Plus de 40 questions et réponses sur les entretiens avec les analystes d'assurance qualité de test populaires (LISTE 2021)

40 popular test qa analyst interview questions

Questions et réponses les plus fréquemment posées lors des entretiens avec les analystes de test / assurance qualité:

Tout en décidant de la carrière dans laquelle vous souhaitez être, le facteur décisif n'est pas seulement celui sur lequel vous pensez pouvoir aimer travailler.

Mais être dans cette catégorie nécessite beaucoup de compétences, une compréhension des responsabilités ainsi que des tâches nécessaires pour la carrière que vous avez choisie. Il en va de même lors du choix d'une carrière en tant qu'analyste QA. Cela ne vous oblige pas seulement à être un bon testeur, un apprenti rapide, un penseur extraordinaire, mais aussi à être un résolveur de problèmes complexes.

Bien que les qualités mentionnées ci-dessus ne soient pas atteintes instantanément, cela nécessite évidemment de l'expérience et des jours de travail acharné.

Cet article couvrira tous les aspects dont les connaissances sont obligatoires pour être un analyste QA. Les questions et réponses des entretiens QA Test Analyst les plus fréquemment posées ici vous donneront une idée claire de la préparation de votre entretien.

Questions d'entretiens chez QA Test Analyst populaires

Q # 1) Quelles sont les responsabilités d'un analyste QA?

Répondre: L'Analyste QA est celui qui s'assure que toutes les mesures possibles ont été prises pour tester chaque fonctionnalité d'une solution logicielle à la fois fonctionnellement et techniquement.

Les principales responsabilités de l'analyste QA peuvent être engagées comme suit:

• Exécuter et gérer toutes les activités pour atteindre les objectifs du plan de test.
• Choisissez les processus de haute qualité pour développer le produit.
• Doit être en mesure d'analyser les exigences et de documenter les procédures.
• Documentez et revérifiez tous les défauts. Définissez la priorité et la gravité des défauts.
• Ils doivent être capables de créer, documenter et maintenir des cas de test.
• Analyse des résultats des tests.

Q # 2) Que pensez-vous d'un plan de test?

Répondre: Lorsque vous avez une idée claire de quoi, quand, comment et qui, alors les choses deviennent plus faciles. Il en va de même pour les tests de logiciels, où le plan de test est un document qui comprend la portée, l'approche, les ressources et les grandes lignes du projet de test ainsi que les activités de suivi de l'avancement du projet.

Le plan de test est un enregistrement des processus qui incluent:

• Tâches de test
• Environnement de test
• Techniques de conception
• Critères d'entrée et de sortie
• Tous risques, etc.

Q # 3) Inscrire la priorité des tâches de test définies par l'équipe QA dans le développement de produits.

Répondre: La priorité des tâches de test est définie comme suit:

• Un plan de test est préparé comprenant les grandes lignes et la portée du projet de test.
• Les cas de test sont préparés pour couvrir toutes les fonctionnalités majeures et mineures avec les données requises pour les tests.
• Exécution des cas de test selon les fonctionnalités implémentées avec les prochaines versions du projet de test dans le cycle de test.
• Signalement des défauts avec revérification et suivi de sa progression.
• Préparation du résumé du rapport d'exécution de test.

Q # 4) Inscrivez certains des principaux défis auxquels sont confrontés lors de l'exécution des tests logiciels.

Répondre: Comme nous disons que des tests complets ne peuvent jamais être réalisés, plusieurs défis sont impliqués. Qu'il soit petit ou compliqué, il y a des défis à relever lors du test de logiciel de n'importe quel projet.

Voici quelques défis clés:

• Manque de testeurs qualifiés qui sont généralement confrontés au problème de la connaissance du sujet ainsi qu’à un manque de bonne connaissance de l’activité du client.
• Le temps est également considéré comme le facteur, car les testeurs se concentrent généralement principalement sur la couverture des tâches plutôt que sur la couverture des tests avec des tests de qualité lorsqu'il y a une énorme liste de tâches à accomplir.
• Pour décider quel cas de test doit être exécuté en premier et en priorité. Ceci est généralement réalisé par l'expérience du travail.
• Une bonne compréhension des exigences qui peuvent conduire à tous vos efforts de test à zéro, si l'exigence est mal comprise.
• Indisponibilité des meilleurs outils nécessaires pour terminer les tests avec moins de temps et plus d'efficacité.
• Gérer la relation entre les testeurs et les développeurs avec de bonnes compétences en communication et en analyse.

Q # 5) Définissez les tests de cas d'utilisation.

