software manual testing interview questions
Questions d'entrevue de test manuel basées sur des scénarios les plus fréquemment posées pour les professionnels expérimentés avec des réponses détaillées:
J'ai récemment eu cette expérience unique de Coaching QA (10 ans d'expérience) pour assister à un entretien de test de logiciel avec une société leader du divertissement à Los Angeles. Le site à tester était un simple site Web orienté client (un peu comme une chaîne de télévision en ligne) qui comportait à la fois des composants Web et mobiles.
Une société de conseil projetait des profils à ce client pour un testeur sur site + poste de coordinateur mais aucun d'entre eux n'a réussi le processus d'entrevue de test. Alors ils ont décidé de collecter le Questions d'entretien QA des participants précédents et ils m'ont donné un questionnaire.
Équilibrage de charge du routeur sans fil double WAN
Ils voulaient que je donne les réponses au prochain candidat et coach qui personne pour réussir l’entretien d’assurance qualité.
Lorsque j’ai reçu la liste des questions, j’ai été à la fois surpris et «pas surpris». Surpris, car les questions étaient vraiment basiques et un AQ expérimenté de 10 ans aurait dû être en mesure d'y répondre facilement. Pas si surpris parce que QA est le domaine de l’informatique qui a le plus de mauvaises herbes à mon avis - mais ne nous y prenons pas.
Après avoir terminé l'exercice, j'ai pensé que ce serait bien de partager cette expérience avec les lecteurs de STH. Pour les débutants, ce sera une bonne exposition en direct. Pour d'autres, ce sera un rappel amical de l'importance fondamentaux sont peu importe notre expérience.
lecture recommandée=> 101+ questions et réponses d'entrevue de test de logiciel.
Voici…..
Questions d'entrevue de test manuel pour expérimenté
9 questions d'entrevue de test de logiciel d'assurance qualité les plus courantes pour les débutants et les candidats expérimentés:
#Q 1) Quel est le processus de création d'un script de test?
Répondre:
Étape 1: est d'avoir une compréhension approfondie de l'AUT:
- Cela pourrait être en lisant attentivement les documents sur les exigences.
- En l'absence de documentation, nous pourrions essayer de comprendre n'importe quel point de référence que nous avons - une version précédente de l'application ou des wire-frames ou des captures d'écran
Étape 2: Après avoir compris les exigences, nous dressons une liste des domaines de cette application qui devront être testés. En d'autres termes, nous identifions les exigences du test. L'objectif de cette étape est d'identifier «quoi» tester. Le résultat de cette étape est une liste de Scénarios de test .
Étape 3: Une fois que nous avons les scénarios de test, nous nous concentrons ensuite sur «Comment» les tester. Cette phase consiste à rédiger des étapes détaillées sur la façon de tester une fonctionnalité particulière, les données à saisir ( Données de test ) et quel est le résultat attendu.
Une fois ces 3 étapes terminées, nous sommes prêts pour les tests.
#Q 2) Quels sont les champs d'un rapport de bogue?
Répondre: Les champs importants suivants doivent être inclus dans un bon rapport de bogue :
- Un identifiant unique
- Description du défaut: une courte description de ce qu'est le bogue.
- Étapes à suivre pour reproduire: des détails sur la façon d'arriver à l'erreur, les données de test exactes, l'heure à laquelle le défaut a été trouvé (le cas échéant) environnement: toute information qui vous aidera à rencontrer à nouveau le problème
- Module / section de l'application (le cas échéant)
- Gravité
- Capture d'écran
- Responsable QA: en cas de questions de suivi concernant ce problème
#Q 3) Comment tester un logiciel orienté client?
Répondre: Avec n'importe quelle application que nous testons, nous essayons de voir si un certain ensemble d'exigences est satisfait ou non par l'application. Mais quand il s'agit d'un site destiné aux utilisateurs, en plus de se concentrer sur les fonctionnalités, nous devons également examiner quelques fonctionnalités d'utilisabilité, peut-être les aspects de performance et de sécurité également dans une certaine mesure.
Le premier niveau de test est : Le site répond-il à ses exigences fonctionnelles.
Par exemple, s'il s'agit d'un site de gestion de prêt, nous devons examiner: le nouveau client est-il en mesure de demander un prêt, le client existant peut-il accéder à ses informations de prêt, le pourcentage d'intérêt appliqué au montant du prêt est-il correct, etc.
Le prochain niveau de test est :à quel point est-il facile d'utiliser le site, les options ont-elles un sens logique et répondent-elles ou non aux attentes de l'utilisateur?
Par exemple, si l'utilisateur doit passer 3-4 écrans pour soumettre les informations de base, il va être ennuyé, donc ces problèmes doivent être résolus.
Une autre Exemple, après avoir entré le nom d'utilisateur et le mot de passe, l'utilisateur peut cliquer sur l'onglet - ce qui signifie que le contrôle doit aller sur le bouton «Se connecter», à la place s'il va annuler, l'utilisateur sera vraiment ennuyé et l'expérience d'utilisation du site est va être compromis. Ces problèmes doivent être pris en compte.
C ++ convertir le caractère en int
Test de performance dans la mesure du possible, cela peut ne pas être dans la portée, mais des situations simples comme, combien de temps les résultats de recherche prennent-ils pour être affichés et combien de temps faut-il au système pour récupérer les informations d'un client à l'heure de pointe - ce sont quelques exemples du genre de choses sur lesquelles nous voudrions garder un œil.
Sécurité - pour les sites où il existe une connexion sécurisée pour accéder au site, la fonctionnalité minimale autour de celui-ci doit être testée. Par exemple, si je laisse le site inactif pendant plus de 10 minutes, est-ce une déconnexion automatique ou non. Quelque chose d'aussi basique que cela devrait être axé sur.
#Q 4) Comment surmonter le défi de ne pas avoir de documentation d'entrée pour les tests?
Répondre: SI la documentation standard détaillée comme BRD et FSD n'est pas disponible, le testeur devra dépendre d'un point de référence.
- Captures d'écran
- Une version précédente de l'application
- Wireframes, etc.
Un autre facteur qui aide énormément, est de parler aux développeurs ou aux analystes commerciaux (le cas échéant) pour obtenir une confirmation de notre compréhension ou des clarifications en cas de doute.
Lorsqu'aucune de ces situations ne fonctionne, nous pouvons simplement conceptualiser l'application sur la base de notre expérience d'application informatique antérieure et créer l'ensemble de base de scripts de test. Lorsque la phase de test arrive, nous pouvons configurer une partie du temps de cycle de test et faire un peu de gestion de cas de test (rendre les scripts déjà créés parfaits) afin que nous ayons la documentation pour les phases suivantes.
#Q 5) Comment obtenir productivité maximale d'une équipe offshore?
Répondre: La clé est de s'assurer que tous les testeurs connaissent tous les modules et qu'il n'y a pas de concentration de connaissances en un seul endroit. Impliquer tout le monde dans les revues par les pairs des scripts de test, les réunions sur les défauts et les sessions KT garantira que tout le monde connaît l'application dans la meilleure mesure possible.
De plus, en encourageant le concept de travail d'équipe, nous pouvons faire en sorte que les membres de l'équipe collaborent, s'entraident et s'entraident pour une meilleure productivité.
Des réunions de suivi régulières aident également beaucoup le processus.
#Q 6) Quels sont les rôles et responsabilités d'un coordonnateur sur place? Est-ce qu'il / elle teste aussi?
quel est le meilleur système d'exploitation pour un ordinateur portable
Répondre: Le coordinateur sur site est un point de contact pour l'équipe offshore et pour le client pour toute information concernant la mission de test.
Ce travail comprend:
- KT de et vers offshore et clients
- Préparer l'environnement pour tout tester
- Test de santé mentale, test de fumée
- Test - la fonctionnalité clé.
- Examen de bogue - trouvé par l'équipe offshore
- Attribution de bogue au développement respectif
- Présentation des métriques
- Fournir une signature
Oui, même un coordinateur sur place doit tester.
#Q 7) Bogues incohérents - Pourquoi onsite peut le trouver, mais pas offshore et vice versa - Comment gérer cette situation?
Répondre: Chaque bogue doit être noté et analysé - qu'il soit rencontré sur site ou en mer, qu'il soit reproductible ou non. Une réelle valeur ajoutée au travail d'un testeur est lorsque nous nous impliquons dans le processus d'analyse de la cause fondamentale d'un bogue plutôt que de simplement le signaler.
Voici quelques-unes des façons dont nous pouvons gérer cette situation:
- Tous les membres de l'équipe sur site et en mer doivent suivre une directive selon laquelle des captures d'écran doivent être prises pour chaque erreur que nous rencontrons - répétable ou non.
- S'il y a des journaux, des fichiers système ou quelque chose comme ça, cela pourrait nous aider à trouver des preuves du problème, nous devrions essayer de le trouver.
- Malgré toutes ces étapes, si nous ne pouvons toujours pas dire pourquoi et quand le problème survient, nous devons tout de même le signaler au développeur, avec autant d'informations que possible.
#Q 8) Tests liés à la vidéo / audio - Qu'est-ce que cela comprend?
Répondre: Comment tester une application ayant de la vidéo ou de l'audio?
Voici les points importants à considérer:
- Niveaux d'accès (restreints ou non - contrôlés par mot de passe)
- Différents types d'environnements
- Compatibilité du navigateur
- Résolutions d'écran
- Vitesse de connexion Internet
- Les options spécifiques d'une vidéo - comme lire, arrêter, couper le son, etc.
- Vidéo par taille
- Réponse aux vidéos - commentaires (limitations de la longueur des commentaires et du nombre de commentaires qu'il peut accepter)
- Réponses vidéo aux vidéos
- Interface avec les sites de réseaux sociaux - Interopérabilité
- Vitesse de mise en mémoire tampon
- Intégrer la vidéo
#Q 9) Test des applications mobiles - Que comprend-il brièvement?
Répondre: Test des applications mobiles Scénarios de test importants:
- Vérifiez si l'application fonctionne bien avec plusieurs opérateurs et plusieurs appareils.
- Convivialité des fonctionnalités sur un écran mobile.
- Le tester sur différentes plates-formes mobiles - comme Android et iOS.
- Installations, désinstallation, lancement de l'application avec et sans réseau, test des fonctionnalités.
- Connexions réseau - Wi-Fi, 2G, etc.
- Les journaux de l'utilitaire de configuration iOS iPhone pour Android Monitor.bat peuvent être utilisés pour le débogage.
C'était ça. Maintenant, ce n’était pas si simple.
En guise de note finale, je réitère la philosophie de STH - bien connaître les bases, le reste suit automatiquement.
Je conclus en espérant que cet effort sera bénéfique et significatif pour nos lecteurs. S'il vous plaît laissez-nous savoir ci-dessous dans la section des commentaires sur la façon dont nous avons fait.
Auteur: Cet article est rédigé par Swati Seela, membre de notre équipe STH.
lecture recommandée
- Questions et réponses d'entrevue
- Quelques questions d'entretien intéressantes sur les tests de logiciels
- Comment se préparer à l'entrevue de test de logiciel
- Ressources et téléchargements de tests de logiciels d'assurance qualité
- Meilleurs outils de test de logiciels 2021 [Outils d'automatisation des tests QA]
- 20 questions simples pour vérifier vos connaissances de base de test de logiciels [Quiz en ligne]
- Emploi d'assistant QA en test logiciel
- Quel est le meilleur moment de votre carrière de testeur? - Réponses à ces 14 questions d'entretien intéressantes sur les tests de logiciels