Eh bien, voici une définition claire pour vous : une liste ordonnée de toutes les choses, entités logiques et physiques, matériaux, termes, objectifs, concepts qui doivent être mis en œuvre pour tester quelque chose, s'appelle un plan de test.

Il s'agit d'un document manuscrit que vous devez rédiger vous-même (c'est la première difficulté lorsqu'on travaille avec une telle documentation).

Souvent utilisé dans les entreprises et les situations où il est nécessaire de se mettre d'accord très précisément et clairement sur les objectifs des tests, la disponibilité physique ou logique des capacités de test...

Cela s'avère intelligent.

En général, si vous avez un client corrosif qui peut vous reprocher une erreur ou vous rejeter la responsabilité de certains problèmes, vous devez rédiger un document.

Ou si vous avez une équipe disparate et que vous devez créer une liste d'objectifs de test, de serveurs, de connexions et d'autres éléments importants accessibles aux deux parties, afin qu'à la fin, toutes les parties parlent de la même chose dans la même langue - vous besoin de rédiger un document.

Ou si vous êtes payé pour des heures de travail selon un plan spécifique, et non « en principe » et « en fin de compte », vous devez rédiger un document.

Ou si vous vous ennuyez et n'avez rien à faire au travail, vous devez rédiger un document.

Il comportera plusieurs sections avec des réponses détaillées (mot clé - détaillé) à un certain nombre de questions.

Les questions sont simples, mais les réponses peuvent être très ambiguës.

Par exemple:
— qu'allons-nous tester,
- pourquoi devons-nous tester ça,
— qui exactement va le tester, combien de personnes en ont besoin,
— où exactement nous allons tester cela (serveurs, ordinateurs, configuration informatique, logiciels, conditions météorologiques, etc.),
— combien de temps allons-nous tester cela,
— dans quel ordre allons-nous le tester,
— quels sont les domaines prioritaires,
— comment exactement nous allons le tester (les cas de test tombent généralement ici),
- à quelle période de la journée,
- et vous, si cette information est nécessaire et importante pour quelqu'un.

On suppose qu'un testeur intelligent lira ce blanc, n'y laissera que ce dont il a besoin, rayera ce qui n'est pas nécessaire et le plan sera prêt. La plupart des gens s'effondrent déjà à ce stade - est-il vraiment nécessaire d'écrire cela vous-même ?

On suppose qu'au cours du processus de travail sur le plan de test, tous les endroits sombres seront clarifiés, tous les détails seront réfléchis et tous les fonds nécessaires seront collectés pour que tout se passe bien.

Et puis, disent-ils, ce document servira à la fois de guide sur la qualité du travail effectué et de rapport.

Total : un plan de test est une liste détaillée de tout ce qui est nécessaire pour tester quelque chose.

Les buts, objectifs, ressources requises, détails techniques, personnes responsables, etc. sont indiqués. Toutes les informations nécessaires sont fournies, après lecture desquelles tout lecteur du document apprendra et comprendra tout ce qu'il voulait savoir et comprendre.

Permettez-moi de noter encore une fois qu'il faut y écrire ce qui est important, et pas tout à la suite, « juste pour l'avoir ».

Après rédaction, le plan de test doit être convenu avec tous les participants au développement qui ont eu besoin de ces tests. Étape difficile :)

Une fois l’accord et les ajustements effectués, vous pouvez commencer à travailler sur ce plan.

Les écarts doivent être corrigés, les changements doivent être reflétés et le résultat de tous les travaux doit être rendu aussi prévisible que possible.

En général, un plan de test est un plan d'action comportant des détails techniques.

Il est important de comprendre qu'il peut y avoir beaucoup d'informations à cet égard. Une personne doit décider ce qui doit être exactement contenu dans ce plan, les réponses à quelles questions doivent y figurer et lesquelles sont totalement inutiles, car personne n'en a besoin.