Répondre: Le test de cas d’utilisation peut être défini comme la technique de test de la boîte noire fonctionnelle qui capture la série d’interactions qui se sont produites entre les «acteurs» et le «système». Ici, les «acteurs» sont représentés par les utilisateurs et leurs interactions.

Les caractéristiques des tests de cas d'utilisation sont énumérées ci-dessous:

• Les exigences fonctionnelles du projet sont organisées.
• Enregistre le chemin ou les scénarios du début à la fin.
• Peut couvrir les défauts d'intégration, c'est-à-dire les défauts survenus à la suite de l'interaction entre différents composants.
• Il décrit les principaux flux ainsi que le flux exceptionnel des événements.
• Toutes les conditions préalables requises pour que le cas d'utilisation fonctionne doivent être spécifiées plus tôt.

Q # 6) Définissez la stratégie de test.

Répondre: Un ensemble de lignes directrices ou des approches de test qui sont généralement effectuées par le chef de projet pour déterminer la conception de test et l'approche de test générale est défini comme stratégie de test. Il se trouve sous la forme d'une petite section du plan de test et est utilisé par plusieurs projets.

Différentes approches de test sont suivies en fonction de facteurs tels que la nature et le domaine du produit, le risque de défaillance du produit, l'expertise dans le travail avec les outils proposés, etc.

Ces approches sont en outre classées comme suit:

• Approche pro-active , où l'approche des conceptions de test commence avant la création de la génération. Ainsi, il aide à trouver et à corriger les bogues avant la construction.
• Approche réactive , où l'approche de test est lancée après l'achèvement de la conception et du codage des tests.

Q # 7) Expliquez la différence entre le contrôle qualité et l'assurance qualité.

Répondre: 'Contrôle de qualité' et 'Assurance qualité' sont les deux principaux termes utilisés pour tout projet ou produit de test. Habituellement, les testeurs, qui sont nouveaux dans ce domaine, ne comprennent pas la différence réelle entre les deux.

Comprenons la différence à l’aide du tableau ci-dessous.

Q # 8) Selon vous, quel est le bon moment pour démarrer le contrôle qualité dans un projet?

Répondre: Selon le cycle de vie du développement logiciel (SDLC), la phase de test est exécutée après l’achèvement de la phase de «mise en œuvre et codage». Mais dans le scénario actuel, pour obtenir les meilleurs résultats, il est nécessaire de démarrer le contrôle qualité du projet ou du produit au démarrage du projet.

Suivre cette approche conduira aux principaux avantages indiqués ci-dessous:

• Planification précoce des processus pour répondre aux attentes de qualité du client.
• Bonne et saine communication entre les équipes.
• Donne un temps suffisant pour configurer l'environnement de test.
• Permet un examen et une approbation rapides des plans de test.

Q # 9) Différencier les processus de vérification et de validation.

Répondre: Les processus de vérification et de validation sont généralement déterminés par deux questions célèbres, à savoir ' Construisons-nous le système correctement? » et «Construisons-nous le bon système?» .

Voyons l'autre différence entre ces deux processus dans le tableau ci-dessous:

Q # 10) Expliquez les avantages des tests destructifs.

Répondre: Les tests destructifs sont définis comme la forme de tests effectués par l'équipe de test pour déterminer le point de défaillance du produit sous différentes charges, c'est-à-dire pour évaluer les performances structurelles de l'application pour déterminer sa résistance, sa ténacité, sa dureté ou, par exemple, sa robustesse.

Voici les avantages des tests destructifs:

• La faiblesse de la conception de l'application est déterminée.
• Déterminez la durée de vie de l'application.
• Cela aide à réduire les coûts et les échecs.

Q # 11) En quoi le nouveau test est-il différent du test de régression?

Répondre: Il existe plusieurs différences entre le nouveau test et le test de régression.

Cela peut être facilement compris à partir du tableau ci-dessous:

Q # 12) Que savez-vous des tests basés sur les données?

Répondre: Il est très clair pour chaque testeur d'automatisation que les scripts de test d'automatisation couvrent uniquement la zone de l'application à tester avec une séquence enregistrée d'actions utilisateur. Normalement, ces actions ne produisent aucune erreur car seules les données d'entrée sont prises dans des conditions que nous avons entrées lors de l'enregistrement.

Les tests basés sur les données entrent en jeu ici, où nous voulons que l'application fonctionne comme prévu pour tout type de valeurs d'entrée. À cette fin, les données requises pour les tests basés sur les données ne sont pas codées en dur, mais les scripts de test prennent leurs données à partir de sources de données telles que des fichiers CSV, des sources ODBC, etc.

