Menu

Comment réviser un document SRS et créer des scénarios de test - Formation aux tests de logiciels sur un projet en direct - Jour 2

how review srs document

Essayez Notre Instrument Pour Éliminer Les Problèmes

Ceci est le deuxième tutoriel de notre «Formation gratuite en ligne sur les tests de logiciels sur un projet en direct» séries. Si vous êtes nouveau ici, veuillez consulter le premier tutoriel d'introduction: Formation de bout en bout sur les tests logiciels sur un projet en direct.

Passons maintenant à une analyse détaillée de la façon dont se déroule une procédure pas à pas SRS, de ce que nous devons identifier à partir de cette étape, des étapes préalables à suivre avant de commencer, des défis auxquels nous pourrions être confrontés, etc. d'une manière détaillée.

Comment consulter un document SRS et créer des scénarios de test_

Phase de conception du SDLC:

La phase suivante du SDLC est la «conception» - c'est là que les exigences fonctionnelles sont traduites en détails techniques. Les équipes de développement, de conception, d'environnement et de données sont impliquées dans cette étape. Le résultat de cette étape est généralement un document de conception technique - TDD.

L'entrée est le document SRS à la fois pour la création du TDD et pour que l'équipe QA commence à travailler sur l'aspect QA du projet - qui est de revoir le SRS et d'identifier l'objectif du test.

Ce que vous apprendrez:

Qu'est-ce qu'un examen SRS?

SRS est un document créé par l'équipe de développement en collaboration avec les Business Analysts et les équipes environnement / données. En règle générale, ce document une fois finalisé sera partagé avec l'équipe d'assurance qualité via une réunion au cours de laquelle une procédure détaillée est organisée.

Parfois, pour une application déjà existante, il se peut que nous n'ayons pas besoin d'une réunion formelle et que quelqu'un nous guide à travers ce document. Nous pourrions avoir les informations nécessaires pour le faire nous-mêmes.

L'examen SRS n'est rien d'autre que de parcourir le document de spécification des exigences fonctionnelles et d'essayer de comprendre à quoi ressemblera l'application cible.

Le format formel et un échantillon ont été partagés avec vous tous dans l'article précédent. Cela ne signifie pas nécessairement que tous les SRS seront documentés exactement de cette façon. Toujours, le la forme est secondaire au contenu .

Certaines équipes choisiront simplement d'écrire une liste à puces, certaines équipes incluront des cas d'utilisation, certaines équipes incluront des exemples de captures d'écran (comme le document que nous avions) et certaines décrivent simplement les détails dans des paragraphes.

Pré-étapes à l'examen des spécifications des exigences logicielles

Étape 1) Les documents font l'objet de plusieurs révisions, alors assurez-vous que nous avons la bonne version du document référencé, le SRS.

Étape 2) Établissez des lignes directrices sur ce qui est attendu à la fin de l'examen de chaque membre de l'équipe. En d'autres termes, décidez des livrables attendus de cette étape - généralement, le résultat de cette étape consiste à identifier les scénarios de test. Les scénarios de test ne sont rien d'autre que des pointeurs sur une seule ligne de «ce qu'il faut tester» pour certaines fonctionnalités.

Étape 3) Établissez également des lignes directrices sur la façon dont ce livrable doit être présenté - je veux dire, le modèle.

Étape 4) Décidez si chaque membre de l'équipe va travailler sur l'ensemble du document ou divisez-le entre eux. Il est fortement recommandé à tout le monde de tout lire car cela empêchera la concentration des connaissances avec certains membres de l'équipe.

Mais dans le cas d'un projet de grande envergure, avec des documents SRS comptant près de 1000 pages, l'approche consistant à diviser le module de document et à l'attribuer aux membres individuels de l'équipe est la plus pratique.

Étape # 5) L'examen SRS permet également de mieux comprendre s'il existe des conditions préalables spécifiques requises pour le test du logiciel.

Étape # 6) En tant que sous-produit, une liste de requêtes où certaines fonctionnalités sont difficiles à comprendre ou si des informations supplémentaires doivent être incorporées dans les exigences fonctionnelles ou si des erreurs sont commises dans SRS.

De quoi avons-nous besoin pour commencer?

  • La version correcte du document SRS
  • Des instructions claires sur qui va travailler sur quoi et combien de temps ils ont.
  • Un modèle pour créer des scénarios de test.
  • Autres informations sur - qui contacter en cas de question ou qui signaler en cas d'incohérence dans la documentation

Qui fournirait ces informations?

Les chefs d'équipe sont généralement responsables de fournir tous les éléments énumérés dans la section ci-dessus. Cependant, les contributions des membres de l’équipe sont toujours importantes pour le succès de toute cette entreprise.

