Menu

Flux de processus de contrôle qualité des tests logiciels pratiques (exigences de publication)

practical software testing qa process flow

Essayez Notre Instrument Pour Éliminer Les Problèmes

Un aperçu complet du flux de processus de test de logiciel d'assurance qualité de bout en bout:

Remarque - Nous republions cet article utile avec un contenu mis à jour.

Le travail de professionnel des tests de logiciels n'est pas facile. Il est rempli de défis, ce qui est tout aussi exigeant. Les testeurs sont censés être alertes et enthousiastes à chaque étape du cycle de vie de l'application.

Bien qu'il y ait des défis, il existe également plusieurs opportunités formidables pour apprendre et explorer les différents aspects des méthodologies de test, des processus et bien sûr du logiciel en détail.

Le rôle d'un ingénieur de test commence très tôt. Et dès la conceptualisation du projet, les testeurs sont impliqués dans les discussions avec le product owner, le chef de projet et les différentes parties prenantes.

Conditions requises pour libérer

Ce tutoriel sur «Flux de processus de test logiciel» vous donne un aperçu complet des différentes phases de STLC ainsi que des défis impliqués et des meilleures pratiques pour surmonter ces défis d'une manière facilement compréhensible.

Ce que vous apprendrez:

Exigence de libération - Un aperçu complet

Cycle de vie des tests logiciels

Dès l'exigence jusqu'à la libération, chaque phase est clairement expliquée. Examinons-les en détail.

# 1) Exigence

Un projet ne peut pas décoller sans avoir une exigence claire. C'est la phase la plus cruciale où les idées doivent être écrites dans un document bien compréhensible et formaté. Si vous faites partie du projet où vous participez à la phase de collecte des exigences, considérez-vous chanceux.

comment créer un nouveau projet java dans eclipse

Vous vous demandez pourquoi? C'est parce que vous êtes témoin d'un projet en faisant de zéro. Bien qu'il y ait de la fierté à être depuis sa création, cela comporte également des responsabilités et des défis.

Défis

On ne peut pas imaginer toutes les exigences pour se réunir en une seule séance. Soyez assez patient.

De nombreuses discussions auront lieu, dont certaines peuvent simplement ne pas être pertinentes pour votre projet, mais même dans ce cas, elles peuvent contenir des informations vitales pour votre projet. Parfois, la vitesse des discussions peut dépasser vos capacités de compréhension ou vous ne feriez tout simplement pas attention au propriétaire du produit.

L'image ci-dessous met en évidence les étapes cruciales de la collecte des exigences:

Cycle de vie des exigences

Chaque information manquée a un impact énorme sur la compréhension globale et les tests du projet. Pour surmonter cela, voici quelques bonnes pratiques à suivre pendant cette phase.

Les meilleures pratiques

  • Gardez l'esprit ouvert et prêtez attention à chaque mot du propriétaire du produit.
  • Ne vous contentez pas d’écouter, clarifiez votre doute, aussi petit qu’il puisse paraître.
  • Utilisez toujours des cahiers pour une prise de notes rapide. Vous ne devriez utiliser un ordinateur portable que si vous pouvez vraiment taper à une vitesse raisonnable.
  • Répétez les phrases et faites-les clarifier à partir du PO qui, selon vous, est ce que vous avez compris.
  • Dessinez des schémas fonctionnels, reliez du texte, etc. pour clarifier les exigences ultérieurement.
  • Si les équipes sont à des endroits différents, essayez d'en faire un enregistrement WebEx ou similaire. Cela vous aidera toujours lorsque vous avez un doute après la fin des discussions.

Bien qu'il n'y ait pas de mur séparé en tant que tel pour chaque phase, les exigences changent même très tard dans les développements. L'idée est donc de saisir la plupart des exigences et de les documenter correctement.

Une fois qu'il est documenté avec tous les points nécessaires, distribuez et discutez de toutes les parties prenantes afin que les suggestions ou les changements soient détectés tôt et avant de passer à autre chose, tout le monde est sur la même longueur d'onde.

# 2) Stratégie de test

Les testeurs sont censés proposer une stratégie de test qui n'est pas seulement suffisante pour mieux tester le logiciel, mais devrait également inspirer la confiance de chaque partie prenante quant à la qualité du produit.

Stratégie de test

Défis

L'aspect le plus crucial de cette phase est de créer une stratégie qui, lorsqu'elle est élaborée, devrait fournir un produit logiciel sans erreur, durable et accepté par ses utilisateurs finaux.

Les stratégies de test sont quelque chose que vous ne changerez pas tous les deux jours. Dans certains cas, vous devez également discuter de vos stratégies de test avec les clients. Donc, cette partie devrait être traitée avec une grande importance.