Pour résumer, les tests basés sur les données exécutent les actions suivantes dans la boucle:

Référence indéfinie c ++ à la classe

• Prend les données de test d'entrée du stockage.
• Données saisies dans l'application pour effectuer des actions.
• Vérifiez les résultats réels avec ceux attendus.
• Répétez à nouveau les mêmes étapes avec les nouvelles données de test d'entrée.

Q # 13) Qu'est-ce que la matrice de traçabilité? Est-ce nécessaire pour chaque projet?

Répondre: La matrice de traçabilité dans tout projet est le moyen de suivre l'avancement du projet concernant la mise en œuvre de nouvelles fonctionnalités, l'amélioration des fonctionnalités existantes, etc. Grâce à une matrice de traçabilité, vous pouvez toujours garder un œil sur l'avancement du projet avec chaque aspect maintenu selon la date.

La matrice de traçabilité des exigences comprend les paramètres mentionnés ci-dessous qui sont en fait conformes au document de spécification des exigences.

Les paramètres de la matrice de traçabilité des exigences comprennent:

• Chaque section du document d'exigence est un point à couvrir dans le RTM (Requirement Traceability Matrix).
• Le titre de chaque point est le titre de chaque section de la spécification des exigences.
• Pour chaque point, des identifiants de cas de test sont mentionnés, écrits pour cette section particulière.
• BUG / New Feature ID est également mentionné dans chaque section.
• Le point le plus important est que le suivi de la fonctionnalité est également maintenu dans lequel la construction du projet et sa fonctionnalité ont été implémentées.
• Un autre paramètre indique si la section est entièrement testée ou est toujours en cours de test.

Q # 14) Décrivez les avantages des tests agiles.

Répondre: En tant que testeur, l'objectif est de fournir un produit de qualité en moins de temps en comprenant les exigences de l'utilisateur final et, plus important encore, aucun défaut du côté de l'utilisateur final. Ici, le test Agile entre dans l'image qui suit le principe du développement logiciel agile et valide rapidement les exigences du client.

Les avantages des tests Agile sont mentionnés ci-dessous:

• Une équipe agile interfonctionnelle est incluse dans les tests, qui à son tour fournit les résultats à intervalles fréquents.
• Économise beaucoup de temps et d'argent.
• Comprend moins de documentation et des retours ponctuels de l'utilisateur final.
• Non seulement le testeur, mais toute l'équipe, y compris le responsable, le client et le développeur, sont impliqués dans la communication face à face.
• À la suite de réunions quotidiennes, les problèmes peuvent être bien déterminés à l'avance.
• Augmentation de la productivité de l'équipe et meilleure compréhension des aspects techniques du projet.

Q # 15) Qu'est-ce que le test négatif?

Répondre: Le test négatif est la méthode qui permet de garantir que la stabilité d'un produit ou d'une application est maintenue ou, par exemple, n'échoue pas lorsqu'une entrée inattendue est donnée. L'objectif principal de cette forme de test valide l'application par rapport à d'éventuelles données d'entrée invalides.

Cette forme de test est également connue sous le nom de «Test d’échec» ou «test de chemin d’erreur» et son objectif principal est de vérifier la fiabilité de la fonction d'application dans des scénarios négatifs. Il expose également les faiblesses du logiciel, détecte les défauts et donne une idée claire de la corruption des données.

Q # 16) Différencier les tests ad hoc et les tests exploratoires?

Répondre: Il existe plusieurs différences entre les tests ad hoc et les tests exploratoires.

Voyons les différences dans le tableau ci-dessous:

Q # 17) Pourquoi les tests d'automatisation sont-ils préférés aux tests manuels?

Répondre: Eh bien, les tests d'automatisation et les tests manuels ont leur importance et leur existence dans le monde des tests.

Vous trouverez ci-dessous quelques aspects importants en raison desquels les tests d'automatisation sont préférés aux tests manuels:

• Le même script de test peut être utilisé à chaque fois pour exécuter le test, donc les tests d'automatisation sont considérés comme les plus fiables et les plus efficaces.
• Généralement préféré en cas de test de régression et d'exécution répétée.
• Les tests d'automatisation sont considérés comme rentables dans le cas d'une exécution à long terme et garantissent ainsi une meilleure qualité des logiciels.
• Les scripts de test sont réutilisables, rapides et tout le monde peut voir les résultats.
• Les outils utilisés pour les tests d'automatisation sont plus rapides et plus fiables que l'approche manuelle.