De tels documents sont très utiles dans la lutte contre les monstres qui disent « Et nous avons pensé que vous testeriez avec tel navigateur non standard et telle extension non standard - cela en soi est sous-entendu...« Rien ne va de soi et le plan permet de discuter de ces points séparément et spécifiquement. La paix mondiale et la liberté d’expression sont implicites, et tout ce qui est testé doit être clair et précis. Nous avions prévu de tester avec une extension de 800×600 = le recevoir et le signer.

La clarté et la clarté ne proviennent que d'instructions détaillées qui sont en discussion parties intéressées.

Un plan de test est un outil qui permet d’atteindre la clarté et le consensus.

Il existe des situations où un plan de test volumineux et beau n'est pas nécessaire. Et même nuisible.

Il existe des entreprises où vous pouvez tester sans spécifier au préalable les adresses de serveur, les connexions, les cas de test, etc. Il arrive qu'il n'y ait que deux testeurs pour dix programmeurs, et tous les détails sont déjà connus de tous, et toutes les tâches ont déjà été discutées, et rédiger un plan de test ne fera que provoquer des rires et des questions " Pourquoi était-ce nécessaire ? Quoi, tu as suivi un cours sur la rédaction de plans de tests ? Avez-vous lu suffisamment de livres ?»

En général, la partie la plus importante de la documentation du testeur est la liste des contrôles que les testeurs peuvent soumettre à l'application testée.

Parfois, cela ressemble à une liste de cas de test.

Parfois, il s'agit d'une liste de fonctionnalités - enfin, juste une liste.

Parfois, il s'agit d'une liste étendue et détaillée - les fonctionnalités sont triées par importance, par exemple, et leurs vérifications sont spécifiées séparément pour chaque élément.

Une simple liste de ce dont vous devez vous rappeler pour tester est une liste de contrôle.

Les listes de contrôle peuvent être différentes 🙂 Regardez ici - http://nrukol.blogspot.com/2010/11/blog-post_08.html - il y a un fichier qui doit être téléchargé et lu.

Le fichier montre en fait les étapes de détail de la liste de contrôle. Vous pouvez faire simple, et cela suffit. Vous pouvez entrer dans les détails en spécifiant non seulement CE QUI doit être testé, mais également COMMENT cela doit être testé.

La force d'un scénario de test est que tout ce qu'il contient est décrit de manière très, très détaillée, et avec l'aide de cas de test, même une personne qui n'a jamais vu l'application qu'elle teste peut tester. Mais quand tous ces détails doivent être mis à jour ou modifiés, cela devient aigre.

Le pouvoir d’une liste de contrôle est qu’elle est simple. Il n'y a pas de détails, c'est juste un rappel. Mais tester une application à l’aide d’une checklist tout de suite, sans préparation, sans comprendre ce que l’on entend par « Facturer une commande au back-office"(où est-ce ? Comment est-ce ? Qu'est-ce que c'est ? D'où vient cela et où ?) - impossible. Et le niveau de détail est faible. Regardons, par exemple, l'élément « Vérifier le paiement » – « Pass » y est marqué. Ok, comment puis-je m'assurer que le paiement a été vérifié en détail ? Le testeur qui a testé cela a-t-il réellement ajouté un article au panier des six manières possibles sur notre site ? Sans détails, PARFOIS c’est très difficile. Et parfois, les détails ne sont tout simplement pas requis.

Parfois, un plan de test n’est qu’une liste de contrôle très détaillée. Est-ce clair pourquoi ?

Et parfois, vous pouvez planifier les tests uniquement sur la base d'une liste de contrôle - celle-ci peut également servir de rapport de travail. Est-ce clair pourquoi ?

Par conséquent, ma substitution de concepts peut être légitime – dans une certaine mesure.

En général, il est impossible de se passer d'un plan de test - il est toujours là, sous quelque forme que ce soit, même si rien n'est décrit en détail, et tout n'est stocké que dans la tête du testeur.

Mais parfois, il est tout à fait possible de se passer d'un plan de test détaillé, ce que l'on entend par « document sympa, avec un tas de tableaux, graphiques, listes et autres conneries«.

J'espère que je ne vous ai pas confondu.

Comme