Les meilleures pratiques

  • Voici quelques-unes des meilleures pratiques qui, lorsqu'elles sont suivies, peuvent vous apporter un grand soulagement et permettre des tests en douceur.
  • Parcourez à nouveau le document d'exigence. Mettez en surbrillance les points d'importation par rapport à l'environnement du logiciel cible.
  • Faites une liste des environnements dans lesquels le logiciel sera réellement déployé.
  • Les environnements peuvent être compris comme un type de systèmes d'exploitation ou d'appareils mobiles.
  • Si Windows est le système d'exploitation, répertoriez toutes les versions de la fenêtre dans laquelle vous allez tester votre logiciel. Si les versions à savoir. Windows 7, Windows 10 ou Windows Server (s) ne sont toujours pas définis dans le document d'exigence, alors il est grand temps d'en discuter.
  • Sur une note similaire, obtenez les navigateurs cibles avec les versions discutées et documentées si l'AUT est un système Web.
  • Faites une liste de tous les logiciels tiers dont l'application aura besoin (si nécessaire / pris en charge). Ceux-ci peuvent inclure Adobe Acrobat, Microsoft Office, tout module complémentaire, etc.

Ici, l’idée est de conserver toutes les plates-formes, tous les appareils et tous les logiciels nécessaires et nécessaires dont notre application aura besoin pour fonctionner, afin qu’une stratégie globale puisse être formulée.

La figure ci-dessous vous aidera à comprendre les grandes lignes de la stratégie de test si vous travaillez sur un projet agile:

Stratégie de test

# 3) Planification des tests

Une fois que les testeurs sont armés de toutes les informations concernant AUT, la phase de planification est l'endroit où la stratégie est mise en œuvre.

Tout comme une stratégie de test, la planification des tests est également une phase cruciale.

Plan de test

Défis