Cependant, d'autres facteurs déterminent que les tests d'automatisation sont préférés aux tests manuels. Les facteurs mentionnés ci-dessus sont les principaux facteurs.

Q # 18) Qu'entendez-vous par «efficacité du test» et «efficacité du test»?

Réponse: efficacité du test peut être défini comme le calcul du nombre de ressources et de code de test consommés pour exécuter ou dire exécuter une fonction particulière. Il détermine également le nombre de ressources utilisées dans la création de produits logiciels.

Cela peut être déterminé par la formule:

Efficacité du test = (Nombre de défauts résolus / nombre total de défauts soumis) * 100

Efficacité du test peut être définie comme la mesure de l'évaluation de l'environnement de test et de son effet sur l'application logicielle. Ici, la réponse du client est évaluée lorsque les exigences de l'application sont remplies.

Cela peut être déterminé par la formule:

Efficacité du test = (Nombre de défauts trouvés / Nombre de cas de test exécutés)

Q # 19) Expliquez le processus de personnalisation du projet.

Répondre: La personnalisation du projet est un processus cohérent et continu qui garantit que la performance du projet est correcte et conforme aux exigences de l'entreprise. L'ensemble du processus comprend l'examen et la modification des données du projet en fonction des besoins opérationnels actuels de l'organisation.

Le processus d'examen se fait au niveau organisationnel, mais la mise en œuvre des plans de personnalisation se fait au niveau du projet. L'objectif principal et les exigences de l'organisation, ainsi que les relations avec les clients et les utilisateurs, sont les deux principaux facteurs à prendre en compte dans le processus.

Quelques aspects selon les objectifs organisationnels dans le cadre du processus de personnalisation sont:

• Approche projet
• Stratégies
• Contrôles et processus impliqués
• Rôles et responsabilités

Q # 20) Comment faites-vous la différence entre la priorité et la gravité du défaut au sein du projet?

Répondre: La «priorité» et la «gravité» sont toutes deux attribuées au bogue pour classer les problèmes / bogues dans l’ordre dans lequel ils doivent être résolus. Celles-ci sont basées sur divers facteurs.

Laissez-nous comprendre plus avec leurs différences dans le tableau ci-dessous:

Q # 21) Pourquoi est-il nécessaire d'effectuer des tests de performance pour toute application?

Répondre: Dans un langage simple, les tests de performances sont effectués pour déterminer le comportement et la réponse d'une application dans diverses situations. Cela permet de collecter des informations concernant la stabilité de l'application, l'évolutivité, la vitesse, etc.

Les raisons de faire des tests de performance peuvent être comprises à partir des points ci-dessous:

• Il détermine le temps de réponse et les performances d'un composant d'application sous la charge de travail.
• Le temps de réponse de l'activité de l'utilisateur est calculé.
• Nécessite des programmeurs expérimentés avec un langage technique étendu.
• Détermine le comportement de l'application sous charge, c'est-à-dire lorsque le nombre de l'utilisateur augmente instantanément.

Q # 22) Qu'est-ce que les tests basés sur les spécifications?

Répondre: Comme son nom le définit, les tests basés sur les spécifications sont effectués sur la base de la spécification des exigences de l'application, les spécifications fonctionnelles servant de base aux tests effectués.

Cette forme de test est la même que le «test de la boîte noire» où l’utilisateur entre plusieurs données, puis la sortie est observée. Il est approprié à tous les niveaux de test avec spécification et plan de test.

Q # 23) Expliquez CMMI.

Répondre: CMMI signifie Capability Maturity Model Integration. Ce modèle a été développé par le Software Engineering Institute (SEI). Il est basé sur le principe que les processus impliqués dans la gestion et le développement d'un produit ou d'un système déterminent la qualité.

Il fournit également des lignes directrices pour l'amélioration des processus pour le produit ou même l'ensemble de l'organisation.

CMMI est divisé en 5 niveaux comme indiqué ci-dessous:

• Niveau 1: Initiale
• Niveau 2: Géré
• Niveau 3: Défini
• Niveau 4: Géré quantitativement
• Niveau 5: Optimisé

Q # 24) Expliquez les avantages de la mise en œuvre de CMMI.

Répondre: La mise en œuvre de CMMI présente plusieurs avantages.

Ils sont répertoriés comme suit:

• Il fournit une couverture détaillée et des rapports sur le cycle de vie du produit et contribue ainsi à l'amélioration des processus.
• Les normes existantes de l'organisation, leurs processus et procédures sont améliorés dans le cadre de la mise en œuvre de CMMI.
• En raison de la mise en œuvre de CMMI, il y a une augmentation de la livraison à temps ainsi que la satisfaction des clients.
• Cela conduit également à une gestion efficace et à des économies de coûts accrues grâce à la détection précoce des erreurs.

Q # 25) Faites appel à des outils de test d'automatisation.

Répondre: Certains des outils de test d'automatisation sont répertoriés ci-dessous:

• Sélénium
• l'eau
• Moulin à vent
• SAVON
• Tellure

Q # 26) Pouvons-nous faire des tests de régression dans les tests unitaires?

Répondre: Absolument. Le test de régression consiste à tester le défaut indésirable qui aurait pu être introduit dans le code comme effet secondaire de la correction d'autres défauts. Le test unitaire est l'exécution de test consistant à exécuter une petite partie de code indépendante et individuelle.

Les tests de régression peuvent être effectués à n'importe quel niveau, des tests unitaires aux tests d'intégration en passant par les tests d'acceptation. Les tests de régression sont des tests basés sur la perspective, tandis que les tests unitaires sont l'approche de niveau (de bas en haut, de haut en bas).

Q # 27) Quelle est la différence entre les tests de fumée et les tests de santé mentale?

Répondre:

• Les tests de fumée sont les tests des anciennes fonctionnalités importantes ou des fonctionnalités existantes de la construction, tandis que les tests de cohérence sont la validation des modules nouvellement ajoutés, des défauts corrigés dans la construction.
• Le test de fumée se produit en premier, puis est suivi d'un test de santé mentale.
• Les tests de fumée couvrent les tests des fonctionnalités critiques prises en charge par le logiciel, de sorte qu'ils s'étendent à tout le logiciel. Les tests d'intégrité, en revanche, sont limités aux modules récemment ajoutés et sont testés en profondeur.

Q n ° 28) Quelles sont vos activités quotidiennes en tant que testeur manuel dans votre bureau?

Manuel: La première chose que je vérifie dans mon système est d'actualiser le tableau de bord pour le statut des exigences / améliorations ou bogues dans l'itération actuelle. Il est suivi d'appels de mêlée quotidiens et de sessions de reporting, de discussion et de brainstorming pour définir avec des scénarios de test et des cas de test.

Ces cas sont ensuite exécutés après avoir été reformulé conformément à l'examen. Assurer la liaison avec les clients pour les besoins non fonctionnels est également l'une des activités majeures de mon assiette.

Q # 29) Quelles sont vos activités quotidiennes en tant que membre du testeur d'automatisation dans votre bureau?

Automatisation: Ma journée commence par une réunion d’état quotidienne qui discute des résultats d’automatisation d’hier, au cas où j’aurais déclenché un lot de scénarios de test sur la nouvelle version.

Le cycle d'exécution peut être appelé une vérification de l'état, pour voir dans quelle mesure la construction est saine.

Il est suivi de rapports de défauts basés sur les échecs de script, les changements de conception dans la fonctionnalité; maintenir les scripts / bibliothèques ou fonctions, automatiser et intégrer un nouveau script pour les nouvelles exigences et si nécessaire, une nouvelle fonction dans la bibliothèque de fonctions.

Parfois, les scripts de test doivent être réexécutés individuellement pour trouver des défauts de régression via l'automatisation et les ajouter également à la suite de tests.

Q # 30) Comment faites-vous la différence entre une exigence et un défaut et une amélioration?

Répondre : À exigence est une user story qu'il est essentiel de mettre en œuvre, de tester et de délivrer.
Une renforcement est une fonctionnalité ajoutée ou improvisée à l'existant.
À défaut est plutôt un écart complet par rapport aux user stories attendues.

De plus, si un défaut découvre un certain domaine d'une exigence qui n'est pas indiqué, sauf indication contraire dans la spécification, il peut également être appelé comme exigence ou comme une partie de celle-ci.

Q # 31) Que faites-vous lorsque votre développeur refuse de corriger un bogue que vous avez signalé?

Répondre : Un facteur important qui décide de la correction d'un défaut est la «priorité» qui lui est attribuée. Si le défaut est de haute priorité, un show stopper, qui bloque une fonctionnalité majeure et est reproduit de manière cohérente, alors il est nécessaire d'être corrigé dans la construction.

La même chose doit être transmise efficacement aux développeurs, car ensemble, les testeurs et les développeurs contribuent à la qualité du produit à expédier.

D'autres aspects qui peuvent aider à convaincre le développeur de corriger un bogue dans un court laps de temps sont les rapports de qualité du bogue et faire comprendre aux développeurs que la correction du bogue est d'une importance primordiale dans la version.