Les tests que nous avons effectués lors du dernier séminaire ne sont généralement pas effectués manuellement. À des fins de test, un programme spécial est écrit - un pilote de test qui effectue les tests. De plus, ces programmes sont souvent écrits dans un langage différent de celui du programme testé ou sont créés automatiquement à l'aide d'utilitaires spéciaux.

Dans cet atelier, nous écrirons nous-mêmes un pilote de test simple en C# pour tester les fonctions de la Calculatrice, en utilisant la spécification du deuxième atelier.

Commentaire. Le code du programme a été légèrement modifié pour simplifier la compilation des modules individuels. Ainsi, travailler avec la variable Program.res est exclu et la classe CalcClass est déclarée publique.

Examinons d’abord la fonction de division. Nous avons déjà établi des exigences de test pour cela. Par souci de simplicité, nous n’utiliserons que quatre exigences générales de test.

1. Les deux paramètres d'entrée appartiennent zone valide, et la valeur de sortie appartient à zone valide.
2. Le premier paramètre d'entrée appartient à zone valide, le deuxième n'appartient pas zone valide
3. Le premier paramètre d'entrée n'appartient pas zone valide, le deuxième appartient zone valide
4. Les deux paramètres d'entrée appartiennent zone valide, et la valeur de la fonction n'appartient pas zone valide.

Créons un programme :