Les chefs d'équipe demandent souvent: quel type d'entrées? Ne serait-il pas préférable d’attribuer un module à une personne intéressée plutôt qu’à un membre de l’équipe qui ne l’est pas? Ne serait-il pas bien de décider de la date cible en fonction de l’opinion de l’équipe plutôt que de leur imposer une décision? De plus, pour la réussite d'un projet, les modèles sont importants.

En règle générale, les modèles ont un taux d’efficacité plus élevé lorsqu'ils sont adaptés à la commodité et au confort de l’équipe spécifique. Il faut donc noter que les chefs d'équipe sont plus que tout des membres d'équipe. Impliquer votre équipe dans les décisions quotidiennes est crucial pour le bon déroulement du projet.

Un modèle est-il requis pour les scénarios de test?

Pourquoi un modèle pour les scénarios de test - n'est-il pas suffisant si nous faisons simplement une liste?

Tout à fait. Cependant, les projets logiciels ne sont pas des spectacles «one-man». Ils impliquent travail en équipe .

Imaginez une équipe de 4 si chacun d'eux décide de revoir un module de la spécification des exigences logicielles chacun. Le membre de l'équipe A a dressé une liste sur une feuille de papier. Le membre de l'équipe 2 a utilisé une feuille Excel. Le membre de l'équipe 3 a utilisé un bloc-notes. Le membre de l'équipe 4 a utilisé un mot doc. Comment consolider tout le travail effectué pour le projet à la fin de la journée?

De plus, comment pouvons-nous décider quelle est la norme et comment pouvons-nous dire ce qui est juste et ce qui ne l’est pas si nous n’avons pas créé les règles, pour commencer?

Voilà ce qu'est le modèle: Un ensemble de lignes directrices et un format convenu pour l'uniformité et la concordance pour toute l'équipe.

comment ouvrir les fichiers .torrent

Comment créer un modèle pour les scénarios de test QA?

Modèles ne doit pas être compliqué ou inflexible.

Tout ce dont ils ont besoin est un mécanisme efficace pour créer un artefact de test utile. Quelque chose de simple comme celui que nous voyons ci-dessous:

modèle de scénarios de test

L'en-tête de ce modèle contient l'espace requis pour capturer les informations de base sur le projet, le document actuel et le document référencé.

Le tableau ci-dessous nous permettra de créer des scénarios de test. Les colonnes incluses sont:

Colonne n ° 1) ID du scénario de test
Chaque entité de notre processus de test doit être identifiable de manière unique. Ainsi, chaque scénario de test doit se voir attribuer un ID. Les règles à suivre lors de l'attribution de cet identifiant doivent être définies.

Pour le bien de cet article, nous allons suivre la convention de dénomination comme TS (préfixe qui signifie Test Scenario) suivi de «_», nom du module MOI (Mon module Info du projet Orange HRM) suivi de «_» puis de la sous-section ( Par exemple, MOI pour My Info Module, P pour la photographie et ainsi de suite) suivi d'un numéro de série. Un exemple serait: «TS_MI_MIM_01».

Colonne # 2) Exigence
Cela aide que lorsque nous créons un scénario de test, nous devrions être en mesure de le mapper à la section du document SRS où nous l'avons choisi. Si les exigences ont des identifiants, nous pourrions l'utiliser. Sinon, les numéros de section ou même les numéros de page du document SRS à partir desquels nous avons identifié une exigence testable feront l'affaire.

Colonne n ° 3) Description du scénario de test
Une seule ligne spécifiant «ce qu'il faut tester». Nous l'appellerions également l'objectif du test.

Colonne # 4) Importance
Il s'agit de donner une idée de l'importance de certaines fonctionnalités pour l'AUT. Des valeurs telles que high, medium et low peuvent être attribuées à ce champ. Vous pouvez également choisir un système de points, comme 1-5, 5 étant le plus important, 1 étant moins important. Quelle que soit la valeur que ce champ peut prendre, elle doit être prédéterminée.

Colonne # 5) Nombre de cas de test
Une estimation approximative du nombre de cas de test individuels que nous pourrions finir par écrire ce scénario de test. Par exemple, Pour tester la connexion, nous incluons ces situations: Nom d'utilisateur et mot de passe corrects. Nom d'utilisateur correct et mot de passe incorrect. Mot de passe correct et nom d'utilisateur incorrect. Ainsi, la validation de la fonctionnalité de connexion entraînera 3 cas de test.

Remarque: Vous pouvez développer ce modèle ou supprimer les champs comme bon vous semble.

Par exemple , vous pouvez ajouter «Révisé par» dans l'en-tête ou supprimer la date de création, etc. Également dans le tableau, vous pouvez inclure un champ «Créé par» pour désigner le testeur responsable d'un certain scénario de test ou supprimer le «Non. des cas de test ». Le choix t'appartient. Choisissez ce qui fonctionne le mieux pour toute l'équipe.

Passons maintenant en revue notre document Orange HRM SRS et créons les scénarios de test