Q n ° 32) Que faites-vous lorsque votre développeur nie que ce que vous avez déposé EST UN BUG?

Répondre : Une phase la plus importante du cycle de vie du défaut est «Rejeté», ce qui signifie que le rapport d’incident enregistré n’est pas valide. Le document d'exigence métier qui énonce les exigences peut aider à comprendre le logiciel et donc la nature de l'incident signalé.

Analysez le bogue et exposez vos découvertes sur le bogue au développeur et à l'équipe. S'il s'agit d'un défaut, ne manquez jamais de le consigner. Parfois, les testeurs doivent fournir une analyse des écarts et la présenter aux développeurs. Si cela ne résout pas les conflits, les cadres supérieurs de l’équipe devraient intervenir.

Q # 33) Qu'est-ce qui vient en premier, un nouveau test ou un test de régression?

Répondre : Re-tester vient en premier car il réexécute le code, en termes plus simples, il s'agit d'une exécution répétée d'étapes prédéfinies. Cela ne doit pas être nécessaire après avoir corrigé un code. Mais un test de régression consiste à évaluer les effets secondaires d'un défaut résolu.

La résolution d'un défaut et l'ajout d'un autre dans le code ne sont certainement pas le but du processus de test. Les meilleures découvertes et les meilleures captures de testeurs sont généralement des défauts de régression. Une version ne doit jamais être publiée sans avoir été testée par régression.

Q # 34) Quelle est une alternative aux tests bêta?

Répondre : Les tests bêta ont lieu sur le site du client avec le moins d'implication des développeurs, enregistrant les échecs dans l'environnement de production réel. Si une telle pratique n'est pas mise en œuvre par une entreprise, une idée plus sûre peut être d'expédier d'abord le produit aux clients, ceux qui ne sont pas dans la file d'attente pour obtenir la dernière version.

Pendant quelques jours, certains consultants de service chez les clients peuvent utiliser le logiciel, enregistrer et surveiller les activités qui assurent la stabilité de la version dans leur environnement, de sorte que même si un bogue majeur est laissé de côté pour être corrigé, puisse être testé avant le livrer au client ciblé. Une autre approche consiste à échanger les tests des exigences au sein d'une équipe pour des tests impartiaux.

Q n ° 35) Quels sont les inconvénients de la mise en œuvre / méthodologie Agile auxquels vous avez fait face?

Répondre : Les inconvénients sont les suivants:

1. Les sprints sont généralement très limités en termes de délais.
2. La documentation n'est pas la priorité
3. Le basculement entre les PBI (Product Backlog Items) peut être fréquent.

Q # 36) Pourquoi l'analyse d'impact est-elle importante?

Répondre : Pour pratiquer une analyse basée sur les risques, une analyse d'impact doit être effectuée. Ce faisant, les cas de test peuvent être conçus de manière à ce que tous les bogues graves, critiques du point de vue du client, puissent être résolus avant le temps. Une bonne étude de l'entreprise, des besoins des clients et de leur utilisation du logiciel doit être prise en charge.

Par exemple, le risque le plus important associé aux logiciels dans le domaine bancaire est la sécurité. Tout nouveau formulaire ajouté au logiciel déjà existant peut être vulnérable. Une bonne quantité de tests de sécurité est recommandée en ajoutant des liens, une redirection et une navigation appropriés vers la page appropriée, en installant le proxy si nécessaire.

Q # 37) À l'aide d'un exemple, chaque test de performance, test de résistance et test de charge?

Répondre : Le meilleur cas ici qui puisse être pris est un site Web en direct.

Test de performance est fait pour vérifier les problèmes dans le système lorsqu'il est soumis à une condition similaire à un scénario en temps réel. Il n'est pas nécessaire d'être effectué dans des conditions de stress. Les résultats des tests de performance aident à déterminer si le système est prêt à entrer en production.

Pour un flux de réservation de billets simple, un problème de performance peut avoir entraîné une lenteur. Par exemple, certaines requêtes utilisant des jointures sont un peu plus lentes qui ont implémenté une clause inutile ou un stockage de données inapproprié dans la base de données.

Test de stress est un type de test de performance qui est effectué en mettant le logiciel dans des conditions extrêmes (charges lourdes et non distribuées, ressources de calcul limitées, haute concurrence).

Si un système présente certains comportements tels que des données perdues ou corrompues, des ressources utilisées même après la suppression du stress, l'irresponsabilité ou des exceptions non gérées, cela signifie qu'il a échoué dans les tests de résistance. Parfois, une panne de disque, une augmentation inutile du nombre de GDI peut également être le résultat.