Bouton vide privéStartDel_Click(expéditeur d'objet, EventArgs e) ( try ( richTextBox1.Text = ""; richTextBox1.Text += "Cas de test 1\n"; richTextBox1.Text += "Données d'entrée : a= 78508, b = -304 \n"; richTextBox1.Text += "Résultat attendu : res = 78204 && error = \"\""+"\n"; int res = CalcClass.Add(78508, -304); erreur de chaîne = CalcClass.lastError; richTextBox1.Text += "Code d'erreur : " + erreur + "\n"; richTextBox1.Text += "Résultat : " +"res = "+ res.ToString() +" error = "+error.ToString() + "\n"; if (res == 78204 && error == "") ( richTextBox1.Text += "Test réussi\n\n"; ) else ( richTextBox1.Text += "Le test a échoué\n\n "; ) ) catch (Exception ex) ( richTextBox1.Text += "Exception interceptée : " + ex.ToString() + "\nTest failed.\n"; ) try ( richTextBox1.Text += "Test Case 2\ n"; richTextBox1.Text += "Données d'entrée : a= -2850800078, b = 3000000000\n"; richTextBox1.Text += "Résultat attendu : res = 0 && error = \"Error 06\"\n"; .Ajouter(-2850800078, 3000000000); Text += "Code d'erreur : " + erreur +"\n" ; Inscription 7.1.

Texte du programme

Chaque scénario de test se trouve dans un bloc try-catch afin d'intercepter toute exception levée dans les méthodes Add().

Dans ce cas, le fichier CalcClass.dll, dans lequel toutes les méthodes mathématiques sont implémentées, doit être ajouté aux Références du projet.

Testons et obtenons le résultat suivant :

Scénario de test 1 Données d'entrée : a= 78508, b = -304 Résultat attendu : res = 78204 && error = "" Code d'erreur : Résultat : res = 78204 erreur = Test réussi Scénario de test 2 Données d'entrée : a= -2850800078, b = 3000000000 Résultat attendu : res = 0 && erreur = "Erreur 06" Code d'erreur : Erreur 06 Résultat : res = 0 erreur = Erreur 06 Test réussi Scénario de test 3 Données d'entrée : a = 3000000000, b = -2850800078 Résultat attendu : res = 0 && erreur = "Erreur 06" Code d'erreur : Erreur 06 Résultat : res = 0 erreur = Erreur 06 Test réussi Scénario de test 4 Données d'entrée : a= 2000000000, b = 2000000000 Résultat attendu : res = 0 && erreur = "Erreur 06" Erreur code : Erreur 06 Résultat : res = 0 erreur = Erreur 06 Test réussi On obtiendrait exactement le même résultat si, si les erreurs identifiées ont été corrigées. Notez qu'avec cette approche de test, nous sommes capables de localiser les erreurs. Si quelque chose ne fonctionne pas comme il se doit, nous pouvons alors affirmer avec certitude que l'erreur est contenue dans la fonction de division, alors que lors du dernier séminaire, nous ne pouvions pas dire exactement où elle s'est produite.

Commentaire. Nous pensons que le pilote de test lui-même est exempt d'erreurs. Tester le pilote de test dépasse le cadre du sujet étudié.

7.4. Documents à distribuer

7.4.1. Programme

Vous recevrez des fichiers .dll qui doivent être testés à l'aide de la méthode de la « boîte noire », ainsi qu'un exemple de pilote de test.

7.5. Devoirs

Créer un plan de test et réaliser tests unitaires méthodes suivantes :

Trouver le reste.

Si vous êtes développeur PHP et, pour diverses raisons, n'écrivez pas de tests pour vos applications, alors cet article est fait pour vous. Dans ce document, je vais essayer de montrer brièvement par où commencer et quoi faire pour que l'écriture de tests vous apporte joie et stabilité à votre candidature.

Alors, premier conseil. Oubliez tout ce que vous savez sur les tests unitaires. Jetez un tabouret à la personne qui vous a dit que vous ne pouviez pas vous en passer. Essayons de comprendre dans quels cas il est nécessaire de les utiliser et dans quels cas cela est inapproprié.

Je suis absolument sûr que les programmeurs PHP écrivent rarement des tests car ils commencent du mauvais côté. Tout le monde sait que les tests sont bons et cool. Mais après avoir ouvert le site Web du même PHPUnit et lu un exemple coloré sur le test d'une calculatrice capable d'effectuer l'opération a + b, ils se demandent : qu'est-ce que cette calculatrice a à voir avec mon application ? Réponse : aucun. Exactement comme tous les exemples similaires sur les sites d'autres frameworks de test. Comme si tout le monde avait oublié que PHP est avant tout destiné au web. C’est comme si tout le monde écrivait des calculatrices, et non des sites Web basés sur le paradigme MVC.

Disons que vous créez un site Web ou développez une application Web. Il contient déjà des pages, des formulaires et peut-être même des éléments interactifs. Comment vérifiez-vous (ou, disons, votre client) que le site fonctionne ? Vous allez sûrement sur le site, cliquez sur des liens, remplissez des formulaires, regardez le résultat. Et dans le bon sens, tous ces processus routiniers consistant à cliquer et à remplir des formulaires devraient avant tout être automatisés.

Et donc nous parlerons de tests fonctionnels (ou de recette).

Les tests fonctionnels sont des tests logiciels visant à vérifier la faisabilité des exigences fonctionnelles, c'est-à-dire la capacité du logiciel dans certaines conditions à résoudre les problèmes nécessaires aux utilisateurs. Les exigences fonctionnelles déterminent ce que fait exactement le logiciel et les tâches qu'il résout.

Pourquoi devriez-vous commencer à écrire des tests avec eux ? Oui, juste pour être sûr que votre site fonctionne et que tout y fonctionne. Les tests d'acceptation conviennent aussi bien à une application Web solide qu'à un site Web simple créé du jour au lendemain à genoux. C’est pourquoi cela vaut la peine de commencer par eux.

De quoi disposons-nous comme tests fonctionnels ? D'après tout ce que je sais, il s'agit de Codeception et, par exemple, PHPUnit + Mink ou de l'utilisation directe de Selenium. Je voulais inclure Behat dans ce cookie, mais son auteur a demandé n'utilisez pas Behat pour les tests fonctionnels.

Si tester avec Selenium ou PHPUnit + Mink était facile, vous les utiliseriez probablement déjà. Par conséquent, concentrons-nous sur Codeception.

Le test est décrit comme suit :

WantTo("voir que mon site fonctionne"); $Je->amOnPage("/"); $I->see("Bienvenue sur mon site !"); ?>

En quelques lignes seulement vous vérifiez qu’au moins la page principale de votre site s’ouvre. Après un travail de longue durée, le casser n'est pas si difficile.
De la même manière, vous pouvez décrire d'autres actions :

click("Commentaires"); $I->see("Envoyez vos commentaires"); $I->fillField("Body","Votre site est génial !"); $I->cliquez("Soumettre"); $I->see("Merci pour votre retour !"); ?>

Ici, nous vérifions déjà que le formulaire d'avis sur votre site fonctionne. Au moins, cela montre à l'utilisateur que son avis a été pris en compte.

Essayons maintenant de décider des tests unitaires.

Les tests unitaires, ou tests unitaires, sont un processus de programmation qui vous permet de vérifier l'exactitude des modules individuels du code source d'un programme.

L'idée est d'écrire des tests pour chaque fonction ou méthode non triviale. Cela vous permet de vérifier rapidement si le prochain changement de code a conduit à une régression, c'est-à-dire à l'apparition d'erreurs à des endroits déjà testés du programme, et facilite également la détection et l'élimination de ces erreurs.

Le problème avec leur utilisation est que les applications Web sont généralement basées sur des CMS ou des frameworks. Et parfois, il n'est pas toujours possible de sélectionner des modules spécifiques à tester. Cela devient particulièrement gênant lorsque la logique de l'application est dispersée entre différentes classes et que chaque unité spécifique ne fait pratiquement rien. Le processus de test sera encore compliqué par le fait que tous les modules sont interconnectés d'une manière ou d'une autre, ont de nombreuses méthodes et configurations héritées, et il est parfois très difficile de distinguer où se trouve votre code et où se trouve le code de la bibliothèque.

Mais si dans le cadre des tests fonctionnels vous avez vérifié tout ce que l'utilisateur peut faire, alors dans les tests unitaires, essayez de prendre en compte ce qu'il ne doit pas faire.

Par exemple, vérifiez si votre code vous permet de créer deux utilisateurs avec le même nom d'utilisateur. Vérifiez que lorsque vous essayez de créer un doublon, l'application ne plantera pas et n'affichera pas un écran blanc de la mort, mais interceptera l'erreur et montrera son texte à l'utilisateur. D'accord, l'utilisateur peut faire bien plus que ce que vous souhaitez. Il est donc parfois impossible de prévoir tous les scénarios possibles et de les couvrir par des tests fonctionnels.

Ou un autre exemple : vous avez une promotion sur votre site Web – chaque 100ème utilisateur enregistré reçoit un cadeau. Comment vérifier que les cadeaux sont distribués sans créer 100 utilisateurs supplémentaires ? C'est ici que vous écrivez des tests unitaires. Sans eux, il est fort probable que rien ne se passera.

Si votre application exprime clairement une logique métier, par exemple : « cette méthode crée un utilisateur, et cette méthode vous permet de modifier le statut d'un groupe », alors il est tout à fait raisonnable de couvrir ces méthodes avec des tests unitaires.

Et encore une chose : si vous créez un site Web ou une application basée sur votre propre framework, CMS, ou certains de vos propres modules pour ces frameworks et CMS, assurez-vous d'écrire des tests unitaires pour eux. Il n'y a aucune option ici. Si vous utilisez des solutions populaires tierces et ne réinventez pas la roue, il est fort probable que leur code ait déjà été testé par l'auteur et vous ne devriez pas vous attarder à les tester.

Il existe de nombreux frameworks pour les tests unitaires.

Aller à l'accueil Plan de test 1. ID Testing Notepad version 6.1 2. Introduction Ce document est un plan de test pour tester l'application de bureau Notepad version 6.1. Il décrit la stratégie et les approches en matière de tests de produits. Le plan permet de valider la qualité du logiciel. 3. Objets de test Voici une liste d'objets de test fonctionnel :  travailler avec des fichiers,  imprimer,  modifier les paramètres de fonctionnement,  éditer,  formater,  modifier la vue,  appeler l'aide 4. Qu'est-ce qui sera testé ? Fonctions du Bloc-notes, du point de vue de l'utilisateur, qui seront testées : - ouverture d'un fichier à l'aide du Bloc-notes ; - création de fichiers ; - clôturer la candidature ; - joint; - modifier les paramètres de fonctionnement ; - édition; - mise en forme ; - changement d'apparence ; - appeler à l'aide. 5. Qu'est-ce qui ne sera pas testé ? Fonctions du bloc-notes, du point de vue de l'utilisateur, qui ne seront pas testées : - Fonctions « Imprimer » - Plage de pages : sélection, sélection de pages, regroupement en copies. La première raison est la suivante : une imprimante physique ne sera pas utilisée pour les tests ; deuxièmement : cette fonctionnalité n'est pas active sur une imprimante virtuelle, et aussi pour l'impression vers un fichier. - Fonction « Paramètres de page » - méthode d'alimentation du papier. Raison - cette fonctionnalité n'est pas disponible sur l'imprimante virtuelle 6. Approche Lors des tests de l'application, des tests non fonctionnels seront effectués, à savoir : - tests d'interface - tests d'utilisabilité/utilisabilité Pour les tests fonctionnels, les techniques de tests suivantes seront utilisées : 1) Partitionnement en classes d'équivalence (Polices) 2 ) Analyse des valeurs limites (Polices) 3) Tests combinatoires. Il est nécessaire de rédiger un plan de test, indiquant respectivement toutes les exigences clés, les approches, ainsi que les responsabilités et les compétences. Aller à l'accueil Rédaction des cas de tests conformément aux responsabilités assignées, leur approbation obligatoire et leur entrée dans le système de gestion des tests. Lors de la création du dernier cas de test, établir une matrice de traçabilité des exigences et calculer la couverture des exigences par les tests. 7. Critères de réussite des tests Tous les cas de test hautement prioritaires sont clôturés avec un résultat « réussite ». La couverture des tests est vérifiée et est suffisante, lorsque le critère de suffisance est une couverture d'au moins 99 % des exigences par les tests. Le rapport de test est rédigé et approuvé par le responsable et le client. 8. Critères d'interruption et de poursuite des tests Le critère d'interruption des tests est l'apparition et l'entrée de bogues bloquants dans le système de suivi des bogues. Le critère pour poursuivre les tests est la fermeture d'un bug bloquant dans le système de suivi des bugs. 9. Résultats des tests Le résultat des tests est la réception des documents suivants : plan de tests, cas de tests, matrice de traçabilité des exigences. 10.Tâches de test Tâche Rédiger un plan de test Rédiger des cas de test Développer des critères de réussite des tests Réaliser des tests et évaluer les résultats Créer des rapports sur les résultats des tests Emplacement Créer un plan de test, responsabilités Objets de test, responsabilités Critères de réussite des tests Approche de test, responsabilités Résultats des tests 11. Exigences techniques Les tests de l'application auront lieu sur les systèmes d'exploitation suivants : Windows XP, Windows 7 12. Responsabilités Rôle n° 1 Lead 2 Testeur 3 Testeur Responsabilités Rédiger un plan de test ; rédiger des cas de tests pour tester les fonctions suivantes : ouverture, création, fermeture ; effectuer des tests fonctionnels manuellement ; élaboration d'une matrice de traçabilité des exigences. Rédaction de cas de tests pour tester la fonction suivante : sauvegarde ; effectuer des tests fonctionnels manuellement. Rédiger des cas de test pour tester les fonctions suivantes : Paramètres de page ; responsable de la mise en œuvre Pasechnik A. Tsimbalyuk A. Butenko A. Aller à l'accueil 4 Testeur 5 Testeur 6 Testeur 7 Testeur 8 Testeur 9 Testeur fonctionnel testeur manuellement Rédaction de cas de test pour tester la fonction suivante : impression ; effectuer des tests fonctionnels manuellement. Rédiger des cas de test pour tester la fonction suivante : Édition ; effectuer des tests fonctionnels manuellement Rédaction de cas de tests pour tester les fonctions suivantes : Format (sauf polices), Apparence, Aide ; effectuer des tests fonctionnels manuellement ; écrire des cas de test pour tester le menu contextuel ; effectuer des tests fonctionnels manuellement ; rédiger des cas de test pour tester les raccourcis clavier ; effectuer des tests fonctionnels manuellement. Rédaction de scénarios de test pour tester les polices ; mise en œuvre manuelle des tests fonctionnels Kosteva V. Kaverin A. Kononsky A. Miroshnik A. Polishchuk P. Miroshnichenko S. 13. Compétences et formation nécessaires Pour effectuer les tâches assignées, vous devez avoir les compétences suivantes : - connaissance et capacité à utiliser les règles pour rédiger des plans de tests, notamment basés sur la norme IEEE-829 ; - connaissance et capacité à appliquer les techniques de conception de tests - connaissance de différents types de tests, y compris fonctionnels et non fonctionnels, tels que les tests d'interface et d'utilisabilité - capacité à utiliser le système de gestion de tests choisi pour le projet en cours, etc. Formations nécessaires pour tester le projet : - formation sur le test des polices.=) - formation sur l'utilisation de logiciels spécifiques pour des tests d'utilisabilité meilleurs et plus complets 14. Calendrier/date limite Date limite d'approbation et d'inclusion de tous les cas de test dans le système de gestion des tests - 30/ 03 /2014 23:59:59 Date limite d'établissement des rapports 31/03/2014 23:59:59 Date limite du projet – 1/04/2014 19:00:00 15. Risques et leur élimination Risques possibles lors des tests : - Nombre insuffisant de ressources humaines pour tester l'application en temps opportun. Retour à l'accueil - Manque de matériel, logiciels, données ou outils nécessaires. - Modifications des exigences ou des instructions originales. - Le nombre de défauts acceptables sera augmenté. - L'équipe de test fera des heures supplémentaires. Cela peut avoir un impact négatif sur le moral de l’équipe. - Les portées du plan sont susceptibles de changer. - les tests d'application peuvent être simplement arrêtés (en cas extrême) 16. Approbation Approbation des cas de test – Responsable du test – Apiculteur Acceptation du projet terminé – Responsable – Anya =)

