6 basic skills that every tester should have
Les tests de logiciels ou QA sont la meilleure plate-forme pour les nouveaux arrivants qui souhaitent entrer dans l'industrie informatique malgré les idées fausses selon lesquelles il s'agit d'un travail moins ou moins rémunéré.
La compétence la plus importante dont un testeur a besoin est la capacité à trouver des bogues . Et, si vous êtes le genre de personne qui aime trouver des insectes, alors vous allez aimer et grandir dans ce domaine.
Cela dit, il existe peu de compétences supplémentaires qui peuvent vous aider à trouver des bogues et à mieux travailler avec les processus d'assurance qualité.
Cet article montrera le processus d'assurance qualité tel qu'il est suivi dans la plupart des entreprises et donnera aux nouveaux testeurs des éclaircissements sur les tests.
En détail, vous apprenez le processus de documentation et les normes, le travail préalable du testeur, les tests basés sur les contraintes, les tests pendant le développement partiel et enfin le processus d'approbation.
Commençons.
Ce que vous apprendrez:
- #1. Documentation
- # 2. La préparation du test
- # 3. Processus de test - Quels tests effectuer?
- # 4. Test au stade de développement partiel
- # 5. Document de rapport de bogue
- # 6. Processus d'approbation
- Conclusion
- lecture recommandée
#1. Documentation
La documentation est essentielle aux tests. La plupart des entreprises attribuent cette tâche aux nouveaux arrivants. Pour réussir, vous devriez avoir bon vocabulaire car le reste des éléments tels que les normes de documentation, etc. ne sont pas sous votre contrôle et dépendent des processus de l'équipe et de l'entreprise.
Assurez-vous également que vous voyez la valeur du processus de documentation. Les avantages sont nombreux: ils vous aident à suivre les changements d'exigences, à suivre vos étapes de test, à consigner votre travail, etc.
Lecture recommandée=> Pourquoi la documentation est importante dans les tests de logiciels
# 2. La préparation du test
De tous les documents disponibles, les suivants ne peuvent être négligés. Ceux-ci sont également appelés documents livrables et ils relient la compréhension du client, du développeur et du testeur.
comment ouvrir un fichier dat sous windows
a) Plan de test: trace le déroulement des tests du début à la fin .
Le plan de test décrit la portée et les activités de la phase de test. Créée par le responsable QA, l'équipe doit contribuer et se tenir au courant de tout ce qui est écrit dans le plan de test.
Certaines équipes ont plusieurs niveaux de plans de test: plan directeur et plans par phase.
Un plan de test doit avoir:
- Nom et version du projet
- Identifiants du plan de test - Créateur, n ° de projet, date de création, etc.
- Introduction - Vue d'ensemble du projet, objectif et contraintes
- Références - Liste des références utilisées comme entrée (assurez-vous d'utiliser les versions exactes et les plus récentes)
- Éléments de test - Modules, version, portée, hors de portée, etc.
- Approche globale de test / stratégie de test - Outils à utiliser, processus de suivi des défauts, niveaux de test à effectuer, etc.
- Critères d'élément réussite / échec - Directives d'exécution des tests
- Critères de suspension et de reprise
- Livrables de test - Cas de test, rapports de test, rapport de bogue, métriques de test, etc.
- Détails de l'environnement de test
- Liste de l'équipe avec les informations de point de contact. pour chaque module ou type de test
- Estimations des tests - Temps et efforts. Les détails du budget sont confidentiels et vous ne les trouverez pas ici
- Risques et plans d'atténuation
- Approbations
- Autres directives
Lire aussi=>
- Comment rédiger un document de plan de test à partir de zéro
- Format du plan de test
- Exemple de plan de test réel (pdf) [Télécharger]
b) Scénarios de test:
Pointeurs sur une ligne sur «ce qu'il faut tester» en fonction de chaque exigence et généralement documentés et suivis dans des feuilles de calcul.
La plupart d'entre eux contiennent:
- Nom du module / composant / fonction (connexion, administrateur, enregistrement, etc.)
- L'ID de scénario sert de référence (par exemple: TS_Login_001)
- Description du scénario - «Ce qu'il faut tester» Par exemple: valider si la connexion permet aux utilisateurs avec des informations d'identification valides de se connecter avec succès
- Importance du scénario - À prioriser en cas de temps insuffisant - Élevé / Moyen / Faible
- ID d'exigence - Pour la traçabilité
Lectures complémentaires=>
c) Cas de test:
Des cas de test précis donnent des résultats de test précis. Les feuilles de calcul sont toujours le support populaire pour la rédaction de cas de test, en particulier pour les débutants, même si certaines entreprises adaptent des outils de gestion de test. La base de l'écriture de cas de test est le document SRS / FRD / Req. Mais, ce n'est souvent pas suffisant, vous devrez donc utiliser beaucoup d'hypothèses et de discussions avec les équipes BA / Dev.
Rédaction de cas de test efficaces est la qualification la plus importante qu'un testeur doit posséder. Habituellement, tous les cas de test sont classés comme positifs / négatifs. Cas de test positif donne des contributions valides et obtient des résultats positifs. Cas de test négatif donne des entrées non valides et obtient le message d'erreur exact.
qu'est-ce que les tests de régression dans les logiciels
Pour plus d'informations à ce sujet, consultez:
Certains des attributs communs de tous les cas de test sont:
- ID de scénario - extrait du document de scénario de test
- ID de cas de test - Pour une identification et un suivi uniques. Par exemple: TC_login_001
- Description du test - Brève explication de la condition de test testée
- Étapes à exécuter - Instructions détaillées étape par étape sur la façon de tester
- Données de test - Données fournies aux étapes de test
- Résultat attendu - Résultat attendu
- Résultat réel - Réponse de l'AUT lorsque le test est exécuté
- État - Réussi / Échec / Pas d'exécution / Incomplet / Bloqué - Décrit le résultat du test
- Commentaires - Pour plus de détails
- Exécuté par - Nom du testeur
- Date d'exécution - Date à laquelle le test est exécuté
- ID de défaut - Défaut consigné par rapport au scénario de test, en cas d'échec du test
- Détails de configuration - OS, navigateur, plate-forme, informations sur l'appareil (facultatif)
Lecture recommandée=>
# 3. Processus de test - Quels tests effectuer?
Il existe un grand nombre de types de tests, mais tous ne peuvent pas être effectués sur cet AUT. Le temps, le budget, la nature de l’activité, la nature de l’application et l’intérêt du client sont les principaux acteurs dans le choix des tests à effectuer sur l’application.
Par exemple: S'il s'agit d'un portail de commerce en ligne, les tests de résistance et les tests de charge sont obligatoires. Cependant, certains des types de tests à ne pas manquer sont:
- Test de la boîte noire
- Test de la boîte grise
- Test unitaire (Le cas échéant)
- Test d'intégration
- Test d'intégration incrémentale
- Les tests de régression
- Test fonctionel
- Nouveau test
- Test de santé mentale
- Test de fumée
- Test d'acceptation
- Tests d'utilisation
- Test de compatibilité
- Test de bout en bout
- Test alpha
- Tests bêta
# 4. Test au stade de développement partiel
En général, avec les entreprises de niveau moyen et en démarrage, le temps et les ressources sont limités. Les testeurs ici peuvent commencer leur processus de test avant l'intégration du module, ce qui signifie que nous pouvons effectuer des tests d'intégration unitaires et intermédiaires.
Il est important de noter que les résultats de ces étapes ne peuvent pas être considérés comme précis, vous devrez donc peut-être planifier un test global de la boîte noire une fois que tout sera prêt. Ignorer cette partie pourrait s'avérer coûteux et testant, inefficace.
# 5. Document de rapport de bogue
Sur le terrain, c'est le document d'assurance qualité le plus critique que vous ayez jamais réalisé.
Voici les champs qu'un bon rapport de bogue doit avoir:
- ID de défaut - Généralement un numéro de série
- Description du défaut - Explication du problème en une ligne
- Emplacement - Module / zone de l'AUT où le problème est détecté
- Numéro de build - Version et code build no.
- Étapes à reproduire - Liste des étapes qui vous mènent au problème
- Gravité - Définissez un niveau pour décrire la gravité du problème - Faible, moyenne, élevée, bloqueur, etc.
- Priorité - Définie par les développeurs pour déterminer l'ordre dans lequel le défaut sera corrigé (P1, P2, P3, etc. P1 - le plus élevé)
- Attribué à - Propriétaire du défaut à ce moment précis
- Signalé par: nom du testeur
- Statut - Statut différent pour représenter l'étape du cycle de vie du bogue
- Nouveau - Le bogue est détecté et vient d'être signalé
- Ouvert - Validé par le responsable QA
- Attribué - Envoyé au responsable du développement pour attribution au développeur respectif
- En cours / Travail en cours - Dev a commencé à y travailler
- Corrigé / résolu - Le développeur a fini de travailler dessus
- Vérifié / fermé - L'équipe QA a retesté et trouvé le bogue corrigé
- Retester - L'équipe QA n'est pas d'accord avec la résolution de Dev et fait progresser le bogue pour le retravailler
- Dupliquer - Un bogue similaire existe déjà
- Différé - Bug valide mais sera corrigé dans les versions ultérieures
- Invalide - Pas un bogue ou n'est pas reproductible ou il n'y a pas assez d'informations
Lectures complémentaires=>
- Comment rédiger un bon rapport de bogue
- Exemple de rapport de bogue
- Comment commercialiser et corriger vos bogues
- Pourquoi le signalement de bogues est un art
# 6. Processus d'approbation
Approuver et l’envoi de la documentation finale est la tâche du responsable / responsable du contrôle qualité. Cependant, l'équipe doit soumettre les documents ci-dessus (scénario de test, cas de test et journal des défauts) pour les examens finaux et l'audit.
Assurez-vous de les relire tous et d'envoyer les versions finales.
Lire aussi=>
- Comment rédiger un rapport de synthèse de test efficace
- Comment signaler intelligemment l'exécution des tests
- Exemple de rapport de résumé de test [Télécharger]
Conclusion
C'est le processus dont j'ai été témoin et expérimenté de première main lorsque j'étais testeur et j'espère que cela vous a donné des indications utiles.
Enfin, une carrière dans les tests a été une joie absolue pour moi et j'espère que c'est pour vous aussi.
Tout le meilleur pour votre carrière!
lecture recommandée
- Meilleurs outils de test de logiciels 2021 [Outils d'automatisation des tests QA]
- Test alpha et test bêta (un guide complet)
- Téléchargement du livre électronique sur les tests
- Test fonctionnel vs test non fonctionnel
- 20 questions simples pour vérifier vos connaissances de base de test de logiciels [Quiz en ligne]
- Guide de CV de test logiciel parfait (avec échantillon de CV de testeur de logiciel)
- Build Verification Testing (BVT Testing) Guide complet
- 7 conseils de base pour tester des sites Web multilingues