Étant donné que le succès (ou l'échec) de l'AUT dépend en grande partie de la manière dont les tests ont été effectués, cette phase devient un aspect important de l'ensemble du cycle de vie des tests. Pourquoi? Parce qu'une partie des tests est définie dans cette phase.

Afin de surmonter certains défis, ces meilleures pratiques peuvent vraiment être utiles.

Les meilleures pratiques

  • Gardez toujours à l'esprit de ne rien négliger lors du test de votre application.
  • Il est temps de formuler une stratégie de test.
  • Créez une matrice de l'environnement afin que le logiciel soit testé sur toutes les plateformes.
  • Comme, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Comme le navigateur Chrome Android 4.2.2+.
  • Si votre application fonctionne avec plusieurs bases de données (si documenté), conservez les bases de données (MySQL, Oracle, SQLServer) dans la matrice de test de manière à ce qu'elles soient trop intégrées à certains tests.
  • Configurez les machines de test en conséquence et nommez-les SetUp1, SetUp2, etc.
  • SetUp1 aura Windows 7+ IE 10+ Office 2007+.
  • SetUp2 peut avoir Windows 10+ IE Edge + Office 2013+.
  • SetUp3 peut avoir un téléphone Android avec votre fichier .apk installé.
  • Toutes nos félicitations! Votre configuration de test est prête et vous avez également inclus toutes les combinaisons possibles de plates-formes sur lesquelles votre application fonctionnera.

# 4) Test

Recherche de bogues

Enfin, la version de votre application est sortie et vous êtes prêt à trouver des bogues! Il est maintenant temps de travailler sur la planification des tests et de trouver autant de bogues que possible. Il y aura des phases intermédiaires si vous travaillez dans un environnement agile, puis suivez simplement ces méthodes Scrum.

Le diagramme ci-dessous illustre la catégorisation des différents types de tests:

Types de tests

Défis

Le test est un processus fastidieux qui est lui-même sujet aux erreurs! On trouve de nombreux défis lors du test d'une application. Voici quelques bonnes pratiques pour sauver.

Les meilleures pratiques

Réconforter! Vous essayez de trouver des défauts dans le code. Vous devez faire attention au fonctionnement général du logiciel.

  • Il est toujours conseillé de regarder l’application avec un nouveau look, SANS PASSER À TRAVERS DES CAS DE TEST.
  • Suivez le chemin de navigation de votre logiciel (AUT).
  • Familiarisez-vous avec l'AUT.
  • Maintenant, lisez les cas de test (Tous) de n'importe quel module particulier (Peut-être de votre choix).
  • Allez maintenant à l'AUT et faites correspondre les résultats avec ceux mentionnés dans la section attendue des cas de test.
  • L'idée derrière cela est de tester toutes les fonctionnalités mentionnées sur chaque plate-forme prise en charge.
  • Notez chaque écart, aussi insignifiant qu'il semble.
  • Notez les étapes de la façon dont vous atteignez toute déviation, prenez des captures d'écran, capturez les journaux d'erreurs, les journaux du serveur et toute autre documentation justificative pouvant prouver l'existence de défauts.
  • N'hésitez pas à demander. Bien que vous ayez le document d'exigence, il y aura des moments où vous serez dans le doute.
  • Contactez les développeurs (s'ils sont assis à côté de vous ou s'ils sont joignables) en cas de doute avant de contacter le Product Owner. Comprendre le point de vue du développeur sur le fonctionnement du logiciel. Les comprendre. Si vous pensez que cette implémentation n'est pas conforme aux exigences, informez-en le responsable des tests.

# 5) Avant la sortie

Avant de lancer un produit sur le marché, la qualité du produit doit être garantie. Les logiciels sont développés une fois, mais ils sont en fait testés jusqu'à ce qu'ils soient remplacés ou supprimés.

Défis

Le logiciel doit être testé rigoureusement pour nombre de ses paramètres.

Les paramètres ne peuvent pas être limités à:

  • Fonctionnalité / comportementale.
  • Performance.
  • Évolutivité.
  • Compatible avec lesdites plateformes.

Le défi est également de prédire le taux de réussite d'une application qui dépend de nombreuses itérations des tests effectués.

Les meilleures pratiques

  • Assurez-vous que toutes les fonctionnalités de toutes les plates-formes sont testées.
  • Mettez en évidence les zones qui ne sont pas testées ou celles qui nécessitent plus d'efforts de test.
  • Conservez une matrice de tous les résultats des tests avant la publication. La matrice de test donnera une image globale de la stabilité du produit. Cela aidera également la direction à prendre un appel sur les dates de sortie.
  • Fournissez vos commentaires / suggestions à l'équipe sur vos expériences lors du test du produit.
  • Votre contribution en vous considérant comme l'utilisateur final profitera largement au logiciel.
  • En raison du manque de temps ou de toute autre situation de ce type, nous manquons certains tests ou ne nous approfondissons pas. N'hésitez pas à informer votre responsable de l'état du test.
  • Présentez la carte de santé de l'application aux parties prenantes. Les cartes Santé doivent avoir un certain nombre de tous les défauts enregistrés, ouverts, fermés, intermittents avec leur gravité et leur priorité.
  • Rédigez un document de version et partagez-le avec toute l'équipe.
  • Travailler sur le document de sortie préparé.
  • Améliorer les domaines suggérés par la direction / l'équipe.

L'image ci-dessous montre la carte du cycle de vie des versions logicielles:

Avant la libération

# 6) Libération

Enfin, le moment est venu de livrer le produit aux utilisateurs visés. En tant qu'équipe, nous avons tous travaillé dur pour approuver le produit et laisser le logiciel aider ses utilisateurs.

Défis

Les ingénieurs de test logiciel sont principalement responsables de la publication de tout logiciel. Cette activité nécessite un flux de travail orienté processus. Voici quelques-unes des meilleures pratiques impliquées dans cette phase.

Les meilleures pratiques

  • Rappelez-vous toujours que vous ne travaillez pas sur le document de sortie à la date de LA LIBÉRATION RÉELLE.
  • Planifiez toujours l'activité de publication avant la date de sortie réelle.
  • Standardisez le document conformément aux politiques de l'entreprise.
  • Votre document de version doit essayer d'établir des attentes positives du logiciel.
  • Mentionnez clairement toutes les exigences logicielles et matérielles spécifiques à leurs versions dans le document.
  • Incluez tous les défauts ouverts et leur gravité.
  • Ne cachez pas les principales zones touchées en raison de défauts ouverts. Donnez-leur une place dans le document Release.
  • Faire réviser et signer numériquement le document (peut différer selon la politique de l'entreprise).
  • Soyez confiant et expédiez le document de version avec le logiciel.

Processus de test d'assurance qualité sur un projet réel - Méthode en cascade

J'ai reçu une question intéressante d'un lecteur, Comment les tests sont-ils effectués dans une entreprise, c'est-à-dire dans un environnement pratique?

Ceux qui sortent de l'université et commencent à chercher un emploi ont cette curiosité: comment serait l'environnement de travail réel dans une entreprise?

Ici, je me suis concentré sur le processus de travail réel de Test de logiciels dans les entreprises .

Processus de test réel dans les entreprises

Chaque fois que nous recevons un nouveau projet, il y a une première réunion de familiarité avec le projet. Lors de cette réunion, nous discutons essentiellement de qui est le client? quelle est la durée du projet et quand est-il livré? Qui sont tous impliqués dans le projet, à savoir le responsable, les responsables techniques, les responsables QA, les développeurs, les testeurs, etc.?

À partir du SRS (spécification des exigences logicielles), le plan de projet est élaboré. La responsabilité des testeurs est de créer un plan de test logiciel à partir de ce SRS et du plan de projet. Les développeurs commencent à coder à partir de la conception. Le travail du projet est divisé en différents modules et ces modules de projet sont répartis entre les développeurs.

En attendant, la responsabilité d'un testeur est de créer un scénario de test et d'écrire des cas de test en fonction des modules assignés. Nous essayons de couvrir presque tous les cas de test fonctionnels de SRS. Les données peuvent être gérées manuellement dans certains modèles de cas de test Excel ou outils de suivi de bogues.

Lorsque les développeurs terminent les modules individuels, ces modules sont attribués aux testeurs. Des tests de fumée sont effectués sur ces modules et s'ils échouent à ce test, les modules sont réaffectés aux développeurs respectifs pour un correctif.

Pour les modules réussis, des tests manuels sont effectués à partir des cas de test écrits. Si un bogue est trouvé qui est attribué au développeur du module et est connecté au outil de suivi des bogues . En cas de correction de bogue, un testeur effectue une vérification de bogue et des tests de régression de tous les modules associés. Si le bogue réussit la vérification, il est marqué comme vérifié et marqué comme fermé. Sinon, le cycle de bogue mentionné ci-dessus se répète. (Je couvrirai le cycle de vie des bogues dans un autre article)

Différents tests sont effectués sur des modules individuels et des tests d'intégration sur l'intégration de modules. Ces tests incluent des tests de compatibilité, c'est-à-dire des tests d'applications sur différents matériels, versions de système d'exploitation, plates-formes logicielles, différents navigateurs, etc.

Des tests de charge et de contrainte sont également effectués conformément au SRS. Enfin, le test du système est effectué en créant un environnement client virtuel. Une fois tous les cas de test exécutés, un rapport de test est préparé et la décision est prise de libérer le produit!

Étapes des conditions requises pour la publication

Vous trouverez ci-dessous les détails de chaque étape de test effectuée dans chaque cycle de vie de qualité et de test du logiciel spécifié par Normes IEEE et ISO.

#1) Examen SRS : Examen des spécifications des exigences logicielles.

# 2) Objectifs sont définis pour les versions majeures.

# 3) Date cible prévu pour les sorties.

# 4) Plan de projet détaillé est construit. Cela inclut la décision sur les spécifications de conception.

# 5) Élaborer un plan de test est basé sur les spécifications de conception.

# 6) Plan de test: Cela comprend les objectifs, la méthodologie adoptée lors des tests, les fonctionnalités à tester et à ne pas tester, les critères de risque, le calendrier des tests, le support multiplateforme et l'allocation des ressources pour les tests.

# 7) Spécifications du test: Ce document comprend les détails techniques (exigences logicielles) requis avant les tests.

# 8) Rédaction de cas de test

  • Fumée ( BVT ) cas de test
  • Cas de test de santé mentale
  • Cas de test de régression
  • Cas de test négatifs
  • Cas de test étendus

# 9) Développement: Les modules sont développés un par un.

# 10) Liaison des installateurs: Les installateurs sont construits autour du produit individuel.

comment lire des fichiers .swf

#Onze) Procédure de construction : Une version comprend des installateurs des produits disponibles - plusieurs plates-formes.

# 12) Test: Test de fumée (BVT): test d'application de base pour prendre une décision sur des tests supplémentaires.

  • Test de nouvelles fonctionnalités
  • Navigateur croisé et tests multiplateformes
  • Test de stress et test de fuite de mémoire.

N ° 13) Rapport de synthèse des tests

N ° 14) Gel de code

  • Aucune nouvelle fonctionnalité n'est ajoutée à ce stade.