En parcourant récemment les forums et ressources dédiés aux tests logiciels, j'ai constaté un certain manque d'informations sur planification des tests. Plus précisément, il existe des informations, mais pas toujours sous une forme accessible. Je vais essayer de le décomposer et d'expliquer dans un langage simple "Qui ? Où ? Quand ?" traite de la planification et des informations qui doivent être incluses dans le plan de test. Commençons par la définition :

Plan de tests(Plan de test) est un document qui décrit l'ensemble de la portée des travaux de test, depuis la description de l'objet, la stratégie, le calendrier, les critères de début et de fin des tests, jusqu'à l'équipement requis dans le processus, les connaissances particulières, ainsi que l'évaluation des risques avec options pour leur résolution.

Chaque méthodologie ou processus tente de nous imposer ses propres formats de plan de test. Je vous propose, à titre d'exemple, modèles de plans de tests de RUP (Rational Unified Process) et Norme IEEE 829:

En y regardant de plus près, il apparaît clairement que les deux documents décrivent la même chose, mais sous des formes différentes. Si le modèle standard ne vous convient pas ou si vous décidez de créer votre propre format de document qui vous convient mieux, alors par expérience, je peux dire que bon plan de test doit au moins répondre aux questions suivantes :

1. ce qui doit être testé (objet de test : système, application, équipement)
2. qu'allez-vous tester (liste des fonctions et composants du système testé)
3. comment vous allez tester (stratégie de test - types de tests et leur application par rapport à l'objet testé)
4. quand allez-vous tester (séquence de travail : préparation, tests, analyse des résultats, dans le cadre des phases prévues de développement du projet)
5. critères de début et de fin des tests

Après avoir répondu aux questions ci-dessus dans votre plan de test, vous pouvez supposer que vous disposez déjà d’un bon projet de document de planification de test. Par ailleurs, afin que le document prenne un aspect moins sérieux, je propose de le compléter par les points suivants :

• Environnement du système testé
• Équipement et logiciels requis pour les tests
• Les risques et leur résolution

Types de plans de test

Le plus souvent, dans la pratique, nous rencontrons les types de plans de test suivants :

• Plan de test principal (plan directeur ou plan de test principal)
• Plan de test (je l'appelle un plan de test détaillé)

À mon avis, la différence évidente entre ces documents est que le plan de test principal est plus statique car il contient des informations de haut niveau qui ne sont pas sujettes à des changements fréquents au cours du processus de test et de révision des exigences. Le plan de test détaillé lui-même, qui contient des informations plus spécifiques sur la stratégie, les types de tests et le calendrier de travail, est un document « évolutif » qui subit constamment des modifications, reflétant l'état réel des choses sur le projet.

Dans la vie quotidienne, un projet peut avoir un plan de test principal et plusieurs plans de test détaillés décrivant les modules individuels d'une application.

Examen et approbation

Lorsqu'un document est rédigé par une seule personne, il s'avère unilatéral, je vous conseille donc de procéder à des révisions périodiques par les membres de l'équipe de projet, ainsi que d'effectuer la procédure d'approbation du document.
À titre d'exemple, voici une liste des membres de l'équipe de projet dont l'approbation me semble nécessaire :

• Testeur de plomb
• Responsable de tests (responsable qualité)
• Responsable du développement
• Chef de projet

Chacun des participants au projet répertoriés, avant approbation, procédera à un examen et formulera ses commentaires et suggestions qui contribueront à rendre votre plan de test plus complet et de meilleure qualité.

Conclusion

En utilisant les conseils ci-dessus, vous aurez plus de chances de rédiger un bon document plutôt que de tout inventer vous-même.
J'attends avec impatience vos questions et commentaires.

Les révisions et ajouts à l'article peuvent être trouvés sur le site Web de ProTesting - Plan de test

11 commentaires :

Commentaires anonymes...

Le matériel est utile, en effet, sur un nouveau lieu de travail, j'ai dû établir des plans de tests pour chaque itération de développement de produits et j'ai été confronté à un manque d'informations sur l'élaboration des plans.
Je l'ai fait selon le modèle existant des itérations précédentes sans grande compréhension. et quand j'ai mieux compris, j'ai réalisé ceci : il existe des plans de tests « pour le client » et « pour soi ».
Le plan personnalisé est une tentative de minimiser les risques. ils disent nous testons ceci et cela sur cet environnement.
et un plan pour vous-même est quelque chose qui vous aidera à ne pas vous perdre dans les exigences et les stratégies d'un projet complexe. C'est exactement le plan qui devrait être élaboré de manière plus réfléchie et plus claire. selon le plan que tu as proposé, Lyokha.
merci pour le message!

Sacha, merci pour le commentaire.
Je vais vous donner un conseil sur les différents plans de test. Il existe 2 plans de test : le plan de test principal et uniquement le plan de test...
D'après ce que je comprends, après avoir manipulé Internet et la documentation, un plan de test principal est établi pour les grands projets, où la fonctionnalité est divisée en plusieurs parties. Et tout y est décrit de manière assez superficielle à haut niveau, mais les détails commencent dans des plans de test spécifiques. Mais je pense ajouter un peu plus à l'article... Ici...

Commentaires anonymes...

Oui...
en fait, il s'agit d'un document assez important qui, dans la pratique, est constamment ignoré pour une raison quelconque. mais ce sont de bons anti-râteau !

Commentaires anonymes...

J'ai aimé la façon dont cela était présenté de manière logique et claire.

Des hauteurs de l'AQ, je suis descendu dans les basses terres du Québec et j'ai écrit cet ajout : Le plan de test doit être intelligible, clair, petit.

Ne considérez pas cela comme du spam ou une volonté de disperser des liens. Tout est pertinent. En complément du texte principal, mais à un niveau inférieur.

L'article est complètement inutile. Si le lecteur découvre quelque chose de nouveau dans cet article, alors l'article lui fera certainement du mal. Ma recommandation est de répondre d’abord vous-même à la question : pourquoi avez-vous besoin d’un plan de test ? A partir de votre réponse à cette question, vous recevrez toutes les informations nécessaires sur le contenu du plan de test. Si vous ne pouvez pas répondre, ne faites pas de plan de test, vous perdrez votre temps, vous n’avez pas encore mûri. Bonne chance à tous, Abbuk ;)