Par exemple, Si le site Web hébergé sur une machine qui consomme déjà énormément de mémoire ou qui le bombarde de requêtes répétées ne doit pas se bloquer ou vous déconnecter.

Test de charge observe le comportement du système tout en augmentant constamment la charge sur le système jusqu'à ce qu'un seuil soit atteint. Les modèles de charge de travail, les métriques et les niveaux de charge sont généralement les données d'entrée des tests de charge.

Par exemple, le temps pour récupérer la disponibilité des sièges pour un train augmente progressivement lorsque l'heure de réservation du quota de Tatkal se rapproche, car le nombre d'utilisateurs alors connectés au système augmente avec l'heure de réservation de Tatkal proche de 10 heures ou 11 heures.

Q # 38) Quel a été l'un de vos plus grands défis lors des tests de régression?

Répondre : Il peut y avoir divers défis lors de l'exécution des tests de régression.

• La réexécution répétée des tests peut devenir moins excitante pour les testeurs.
• Prend du temps, car de tels tests nécessitent parfois une réflexion hors de la boîte.
• Valeur commerciale compromise.
• Une mauvaise sélection de cas de test de régression peut ignorer un défaut de régression majeur à trouver.
• La reproduction du défaut de production devient donc incohérente.
• Grande suite à exécuter.

Q # 39) Si vous êtes invité à documenter des scénarios de test, des cas de test, des plans de test, une stratégie de test, par quoi allez-vous commencer et dans quel ordre le reste suivra-t-il?

Répondre : La séquence sera la stratégie de test, le plan de test, les scénarios de test et enfin les cas de test.

Q # 40) Et si je manque de documenter l'un des éléments ci-dessus? Dites que je manque de documenter le plan de test, quelles seront les conséquences?

Répondre : Si nous manquons de documenter le plan de test, il y aura un vide pour la portée de tester son approche objective et l'accent mis sur les tests. Il sera alors difficile de déterminer les fonctionnalités à tester, les techniques à tester, les critères de réussite ou d'échec et finalement un risque majeur associé aux tests.

Q n ° 41) Comment commenceriez-vous à tester la version que vous avez récemment obtenue: y a-t-il une approche que vous suivez, par exemple Commencer d'abord les tests de fumée, puis les tests de santé mentale?

Répondre : Test de fumée> Test de santé mentale> Test exploratoire> Test de fonctionnalité> Test de régression et validation du produit final.

Q # 42) Expliquez le format du rapport de bogue que vous avez suivi?

Répondre :

Un rapport de bogue doit contenir les informations suivantes:

• ID de bogue
• Mappage aux exigences / amélioration / bogue existant
• Résumé / titre du bogue
• Une version du produit
• Priorité
• Configuration (spécifications système)
• Conditions préalables
• Pas
• Résultat attendu
• Résultat réel
• Journaux. Instantanés, clips vidéo
• Statut
• D'autres remarques

Q n ° 43) Comment sélectionner des cas de test de régression ou former la suite de tests de régression?

Répondre : Oui. C'est le résultat d'une analyse d'impact. Il s'agit d'un simple mappage des fonctionnalités utilisées ou accessibles dans les différentes zones que vous testez, son intégration avec d'autres fonctionnalités et tout au long d'un système de bout en bout ou de test de flux.

Vous pouvez également récupérer les défauts précédemment signalés pour la même fonctionnalité dans les versions précédentes. Idéalement, un défaut doit être testé par régression en utilisant au moins cinq cas de test différents qui utilisent la fonctionnalité.

Q n ° 44) Pouvez-vous venir avec un exemple des défauts suivants

• Défaut de haute gravité de faible priorité
• Défaut de haute priorité et de faible gravité

Répondre : Un défaut qui bloque l'application lorsqu'elle est reproduite uniquement à un horodatage donné sur un système d'exploitation particulier peut être un défaut de haute gravité et un défaut de faible priorité.

Un défaut déposé sur une vue qui ne s'ouvre pas par double-clic mais s'ouvre avec un clic droit peut être un défaut de haute priorité et de faible gravité.

Q n ° 45) Ecrire un cas de test efficace pour tester si un article donné est un livre blanc?

Répondre: Si la couleur de l'encre source avec laquelle vous écrivez sur du papier blanc reste la même, le papier est blanc. Par exemple, si vous écrivez sur du papier blanc avec de l'encre rouge, la couleur de l'encre reste rouge dans le stylo et apparaît également en rouge sur le papier.