Conseil pro: Consultez la table des matières de l'exemple SRS que nous avons fourni dans les premiers tutoriels pour avoir une bonne idée de la façon dont un document va se dérouler et de la quantité de travail qu'il pourrait impliquer.

Section 1 est le but du document. Aucune exigence testable là-bas.

Section 2.1 : Vue d'ensemble du projet - Public - pas d'exigences testables là non plus.

Section 2.2 : Matériel et Hébergement - Cette section traite de la manière dont le site Orange HRM va être hébergé. Maintenant, ces informations sont-elles importantes pour nous, testeurs? La réponse est oui et non. Oui, car lorsque nous testons, nous devons disposer d'un environnement similaire à l'environnement en temps réel.

Cela nous donne une idée de ce que cela doit être. Non, car ce n'est pas une exigence testable - une sorte de condition préalable pour que les tests aient lieu.

Section 3: Il y a un écran de connexion ici et les détails du type de compte dont nous avons besoin pour accéder au site. C'est une exigence testable. Il doit donc faire partie de nos scénarios de test.

Veuillez consulter le document de scénarios de test dans lequel des scénarios de test pour quelques sections du SRS ont été ajoutés. Pour la pratique, veuillez ajouter le reste des scénarios de la même manière. Cependant, je vais directement à la section 4 du document.

Section 4: Exigences et directives esthétiques / HTML - Cette section explique le mieux comment certaines exigences peuvent ne pas avoir de sens pour l'équipe de test au moment de la révision du SRS, mais l'équipe devrait tout de même les noter comme des exigences testables.

Comment les tester et si nous avons besoin d'une configuration spécifique / de l'aide d'une équipe pour le valider sont des détails que nous ne connaissons peut-être pas à ce stade. Mais les intégrer à notre périmètre de test est la première étape pour nous assurer de ne pas les manquer.

Exemples de scénarios de test pour l'application OrangeHRM: (cliquez pour agrandir l'image)

modèle de scénarios de test

=> Veuillez vous référer et télécharger le document Scénarios de test pour plus d'informations.

Quelques observations importantes concernant l'examen du SRS

#1) Aucune information ne doit être laissée à découvert.
#deux) Effectuer une analyse de faisabilité pour savoir si une certaine exigence est correcte ou non et également si elle peut être testée ou non.
# 3) Sauf s'il existe une performance / sécurité distincte ou toute autre forme d'équipes de test, il est de notre devoir de nous assurer que toutes les exigences non fonctionnelles doivent être prises en compte.
# 4) Toutes les informations ne sont pas destinées aux testeurs, il est donc important de comprendre ce qu'il faut noter et ce qui ne l'est pas.
# 5) L'importance et non. des cas de test pour un scénario de test n'ont pas besoin d'être précis et peuvent être remplis avec une valeur approximative ou peuvent être laissés vides.

Pour résumer, l'examen SRS aboutit à:

  • Liste des scénarios de test
  • Résultats de l'examen - Erreurs de documentation / d'exigence trouvées en parcourant / vérifiant statiquement le document SRS
  • Une liste de questions pour une meilleure compréhension - en cas de
  • L'idée préliminaire de la façon dont l'environnement de test est censé être
  • Identification de la portée du test et une idée approximative du nombre de cas de test que nous pourrions finir par avoir, donc de combien de temps nous avons besoin pour la documentation et finalement l'exécution.

Points importants à noter:

#1) Les scénarios de test ne sont pas des livrables externes (non partagés avec les analystes commerciaux ou les équipes de développement), mais sont importants pour la consommation interne du contrôle qualité. Ils constituent notre premier pas vers un objectif de couverture de test à 100%. Les scénarios de test une fois terminés font l'objet d'un examen par les pairs et une fois que cela est fait, ils sont tous consolidés.

Pour plus de détails sur la façon dont les documents d'assurance qualité sont examinés, consultez l'article: Comment effectuer des révisions de la documentation de test en 6 étapes simples.

#deux) Nous pourrions utiliser un outil de gestion de test comme HP ALM ou qTest pour créer les scénarios de test. Cependant, la création de scénarios de test en temps réel est une activité manuelle. À mon avis, c'est plus pratique manuellement. Comme il s'agit de l'étape 1, nous n'avons pas encore besoin de sortir les gros canons. Les feuilles Excel simples sont la meilleure façon de procéder.

La prochaine étape de cette série est que - nous travaillerons sur la création de cas de test et approfondirons la phase de conception des tests. Avant cela, nous entrerons également dans - Qu'est-ce que la planification des tests?Où cela s'inscrit-il dans l'ensemble du projet d'assurance qualité? Comme toujours, travaillez avec nous pour obtenir les meilleurs résultats.

Formation QA Jour 3: Comment rédiger un document SRS à partir de zéro.

Veuillez garder vos questions et commentaires à venir. Nous apprécions énormément votre lectorat!

lecture recommandée

^