# 15) Test: Tests de construction et de régression.

# 16) Décision de libérer le produit.

# 17) Scénario post-libération pour d'autres objectifs.

Il s'agissait d'un résumé d'un processus de test réel dans un environnement d'entreprise.

Conclusion

Le travail d'un testeur de logiciels est plein de défis, mais agréable. C'est pour quelqu'un qui est tout aussi passionné, motivé et plein d'enthousiasme. Trouver des défauts chez quelqu'un n'est pas toujours une tâche facile! Cela demande beaucoup de compétences et un œil sur les défauts.

Outre toutes les qualités, un testeur doit également être orienté processus. Comme toutes les autres industries, les projets informatiques sont trop travaillés en phases, où chaque phase a des objectifs bien définis. Et chaque objectif a un critère d'acceptation bien défini. Un ingénieur de test doit porter de nombreuses charges de qualité logicielle sur ses épaules.

Tout en travaillant dans n'importe quelle phase du logiciel, les testeurs sont censés suivre les meilleures pratiques et doivent s'aligner sur le processus impliqué dans les phases respectives. Suivre les meilleures pratiques et un processus bien formulé aide non seulement à faciliter le travail des testeurs, mais contribue également à garantir la qualité du logiciel.

Avez-vous participé à l'une des phases ci-dessus? N'hésitez pas à partager vos expériences ci-dessous.

lecture recommandée

^