Noter: Il existe de nombreuses autres réponses à cette question. Vous pouvez penser à une telle réponse valable avec une logique sous-jacente.

Q n ° 46) Qu'est-ce que le test Charter?

Répondre: Un test de session effectué en fonction des objectifs et des agendas répertoriés dans une charte avant de commencer le test est appelé test de la Charte.

Les tests ici sont effectués dans un créneau horaire fixe avec un accent moins sur la documentation et plus sur les tests. Il s'agit d'une variante différente des tests exploratoires dans laquelle les ingénieurs de test vérifient le logiciel dans un laps de temps ( Par exemple, juste 2 heures) sur la base de quelques heuristiques développées.

Q # 47) Quelle est votre approche lorsque vous avez une version hautement prioritaire à livrer dans un délai très court?

Répondre: Dans de tels cas, un plan bien pensé peut être bénéfique.

Ce qui suit peut être fait pour aider les tests dans un scénario de manque de temps: -

• Utilisation de scripts d'automatisation mis à jour existants pour exécuter des tests de régression.
• Tester les scénarios basés sur les flux de bout en bout.
• Exécution de cas de test de haute priorité et si le temps le permet, passez aux cas de priorité inférieure.
• Re-tester les bogues de haute priorité déposés sur les versions précédentes.
• Test logiciel rapide
• Les développeurs peuvent être invités à exécuter des tests unitaires pour obtenir une plus grande couverture des tests.

Q n ° 48) Écrire des cas de test sur n'importe quel appareil / objet présent autour (Exemple: une chaise)?

Répondre: Un conseil ici serait: Commencez toujours par rassembler les exigences. Cela montre votre maturité face au cycle de vie du développement logiciel. N'hésitez pas à poser des questions après avoir sélectionné l'objet.

Dans ce cas:-

• De quel type de chaise s'agit-il? Chaise de bureau, chaise de table d'étude, chaise de canapé, chaise de table à manger, chaise de confort?
• Quel matériau est utilisé pour fabriquer la chaise - bois, acier, plastique, rembourrage?
• Demandez les dimensions (hauteur, poids en fonction du type de chaise).
• Demandez la disponibilité. Et sur cette base, commencez à rédiger vos dossiers.

Les cas de test seraient différents pour chaque type de chaise, ce qui est mieux laissé pour votre capacité de réflexion ( Par exemple, but de la chaise, dimensions selon le type de chaise, portable-non potable, légère, options d'achat).

Pour chaque chaise, un Le cas de test de performance peut être: pour calculer la résistance à la traction ou la capacité de charge maximale.

Q n ° 49) Tout peut-il être automatisé?

Répondre: - Dans une certaine mesure oui. Mais les outils d'automatisation, comme les autres logiciels, ont leurs limites. En outre, les logiciels en cours de test ou l'application en cours de test continueront d'être mis à niveau.

Il n'y a donc aucune garantie que les tests logiciels peuvent s'exécuter sans intervention manuelle. Après tout, un outil est aussi intelligent que le testeur. Il s'agit simplement de tester un autre logiciel. C’est le code / les scripts / les bibliothèques qui doivent être suffisamment intelligents pour tester et trouver les défauts.

Conclusion

J'espère que cet exercice vous aidera à vous réchauffer avec quelques questions et vous donnera un bon coup de pied pour vos entretiens et affiner votre confiance tout en répondant aux questions. En outre, il peut y avoir d'autres questions basées sur des scénarios, celles qui peuvent provenir de votre CV / profil.

Par conséquent, il est toujours conseillé de pratiquer un entretien simulé avec soi-même, afin que l'entrevue se révèle être une situation gagnant-gagnant à la fois pour l'intervieweur et le candidat. N'oubliez pas qu'un analyste qualité est plus qu'un ingénieur de test, dont les commentaires sont importants non seulement pour la qualité du produit, mais également pour le processus suivi pour tester le logiciel.

Merci et bonne chance pour les interviews!

lecture recommandée

• Questions et réponses d'entrevue
• 25+ questions et réponses d'entrevue ADO.NET les plus populaires
• 25 meilleures questions et réponses d'entrevue de test Agile
• Questions d'entrevue Spock avec réponses (les plus populaires)
• Questions et réponses d'entrevue de test ETL
• 20 questions et réponses d'entrevue TestNG les plus populaires
• Top 30+ Questions et réponses populaires d'entrevue de concombre
• Top 50 des questions et réponses d'entretiens CCNA les plus populaires