Phrases inachevées. Test psychologique

Le début représente la moitié de la bataille. Cette règle s'applique à presque tous les domaines d'activité, et même aux tests de logiciels.

Souvent, au début d'un projet, les testeurs font preuve d'enthousiasme en rédigeant de la documentation (stratégie de test, plan de test ou cas de test).

Mais à l’avenir, des difficultés surviennent souvent. Après avoir terminé la première série de tests, les testeurs trouvent généralement un certain nombre de bugs, puis abordent la deuxième série de manière quelque peu détendue. Il existe ce qu'on appelle le facteur humain et la tendance humaine universelle lorsqu'il devient ennuyeux d'effectuer des opérations répétées.

Dans de telles situations, de nombreuses personnes ont l'impression d'effectuer un travail monotone et, par conséquent, perdent tout intérêt à continuer de tester des logiciels déjà familiers. Et pendant environ le troisième tour, la question plane inexorablement sur le testeur : « Quand faut-il arrêter les tests ?

Chaque testeur a posé cette question au moins une fois, dont la version étendue ressemblerait à ceci :

De nombreux testeurs pensent qu'il n'y a pas conditions spéciales, indiquant que les tests doivent être terminés. Mais pour répondre à cette question, vous devrez analyser l’activité de test du début à la fin.

Disons que la tâche consiste à tester un nouveau projet.

Étapes initiales :

• L'équipe de test reçoit les exigences.
• Vient ensuite la planification et le développement.
• La documentation des tests est préparée et examinée .

Tests, tour n°1)

L'équipe de test commence les tests dès que le produit logiciel nouvellement créé lui est remis.

Pendant la phase de test, les testeurs exécutent divers scénarios pour tenter de cracker le logiciel et de découvrir des défauts. (Étant donné que l'application est nouvelle et évaluée pour la première fois, le taux de défauts trouvés sera relativement élevé.)

Les développeurs corrigent les défauts et renvoient le développement aux testeurs pour un nouveau test.

Les testeurs vérifient les défauts, puis passent à .

Une fois les défauts graves éliminés et le logiciel démontrant travail stable, l'équipe de développement publie la prochaine version.

Tests, tour n°2)

Les testeurs commencent la deuxième série de tests et répètent ce qui a été fait lors de la première série.

Au cours de ce processus, d'autres défauts sont généralement découverts.

Les développeurs corrigent les défauts et la demande est renvoyée pour examen.

Les testeurs effectuent des retests et des tests de régression sur les parties du développement qui n'ont pas changé.

Cela peut continuer à l’infini. Tour 3, 4, 5... jusqu'à logiciel ne sera pas du tout débarrassé des bugs.

Mais est-il théoriquement possible de trouver absolument tous les défauts ? C'est la question à un million de dollars, mais essayons d'y répondre.

La plupart des applications sont complexes, c'est pourquoi leur portée de test est assez large. Ce n’est pas qu’il soit totalement impossible de détecter absolument tous les défauts, mais cela prendra une éternité.

Même une fois que la plupart des bogues du logiciel ont été découverts, personne ne peut affirmer avec certitude que l'application est devenue parfaite.

De plus, une telle tâche n’en vaut pas la peine. Le but des tests logiciels est de s’assurer qu’ils sont fonctionnels et fonctionnent comme prévu. Ceci est réalisé grâce à des tentatives de piratage ou à la recherche d'écarts par rapport au comportement attendu.

Les candidatures peuvent avoir ensemble infini défauts, et il est peu pratique de les réaliser tant qu'ils ne sont pas complètement éliminés. On ne sait jamais quel bug sera le dernier.

Et si « l'arrêt des tests après élimination complète des défauts » n'est plus un critère, alors de quoi faut-il procéder ?

Essayons de déterminer quels facteurs doivent être considérés comme les plus importants ?

La décision d'arrêter les tests dépend généralement du temps (disponible), du budget et durée requise essai.

Le plus souvent, la décision de mettre fin aux tests est prise lorsque le temps/le budget est épuisé ou lorsque tous les scénarios de test sont terminés. Mais il s’agit d’une solution de compromis qui peut se faire au détriment de la qualité.

Exemple

Scénario de test :

Disons que vous devez tester un module logiciel ; un certain budget a été alloué pour ce travail. Durée : 1 mois. Total scénarios de tests : 200.

Scénario 1)

Première semaine: Vous avez réussi - le premier jour, vous avez trouvé le défaut de Show Stopper. Mais les tests se sont arrêtés pendant 3 jours. Vous ne pouvez pas vérifier d'autres scénarios tant que le bug découvert n'est pas corrigé. Après avoir perdu du temps, vous vous remettez au travail.

À la fin de la semaine, 20 scripts avaient été testés et plusieurs bugs encore plus dangereux avaient été découverts.

Semaine 2: Vous commencez à tester, en recherchant soigneusement les défauts. Durant la deuxième semaine, trouvez plusieurs bugs du 1er, 2ème et 3ème niveau de criticité. Pendant ce temps, nous avons réussi à tester 70 scénarios.

Semaine 3: Au début de la troisième semaine, tous les défauts hautement prioritaires ont été éliminés, mais désormais, en plus de l'exécution des scénarios en cours, une revérification des bugs précédemment découverts est également ajoutée. Au cours de la troisième semaine, vous avez couvert 120 scénarios et trouvé plusieurs autres bugs. Il ne reste plus qu'à rechercher les défauts de troisième ordre.

Semaine 4: Au début de la quatrième semaine, les défauts et les 80 scénarios restants doivent être revérifiés. À la fin de la semaine, vous avez testé 180 scénarios ; Tous les défauts hautement prioritaires ont été corrigés et retestés.

Les données sur les tests effectués sont placées dans le tableau :

Peut-être que c'est déjà suffisant ?

Le temps imparti pour les tests est expiré. Vous avez trouvé et éliminé un certain nombre de défauts de niveau 1. Si l’on s’arrête là, le logiciel développé peut-il être considéré comme fiable ? Pas vraiment, pour plusieurs raisons :

• Tous les scripts n'ont pas été testés.
• Plusieurs défauts potentiellement dangereux n'ont jamais été testés.
• Tous les scénarios testés n’ont été testés qu’une seule fois.
• Le logiciel présente encore des défauts.

Scénario n°2)

Semaine 1: Vous constatez un défaut de niveau 1 dès le premier jour de test. Et les tests sont reportés de 3 jours. Après avoir perdu trois jours, vous recommencez à travailler.

À la fin de la semaine, 20 scripts avaient été vérifiés et plusieurs défauts encore plus dangereux avaient été découverts.

Les résultats de la première semaine sont similaires à l'exemple n°1.

Semaine 2: Durant la deuxième semaine vous trouvez plusieurs bugs du 1er, 2ème et 3ème niveau de criticité. Mais le défi consiste désormais à couvrir autant de scénarios que possible. Au total, 120 scénarios d'ici la fin de la semaine.

Semaine 3: Au début de la troisième semaine, tous les défauts prioritaires ont été éliminés, et désormais, en plus des scénarios actuels, il est nécessaire de revérifier les défauts précédemment découverts. Au cours de la troisième semaine, vous avez couvert 200 scénarios et découvert un certain nombre de bugs supplémentaires.

Désormais, vous ne pouvez signaler que les défauts de niveau 2 et 3.

Données de test:

C'est assez?

Vous avez entièrement couvert tous les scénarios de test et trouvé plusieurs autres défauts. Si on s’arrête là, le logiciel peut-il être considéré comme fiable ?

Pas vraiment:

• Tous les scénarios ont été testés une seule fois.
• Le logiciel présente encore des défauts.
• Aucun test de régression n'a été effectué.

Comme vous pouvez le constater, les deux scénarios ne garantissent pas la qualité. La meilleure chose à faire dans une telle situation est d'essayer de trouver juste milieu, utilisez une approche qui prend tout en compte Meilleures caractéristiques des premier et deuxième scénarios. Pour ce faire, vous devrez définir un certain nombre de critères.

Critères d’achèvement ou de sortie

Le critère de sortie vous permet de déterminer quelle quantité de tests doit être considérée comme suffisante. Il est déterminé à la fin du cycle de tests et inclus dans le plan. Il s'agit d'un ensemble de conditions ou d'activités qui doivent être remplies pour que le test soit qualifié de terminé.

Que comprend le critère de sortie ?

Idéalement, il s’agit d’une combinaison de plusieurs facteurs propres à tout projet. Tout dépend des exigences d'un projet spécifique. Par conséquent, lors de la planification, il est conseillé de calculer autant de paramètres que possible.

Vous trouverez ci-dessous quelques nuances à prendre en compte pendant ou. Vous pouvez créer une combinaison spécifique ou utiliser tous ces facteurs pour déterminer exactement quand terminer les tests.

Les tests peuvent être effectués lorsque :

• 100% des exigences sont prises en compte.
• Défauts identifiés/nombre attendu de défauts détectés.
• Tous les défauts classés comme Show Stopper ou Blocker ont été corrigés ; aucun des défauts critiques n'a le statut « ouvert ».
• Tous les défauts hautement prioritaires ont été identifiés et corrigés.
• Le taux de défauts est inférieur au niveau acceptable établi.
• Un très petit nombre de défauts de criticité moyenne ont été « ouverts » et analysés.
• Le nombre de défauts « ouverts » de niveau intermédiaire qui n’affectent pas l’utilisation du système est très faible.
• Tous les défauts avec haut niveau les priorités ont été clôturées et les scénarios de régression correspondants ont été réalisés avec succès.

Couverture de test:

• La couverture des tests doit être de 95 %.
• Le taux de réussite de la casse texte doit également être de 95 %. Pour calculer ce pourcentage, la formule est utilisée :

(Nombre total de cas de texte réussis / nombre total de cas de test) * 100.

• Tous les cas de tests critiques ont réussi
• 5 % des cas de test peuvent échouer, mais cela s'applique aux cas peu prioritaires.
• La couverture complète des fonctionnalités a été atteinte.
• Tous les défauts fonctionnels majeurs ont été éliminés avec succès.

Délais :

La période allouée aux tests est expirée.

Documentation des tests :

Toute la documentation de test due (par exemple le rapport de test) est préparée, examinée et soumise.

Budget:

• Le budget alloué aux tests a été entièrement dépensé.
• Des réunions au format « Go / No Go » ont eu lieu, la décision de sortir le produit a été prise.

Enfin, veuillez répondre à quelques questions.

Si la majorité des réponses sont oui, cela signifie que vous pouvez passer le test. Si la plupart des réponses sont négatives, vous devrez alors rechercher ce qui a été manqué.

• Tous les cas de test ont-ils été testés au moins une fois ?
• Existe-t-il un taux de réussite des cas de test (Test Case Pass) ?
• La couverture complète des tests a-t-elle été atteinte ?
• Tous les flux fonctionnels/métier sont-ils testés au moins une fois ?
• Le nombre spécifié de défauts a-t-il été constaté ?
• Tous les défauts hautement prioritaires ont-ils été résolus et « fermés » ?
• Tous les défauts ont-ils été retestés et considérés comme « fermés » ?
• Des tests de régression ont-ils été effectués sur tous les défauts « ouverts » ?
• Le budget alloué aux tests est-il épuisé ?
• La période de test est-elle expirée ?
• Toute la documentation des tests a-t-elle été examinée et publiée ?

Quand faut-il arrêter les tests et faut-il les arrêter ? L’intégralité des informations a-t-elle été traitée et tout a-t-il été pris en compte ? Et d'une manière générale - ? Ces questions sont pertinentes pour chaque testeur. Alors arrêtons-nous une minute et réfléchissons : à quel moment est-il nécessaire et possible d'interrompre le processus de test tendant vers l'infini ?

Raison de l’arrêt : « Les délais approchent ! Le temps, c'est de l'argent!"

Il existe souvent des délais clairement définis pour un projet, que le client n'est pas toujours prêt à avancer. Dans ce cas, la commande « terminer le test ! » dépend justement des délais, et c’est un critère important. Oui, un tel scénario ne peut pas être qualifié de meilleur (car il n'y a toujours pas assez de temps pour un contrôle complet et la qualité en souffre souvent), mais il est également possible.

Exemple tiré de la pratique. Je me souviens d'une situation où la qualité d'un produit souffrait en raison de délais serrés. Une boutique en ligne d'articles ménagers a été testée et, en plus d'une nouvelle remise promotionnelle réservée aux clients enregistrés, un bug a été introduit : l'impossibilité d'activer plusieurs promotions en vigueur à ce moment-là. Ainsi, la version s’est transformée en « une version plus quelques jours plus intenses de correction de bugs ». Il aurait probablement été bien préférable de déplacer les limites strictes d'un jour ou deux et de donner la possibilité de tester davantage les nouvelles fonctionnalités... mais dans la vie, il y a différentes situations.

Conclusion. La tâche principale testeur dans des conditions de temps limité doit couvrir autant que possible quantité possible cas de test critiques (cas de test de priorité élevée et moyenne), enregistrant tous les défauts trouvés (pour éviter leur perte en raison du temps et de la rotation des tâches) et générant un message sur la quantité réelle de travail effectué. En conséquence, le testeur devrait recevoir image complète vérifié et une liste de ce qui n'a pas encore été vérifié (afin de déterminer davantage l'étendue des travaux).

Raison de l’arrêt : « Ce n’est pas le final, mais un intermédiaire »

Il arrive que pendant le test, il soit nécessaire de procéder à un arrêt forcé, car « quelque chose » bloque de manière critique l'évaluation optimale de l'objet testé, et de ce fait, l'ensemble du système de test peut « échouer » à l'avenir. Dans ce cas, il vaut mieux s'arrêter et attendre que le problème soit résolu.

Exemple tiré de la pratique. Un logiciel médical assez volumineux a été testé. Sur le banc d'essai, il n'a pas été possible de tester complètement la nouvelle fonctionnalité (envoi de lettres aux clients lors du remplissage du formulaire et des données compte personnel client). La tâche était assez vaste et couvrait de nombreux aspects : activation de sections individuelles lorsque les documents sont complètement chargés, restrictions d'accès aux sections lorsque dans une certaine mesure remplir votre profil et autres. A la question avant la sortie, "est-ce que tout a été testé et est-il possible de terminer les tests ?" Il était tout simplement impossible de donner une réponse sans ambiguïté : le contrôle a été partiellement bloqué en raison de l'impossibilité de vérifier la réception de certaines lettres dans l'environnement de test. En conséquence, des erreurs critiques sont apparues côté client lors de la publication. Le client n'a pas reçu les lettres de notification nécessaires et n'a donc pas pu obtenir un accès complet à son profil. Pour éviter de telles situations, il a été constaté solution suivante: après modification, des options d'envoi et de réception de courriers sur banc de test sont devenues disponibles, ce qui a permis de tester davantage cette partie de fonctionnalité assez importante. L'inclusion de ces contrôles dans toutes les passes de régression ultérieures a permis d'évaluer de manière plus optimale l'état de préparation du produit avant de le publier côté client.

Conclusion. L'analyse des erreurs nous a permis de tirer les bonnes conclusions et d'éliminer tous les problèmes bloquants. Et pourtant, dans situation similaire les travaux d'optimisation des outils de test et des outils basés sur des erreurs déjà identifiées peuvent difficilement être envisagés bonne option. Sans aucun doute, il serait beaucoup plus approprié et correct d'arrêter le processus de test et d'affiner les fonctionnalités initialement incomplètes de l'environnement de test afin d'éviter l'émergence de moments critiques déjà du côté client.

Raison de l’arrêt : « Vous ne pouvez pas avancer si vous restez immobile. » Où mettre la virgule et pourquoi y a-t-il confusion ?

Est-il correct de corriger les bugs directement pendant le test, qui n'est pas interrompu ? La logique veut que le processus soit arrêté et redémarré dès le début après avoir effectué un ajustement, car toute correction d'une erreur peut entraîner l'apparition d'une douzaine de nouvelles.

Exemple tiré de la pratique. Un cas assez courant, connu de tout testeur, vient immédiatement à l'esprit : lors des tests, des bugs critiques sont découverts, et la moitié des cas de test ont déjà été vérifiés, et leurs résultats sont enregistrés. Parfois, les développeurs essaient de corriger un bug si rapidement qu'ils « oublient » d'avertir le testeur assidu, pressé de parcourir tous les cas de tests de régression prévus. En conséquence, les tests continuent après la correction du bug au lieu d'arrêter le test et de le redémarrer ; Certaines erreurs ne seront plus détectées.

Conclusion. Dans de telles situations, il est important que le développeur signale rapidement ses corrections au testeur afin qu'il puisse arrêter les tests et repasser les cas de test - tous ou seulement les plus critiques et les plus prioritaires (s'il ne reste plus beaucoup de temps). ). Cela permettra d'éviter toute confusion future sur la question : d'où proviennent les nouveaux défauts du produit et qui en est responsable ?

Raison de l’arrêt : « L’ordre est arrivé de battre en retraite ! »

Il arrive que le client littéralement dernière étape met l'analyse en pause. Il peut y avoir de nombreuses raisons à cela : l'émergence de plus tâche importante ou fonctionnalité qui nécessite des éclaircissements supplémentaires, une réévaluation des priorités de publication, une révision du plan de ce moment. Notre tâche est de suspendre le processus, mais de ne rien oublier !

Exemple tiré de la pratique. Il est arrivé qu'une version presque entièrement testée ait été reportée. Il semblerait que tout soit prêt - tous les blocs ont été minutieusement testés, toutes les tâches sont terminées - et vous pouvez publier le produit fini pour le plus grand plaisir de l'utilisateur, mais le client décide soudain qu'il vaut mieux tout faire complètement différemment, et la version presque prête doit être temporairement arrêtée. L’inconvénient de cette situation est la perte de temps du testeur, l’avantage réside dans les cas de test écrits qui peuvent être utilisés pour tester les fonctionnalités d’autres logiciels.

Conclusion. Dans ce cas, il est important pour un testeur d'écrire des cas de test de haute qualité avec lesquels il pourra travailler à l'avenir soit sur des tâches similaires, soit (en cas de reprise du travail) sur une version annulée/reportée.

Raison de l’arrêt : « Ça y est, je suis fatigué, ça suffit ! »

Un arrêt peut aussi survenir simplement parce que la tension a atteint son paroxysme. Le désir de faire le plus possible en le moins de temps possible temps possible a parfois un impact négatif sur les résultats du travail.

Exemple tiré de la pratique. Un de nos projets a connu une sortie assez longue ; nous l'avons testé intensément et activement. Les tests dans ma tête ne se sont pas arrêtés même pendant que je dormais. Et à ce moment-là, lorsque l'erreur est apparue littéralement sous mes yeux, me la « signalant » clairement dans les journaux, je ne l'ai tout simplement pas vue. Dans de tels moments, il faut pouvoir se dire : « Arrête, fais une pause, sinon tu vas te tromper, tu vas rater un bug, ton attention sera nulle ! Et l'attention est la principale qualité d'un testeur. Bien sûr, le processus lui-même ne peut pas être simplement arrêté, mais il est nécessaire de prévoir du temps personnel pour se détendre !

Conclusion. DANS cas similaires l'arrêt des tests est obligatoire et point important pour le testeur. À la fin du travail, il faut se reposer et se distraire (faire autre chose par exemple), afin d’éviter de « se brouiller les yeux ».

Raison de l’arrêt : « Des doutes ? Arrêt!"

Avant la sortie de chaque version, le testeur, évaluant le travail effectué et l'ensemble des cas de tests complétés, résume : tout a-t-il été testé ? Certainement, état naturel il y aura une volonté de poursuivre le processus de vérification, ce qui ne correspond pas toujours au facteur temps. Pourtant, des doutes raisonnables doivent au moins être exprimés. Même si le bug a été « détecté » à la dernière étape et que sa correction retardera l'ensemble du processus de publication, l'erreur ne doit en aucun cas être laissée sans surveillance ;

Exemple tiré de la pratique. D'après mon expérience, il y avait des situations où l'erreur était déjà découverte dans les dernières étapes (on pourrait même dire au dernières minutes) les tests de régression. Était-ce la faute d'un testeur (c'est-à-dire la mienne) ? Oui, et c'était un bon coup de pied pour la poursuite des travaux sur vos erreurs. Mais il fallait éradiquer le bug. Le problème a été « éliminé » de la version pour amélioration, mais la version elle-même a été plutôt réussie. N’oubliez pas : le client préfère apprécier la qualité du contrôle plutôt que de respecter les délais sans maintenir la qualité.

Conclusion. Chaque étape du processus de test est importante. Un développement incorrect du matériel ou une couverture incomplète de la tâche avec des cas de test peuvent amener le testeur à manquer un bug important et critique. Quelle que soit l'étape de test découverte, il est important de comprendre que dans de tels cas, il est nécessaire de s'arrêter, d'évaluer la situation et de prendre une décision. plan supplémentaire travaux!

Raison de l’arrêt : « Selon mon envie, arrête ! »

En test rôle important joue un rôle dans la compréhension par le spécialiste de l’importance du produit fabriqué. C'est mauvais si une personne est indifférente au produit final. Dans ce cas, les tests peuvent s’arrêter simplement parce que le testeur est fatigué du processus lui-même (« ça fera l’affaire de toute façon ! »).

A cette occasion, une vieille blague me vient à l’esprit :
« L’homme a cousu un costume en studio. Je suis rentré à la maison et je l'ai mis. La femme est terrifiée :
- Qu'as-tu cousu ? Regardez : une manche est plus longue, l'autre est plus courte. Les ourlets de la veste et les jambes du pantalon sont différents. Ramenez tout ça !
Le mari revint :
- Qu'est-ce que tu m'as cousu ? Regarder! Des pantalons de différentes longueurs !
– Et tu plies une jambe au niveau du genou, parce que tu ne marches pas sur les jambes droites. Et tout ira bien.
– Regardez, les manches sont de différentes longueurs !
- Et alors? Vous ne tenez pas vos mains à vos côtés. Pliez les coudes. Ici! Merveilleux!
- Et les sols ? Que faire avec eux?
- Et tu te penches un peu d'un côté. Tout va bien!
L'homme est sorti dans un nouveau costume. Personnes à l'arrêt de bus :
- Écoute, quel monstre ! Et comme le costume lui va bien !

Pour un testeur, une attitude négligente envers le processus est tout simplement inacceptable. Toutes les lacunes finissent par devenir apparentes, ce qui conduit finalement à des résultats désastreux.

Exemple tiré de la pratique. Heureusement, mes collègues et moi n'avons jamais rencontré de telles situations : nous aimons notre travail et respectons les utilisateurs finaux (après tout, nos erreurs affectent leur expérience d'interaction avec le produit). J'espère que quelque chose comme ça n'arrivera jamais. L'essentiel est de ne pas oublier que cela est possible et d'éviter de tels cas.

Conclusion. Il est impossible d'arrêter les tests uniquement à la demande du testeur ; chaque arrêt doit être justifié. La décision d'arrêter le processus ne sera logique que si tout un ensemble de paramètres a été complété et minutieusement élaboré de manière optimale et positive : l'ensemble des cas de test pour la tâche a été rédigé, les priorités ont été correctement définies pour estimer le temps au cas où de contrôles urgents ou rapides, toutes les tâches ont été entièrement analysées et vérifiées avec les exigences techniques de retour à étapes initiales familiarisation, tout est pris en compte dès la phase de planification de la sortie.

Et enfin... Roulements de tambour... Dernière raison, mais la plus souhaitable, pour s'arrêter : « À vos marques, vous pouvez le récupérer ! »

Lorsque la planification d'une nouvelle version commence, un plan de test spécifique, des priorités et une portée sont définis. Une bonne planification mène à des résultats positifs et des résultats de qualité. Lorsque tous les résultats des tests satisfont pleinement aux critères de qualité, vous pouvez vous dire en toute sécurité : « Arrêtez, ici nous avons fait tout ce que nous pouvions ! Mais pour cela, il est nécessaire que toutes les erreurs trouvées soient corrigées, que tous les cas de test prévus soient réussis (et qu'aucun bug supérieur à mineur ne soit trouvé), que toutes les modifications nécessaires soient apportées et que le résultat des tests d'acceptation soit totalement positif. Et cela arrive réellement ! Dans ce cas, le client est satisfait et le testeur peut se donner en toute sécurité une « médaille » pour Bon travail. Et comment cela vous prépare à d’autres « exploits » !

Exemple tiré de la pratique. Par exemple, nous avons testé il y a quelque temps la mise à jour du site Internet dédié aux appareils électroménagers. Le site était et continue d'être très populaire et la responsabilité du produit était assez élevée. Le résultat de cette publication a été une dynamique positive et une amélioration des statistiques sur le nombre d'utilisateurs ayant passé une commande via Internet. Bien entendu, cela constitue un énorme avantage pour le client. Le principal indicateur d'une version réussie pour les testeurs est un produit adapté au maximum au client et contenant quantité minimale erreurs (ou peut-être qu’il n’y en a plus du tout ?!!!). L'arrêt des tests dans ce cas est tout à fait naturel, puisqu'il est fixé dans un délai clairement établi, prenant en compte tous les critères nécessaires.

Conclusion. Pour obtenir bon résultat Il est important de prendre en compte tous les facteurs dans votre travail. Évaluer et analyser une tâche, rédiger des cas de test pour la couvrir, calculer le temps et un soin maximum garantissent des résultats positifs dans votre travail.

Le final

Pour résumer, on peut dire que dernier scénario- Ce option parfaite arrêter les tests : il combine une planification appropriée, des tests détaillés et une partie d'acceptation finale positive. Dans d'autres cas, des arrêts surviennent en raison d'erreurs de testeurs, à la demande du client, d'un plan de test insuffisamment réfléchi, d'un timing incorrect, ou simplement par paresse (d'ailleurs, qualité inacceptable dans notre métier).

Par conséquent, les arrêts dans de tels cas n'entraînent pas cette résultat positif ce que vous voulez toujours réaliser. Dans cette situation, il est important de tirer les bonnes conclusions et d’identifier la cause de l’erreur principale. En règle générale, il s'agit d'une mauvaise planification du temps, de la peur de demander au développeur si les correctifs sont prêts (c'est-à-dire d'une mauvaise communication entre le développeur et le testeur) et d'une rédaction négligente des cas de test en raison d'une familiarisation incomplète avec les spécifications et les exigences. Ayant identifié points faibles sur un projet ou à titre personnel, vous pouvez commencer à élaborer un plan pour un travail ultérieur plus efficace.

Pour ce faire, il est toujours nécessaire de prendre en compte : les conditions et souhaits du client, le délai établi et la mesure dans laquelle les cas de test couvrent les exigences spécifiées et décrites dans la tâche. Chaque point doit être clairement élaboré et discuté avec le client et le développeur. Le testeur doit imaginer l'étendue du travail : quel type de test peut être effectué dans le délai spécifié, combien de cas de test seront nécessaires, jusqu'à quel point les corrections de bogues sont autorisées, quand le code de gel commence et si le nombre de les bugs trouvés permettent la sortie du produit lui-même.

Bien entendu, chaque projet a ses propres caractéristiques. Il est impossible de trouver une seule méthode de solution de référence correcte. Et pourtant, la prise en compte des critères de base ci-dessus conduira au fait que le produit fabriqué répondra au mieux aux exigences, et que le processus et l'arrêt des tests seront clairs et logiques.

Organisation du processus de tests. Le développement de logiciels est en grande partie un processus de communication d'informations sur le programme final et de traduction de ces informations d'une forme à une autre. En outre, la très grande majorité des erreurs logicielles sont causées par des défauts dans l'organisation du travail, une compréhension mutuelle insuffisante et des distorsions dans le processus de transmission et de traduction des informations.

En améliorant la clarté du processus de développement lui-même, de nombreuses erreurs peuvent être évitées. Cela conduit au fait qu'à la fin de chaque étape, il est nécessaire d'inclure une étape de vérification distincte visant à localiser le plus grand nombre erreurs avant de passer à l’étape suivante. Par exemple, la spécification est vérifiée en la comparant avec le résultat de l'étape précédente, et chaque erreur trouvée est renvoyée au processus de développement de la spécification pour correction.

De plus, des processus de tests spécifiques doivent être axés sur étapes spécifiques développement. Cela concentre chaque processus de test sur une étape de traduction, ce qui entraîne la capture d'une classe spécifique d'erreurs.

Relation entre les processus de développement et de test.

Le processus de test proprement dit commence par la vérification du code source. À cette fin, des méthodes de tests statiques sont utilisées.

Viennent ensuite les tests des modules, axés sur la vérification du respect des spécifications de l'interface du module, ainsi que les tests de l'interface et les résultats d'assemblage de la structure modulaire, axés sur la vérification de la conformité avec la conception du système et (ou) la conception de la structure d’un programme distinct.

Viennent ensuite les tests fonctionnels, qui consistent à trouver les différences entre le programme et sa spécification externe. Lors du test des fonctions, des techniques de tests fonctionnels sont généralement utilisées. On suppose qu'à un stade antérieur du test des modules, le critère de couverture logique requis, caractéristique des méthodes essais structurels, est satisfait.

Pour comparer les résultats de développement avec les objectifs initiaux, un processus de tests complets apparaît, ou, comme on l'appelle également, des tests système, dans lesquels tous les logiciels sont testés dans leur ensemble. Lorsque l'on considère les différences entre les résultats obtenus et les objectifs initiaux du développement logiciel la plus grande attention se concentre sur l’identification des erreurs de traduction qui surviennent lors du développement d’une spécification externe. Des tests complets sont donc indispensables, car c'est à ce stade que les erreurs les plus graves sont découvertes.

Le processus de test se termine par le test du logiciel. Les tests permettent de vérifier l'exhaustivité de la solution tâches fonctionnelles, leur qualité et leur conformité aux logiciels et à la documentation technique.

Test du système. Contrairement aux tests de fonctionnalités, une spécification externe ne peut pas être utilisée comme base pour dériver des tests système, car cela irait à l’encontre de l’objectif de ces tests. En revanche, un document reflétant les objectifs du système en tant que tel (dans notre cas, il s'agit d'une spécification technique) ne peut pas être utilisé pour formuler ses tests, car par définition il ne contient pas de descriptions précises.

Le problème est résolu en utilisant la documentation utilisateur opérationnelle. Les tests du système sont conçus sur la base d'une analyse de ses objectifs basée sur les résultats de l'étude de la documentation utilisateur. Cette pratique permet de comparer non seulement le programme avec le document source, mais également les résultats de son fonctionnement avec la documentation utilisateur, ainsi que la documentation utilisateur avec le document source.

Il existe plusieurs catégories de tests, chacune visant à tester des objectifs spécifiques. Ceux-ci incluent les tests d'exhaustivité de la mise en œuvre, les tests de limite de volume, les tests de limite de charge, les tests d'utilisabilité, les tests de sécurité, les tests de configuration matérielle, les tests de compatibilité, les tests de fiabilité, les tests de récupération, les tests de maintenabilité, les tests d'utilisabilité de l'installation et les tests de documentation.

Tester l’exhaustivité de la mise en œuvre est le type de test système le plus évident, qui consiste à vérifier la mise en œuvre de chaque point du document source. La procédure de vérification consiste à examiner séquentiellement le document source, phrase par phrase. Si la phrase contient tâche spécifique, puis déterminez si le programme effectue cette tâche.

Le test limite consiste à exécuter le programme à gros volumes données, dépassant de préférence le volume opérationnel proposé. Par exemple, un grand programme source est envoyé à l'entrée du compilateur à titre de test, un programme contenant un millier de modules est envoyé à l'entrée de l'éditeur de liens et un programme de simulation est envoyé à l'entrée. circuits électroniques- un circuit contenant des milliers de composants. Le but des tests de capacité est de démontrer que le programme ne peut pas gérer la quantité de données spécifiée dans ses objectifs initiaux.

Les tests à des charges extrêmes sont dus au fait que le besoin en ressources mémoire et en performances dans le processus de résolution d'un problème sur un ordinateur varie considérablement en fonction de la composition du volume des données source. Avec une forte intensité de données d'entrée, l'équilibre temporel entre la durée de résolution d'un ensemble de problèmes logiciels en temps réel et les performances réelles de l'ordinateur pour résoudre ces problèmes peut être perturbé. Le but des tests de charge extrême est de montrer que le logiciel n’atteint pas les objectifs de performances.

Les tests d'utilisabilité consistent à identifier les problèmes psychologiques (de l'utilisateur) qui surviennent pendant le fonctionnement. Ces tests devraient établir, au minimum, les éléments suivants :

1. Est-il possible d'adapter l'interface développée pour informer et former l'utilisateur final, ainsi que pour assurer son travail dans conditions réelles?
2. Les messages de sortie du programme sont-ils significatifs, clairs et non offensants ?
3. Le diagnostic d'erreur est-il clair ?
4. L’ensemble des interfaces utilisateur présente-t-il une cohérence et une uniformité en termes de syntaxe, de conventions, de sémantique, de format, de style et d’abréviations ?
5. Le système contient-il des options excessives ou peu susceptibles d’être utilisées ?
6. Le système émet-il des accusés de réception pour tous les messages d'entrée ?
7. Le logiciel est-il simple et agréable à utiliser ?

Les tests de sécurité consistent à vérifier si les informations sont protégées contre tout accès non autorisé. Pour tester la sécurité, il est important de créer des tests qui violent la sécurité des logiciels. Une façon de développer de tels tests est d'étudier Problèmes connus protection dans de tels systèmes existants et créer des tests qui vous permettent de vérifier comment des problèmes similaires sont résolus dans le système testé.

Les tests de configuration matérielle sont motivés par le fait que les systèmes d'exploitation, les systèmes de gestion de bases de données et les systèmes de communication doivent prendre en charge plusieurs configurations matérielles (par exemple, Divers types et le nombre de périphériques d'entrée/sortie et de lignes de communication, diverses quantités de mémoire, etc.). Souvent le nombre de configurations possibles est trop important pour tester le logiciel sur chacune d’elles. Cependant, le programme doit être testé avec au moins chaque type de matériel dans les configurations minimale et maximale. Si vous pouvez modifier la configuration du logiciel lui-même, vous devez alors tester toutes ses configurations possibles.

Les tests de compatibilité sont motivés par le fait que la plupart des logiciels développés ne sont pas complètement nouveaux. Il remplace souvent des systèmes de traitement de l’information ou des processus manuels imparfaits et obsolètes. Ainsi, lors du développement de logiciels, il est nécessaire de s'assurer de la compatibilité avec l'environnement dans lequel fonctionnaient les systèmes remplacés et, si nécessaire, de créer des procédures de conversion pour assurer le passage d'un mode de traitement des données à un autre. Dans ce cas, comme pour d’autres formes de tests, les tests doivent viser à garantir la compatibilité et le fonctionnement de la procédure de conversion.

Le but de tous les types de tests est d'augmenter la fiabilité du logiciel, mais si le document source reflétant les objectifs du projet contient des instructions spéciales, par exemple pour garantir certaine heure Le MTBF ou le nombre d'erreurs admissible est spécifié, il est alors nécessaire de mener une étude du logiciel testé pour satisfaire à ces exigences. Cela se fait grâce à des tests de fiabilité. Il y a plusieurs jours pour ce type de test. modèles mathématiques fiabilité. Ensuite, dans la section sur les critères de réalisation des tests, deux modèles de fiabilité seront considérés : le modèle dit de Mills et un modèle simple et intuitif.

Pour système opérateur, les SGBD et les télécommunications définissent souvent la manière dont le système doit se remettre des erreurs logicielles, des pannes matérielles et des erreurs de données. Lors du test du système, il est nécessaire de montrer que ces fonctions ne sont pas exécutées. Des tests de récupération sont utilisés à cette fin. Pour ce faire, vous pouvez délibérément introduire des erreurs logicielles dans le système pour voir s'il sera récupéré une fois éliminées. Les pannes matérielles peuvent être simulées. Des erreurs dans les données (interférences dans les lignes de communication ou valeurs incorrectes des pointeurs dans la base de données) peuvent être intentionnellement créées ou simulées.

Parfois, le document source contient fins spéciales facilité de maintenance ou de maintenance logicielle. Ils peuvent définir les outils de maintenance dont le logiciel doit être doté (par exemple, programmes de vidage mémoire, programmes de diagnostic, etc.), le temps moyen pour trouver un bug, les procédures associées à la maintenance et la qualité de la documentation sur les systèmes internes. logique du programme. Bien entendu, tous ces objectifs doivent être testés. À cette fin, des tests d’utilisabilité sont utilisés.

Le but des tests de facilité d'installation est de montrer que les objectifs de personnalisation du logiciel pour des conditions de fonctionnement spécifiques ne sont pas atteints.

La vérification du système comprend également la vérification de l'exactitude de la documentation utilisateur. La plupart de Cette vérification a lieu lors de la détermination de l'exactitude des tests système précédents. De plus, la documentation utilisateur doit être inspectée pour en vérifier l'exactitude et la clarté, à l'instar des inspections texte source. Tous les exemples donnés dans la documentation doivent être conçus comme un test et testés sur le logiciel.

Critères de réussite des tests. Lors des tests, la question se pose de savoir quand les tests du programme doivent être terminés, car il n'est pas possible de déterminer si l'erreur identifiée est la dernière.

Fondamentalement, dans la pratique, les deux critères suivants sont respectés : lorsque le temps imparti selon le calendrier de travail pour les tests est expiré ; lorsque tous les tests ont échoué, c'est-à-dire qu'ils ont été effectués sans identifier d'erreurs.

Ces deux critères ne sont pas assez précis et logiques, puisque le premier critère ne contient pas d'évaluation de la qualité des tests et peut être satisfait sans rien faire, tandis que le second ne dépend pas de la qualité des ensembles de données de test.

Cependant, le deuxième critère peut être amélioré en se concentrant sur certaines méthodologies de conception de tests. Par exemple, vous pouvez déterminer la condition de terminaison pour les tests de module à l'aide de tests obtenus de deux manières : en satisfaisant la couverture combinatoire des conditions et la méthode d'analyse des valeurs limites selon la spécification de l'interface du module. Tous les tests qui en résultent finiront par échouer.

L'achèvement des tests de fonctionnement peut être déterminé en exécutant conditions suivantes: tests obtenus par les méthodes des diagrammes fonctionnels ; le partitionnement équivalent et l’analyse des valeurs limites doivent échouer.

Cependant, ces critères, premièrement, sont inutiles en phase de test lorsque certaines méthodes devenir inutilisable, par exemple, pendant la phase de test du système ; deuxièmement, une telle mesure est subjective, car il n'y a aucune garantie que le spécialiste a utilisé correctement et avec précision la méthodologie requise ; troisièmement, afin de fixer un objectif et de permettre le choix de la manière la plus appropriée pour l'atteindre, les critères considérés prescrivent l'utilisation de méthodes spécifiques, mais ne fixent pas d'objectifs.

Parfois, un critère est utilisé, basé en grande partie sur le bon sens et sur des informations sur le nombre d'erreurs obtenues lors des tests. Pour ce faire, tracez la dépendance du nombre d'erreurs et du moment de leur apparition. La forme de la courbe résultante détermine s’il vaut la peine de poursuivre les tests ou non. La figure montre des exemples de graphiques du nombre d'erreurs en fonction de la durée du test.

Dépendance du nombre d'erreurs sur la durée des tests.

L'exemple montre que si la durée du test est longue et que le nombre d'erreurs augmente à mesure que la durée du test augmente, alors, naturellement, les tests doivent être poursuivis. Si, au cours du processus de test, à un moment donné, le nombre d'erreurs détectées diminue, si le nombre d'erreurs détectées tend progressivement vers zéro ou a atteint zéro, alors il est clair que le processus de test peut être terminé.

Cependant, ce critère n'est pas non plus assez efficace, car il n'y a aucune certitude que ce dernier cas il n'y aura pas d'augmentation supplémentaire du nombre d'erreurs détectées.

Une autre approche pour déterminer le critère d’achèvement des tests est possible. Puisque le but des tests est de trouver des erreurs, un certain nombre prédéterminé d'erreurs peut être sélectionné comme critère, correspondant à une certaine partie du nombre total d'erreurs attendu. Cependant, l'utilisation de ce critère pose un certain nombre de problèmes. Tout d’abord, il est nécessaire d’estimer le nombre total d’erreurs dans le programme. Deuxièmement, il est nécessaire de déterminer quel pourcentage de ces erreurs peut être déterminé par des tests. Enfin, il est nécessaire de déterminer quelle partie des erreurs est survenue lors du processus de conception et au cours de quelles phases de test il convient de les identifier.

Pour estimer le nombre total d'erreurs et identifier le pourcentage possible d'erreurs pouvant être détectées par les tests, vous pouvez utiliser des méthodes utilisées pour déterminer les indicateurs de fiabilité (modèles de fiabilité), par exemple en utilisant le modèle Mills ou un modèle intuitif simple, que nous j'y réfléchirai un peu plus tard.

Une autre façon d’obtenir une telle estimation consiste à utiliser des moyennes statiques, largement utilisées dans l’industrie. Par exemple, le nombre d'erreurs qui existent dans les programmes typiques au moment où le codage temporel est terminé (avant la visite ou l'inspection) est d'environ 4 à 8 pour 100 instructions de programme.

Le modèle Mills repose sur l'introduction d'erreurs dans un programme afin d'estimer, lors des tests, le nombre d'erreurs résiduelles réellement contenues dans le programme. En vérifiant le programme pendant un certain temps et en triant les erreurs introduites de celles réellement présentes dans le programme, vous pouvez estimer le nombre d'erreurs initialement contenues dans le programme et le nombre d'erreurs restantes au moment de l'évaluation.

Si S erreurs sont introduites de manière aléatoire dans le programme, n+V erreurs sont trouvées lors du test (n est le nombre d'erreurs trouvées propres erreurs; V est le nombre d'erreurs introduites trouvées), alors le nombre estimé d'erreurs propres initialement trouvées dans le programme peut être calculé à l'aide de la formule : .

Par exemple, si 20 erreurs propres et 10 erreurs introduites sont détectées, avec un nombre total d'erreurs initialement introduites égal à 25, la valeur N = 25*20/10 = 50 ; ceux. À ce stade, on suppose que le programme comportait 50 erreurs inhérentes et les tests doivent se poursuivre.

Le nombre N peut être estimé après chaque nouvelle détection d'erreur.

Le programme doit être débogué jusqu'à ce que toutes les erreurs introduites soient détectées. Lorsque des erreurs introduites sont détectées, un niveau de confiance C peut être déterminé, indiquant la probabilité que l'estimation soit correcte :

où k est le nombre estimé d'erreurs propres, S est le nombre d'erreurs introduites, n est le nombre d'erreurs propres détectées.

Par exemple, si nous affirmons qu'il n'y a pas d'erreurs dans le programme (k = 0), et que lorsque 6 erreurs ont été introduites dans le programme, elles ont toutes été détectées, mais aucune erreur propre n'a été détectée, alors C = 6/(6 + 0 + 1) = 0, 86. En revanche, pour atteindre un niveau de confiance de 0,98, 39 erreurs doivent être introduites dans le programme : C=39/(39 + 0 + 1)=0,98.

Le modèle de Mills n'est pas sans un certain nombre de défauts, dont les plus significatifs sont la nécessité d'introduire des erreurs artificielles (ce processus est mal formalisé) et une hypothèse assez vague de la valeur k (le nombre d'erreurs propres), qui repose sur uniquement sur l'intuition de la personne qui effectue l'évaluation, c'est-à-dire admet grande influence facteur subjectif.

Un modèle simple et intuitif implique des tests effectués par deux groupes de programmeurs indépendamment l'un de l'autre, à l'aide de suites de tests indépendantes.

Pendant le processus de test, chaque groupe enregistre toutes les erreurs qu'il trouve. Lors de l'évaluation du nombre d'erreurs restant dans le programme, les résultats des tests des deux groupes sont collectés et comparés.

Il s'avère que le premier groupe a découvert N 1 erreurs, le second - N 2 erreurs et N 12 sont des erreurs découvertes par les deux groupes.

Si nous désignons par N le nombre inconnu d'erreurs présentes dans le programme avant le début des tests, alors l'efficacité des tests de chaque groupe peut être déterminée comme

En supposant que la capacité de détecter toutes les erreurs est la même pour les deux groupes, on peut supposer que si le premier groupe trouvait un certain nombre de toutes les erreurs, il pourrait déterminer le même nombre de n'importe quel sous-ensemble sélectionné au hasard.

En particulier, on peut supposer que

La valeur de N 12 est connue, et E 1 et E 2 peuvent être définis comme N 12 /N 1 et N 12 /N 2. Ainsi, le nombre inconnu d'erreurs dans le programme peut être déterminé par la formule :

En poussant ce modèle plus loin et en s'appuyant sur les hypothèses que les deux groupes de test ont probabilité égale détection d'erreurs "générales", elle peut être calculée par la formule suivante:

où P(N12i) est la probabilité de détecter N 12 erreurs « courantes » lors des tests de programmes par deux groupes indépendants.

L'identification des erreurs qui se produisent au cours du processus de conception utilise des données indiquant que dans les gros logiciels, environ 40 % de toutes les erreurs sont des erreurs de conception logique et de codage, et le reste est dû à davantage d'erreurs. étapes préliminaires conception.

Sur cette base, regardons un exemple. Disons qu'un programme de 1 000 instructions est en cours de test ; le nombre d'erreurs restant après inspection du code source est estimé à 5 pour 100 déclarations. L’objectif des tests est de détecter 98 % des erreurs de codage et de logique et 95 % des erreurs de conception.

Le nombre total d’erreurs est de 500. On suppose que 200 d’entre elles sont des erreurs de codage et de logique, et 300 sont des erreurs de conception. Par conséquent, il est nécessaire de trouver 196 erreurs de codage et de logique et 285 erreurs de conception.

Pour des raisons bon sens Il est logique de répartir le pourcentage d'erreurs trouvées entre les étapes de test, comme indiqué dans le tableau.

Pourcentage erreurs trouvées par les étapes de test.

Sur la base de ces chiffres, les critères suivants peuvent être déterminés.

1. Lors de la phase de test des modules, 130 erreurs doivent être trouvées et corrigées (65 % des 200 erreurs de codage et de logique estimées).
2. Au stade des tests du système, il est nécessaire de rechercher et de corriger 6 erreurs et 105 (3% sur 200 et 35% sur 300).

Un autre problème évident avec ce type de critère est celui de la surestimation. Que se passe-t-il si, dans l'exemple ci-dessus, il reste moins de 240 erreurs au moment où la vérification des fonctionnalités démarre ? Sur la base de ce critère, il n'est jamais possible de terminer la phase de test des fonctionnalités. Pour éviter une telle situation, le critère du nombre d'erreurs devrait être complété par le délai pendant lequel elles doivent être détectées. Dans ce cas, si des erreurs sont détectées rapidement, les tests à un certain stade doivent être poursuivis jusqu'à la fin de l'intervalle de temps spécifié. En cas de surestimation, c'est-à-dire le temps a passé et quantité spécifiée aucune erreur n'a été trouvée, alors vous devriez inviter un expert désintéressé qui exprimera son avis sur les raisons du problème : soit les tests ne sont pas efficaces, soit les tests sont réussis, mais il y a vraiment peu d'erreurs dans le programme.

Le meilleur critère pour réaliser les tests est une combinaison des trois approches envisagées. Pour les modules de test, le premier critère considéré sera optimal, car dans la plupart des projets à cette phase, ils ne surveillent pas le nombre d'erreurs détectées ; il est important ici qu'un certain ensemble de méthodes de conception de tests soit utilisé ; Pendant les phases de tests fonctionnels et système, le critère de terminaison peut être un arrêt à l'atteinte numéro donné erreurs détectées ou atteindre le point, déterminé par calendrier travail, à condition qu'une analyse de la dépendance du nombre d'erreurs sur le temps de test montre une diminution de la productivité.

) a enregistré une vidéo pour démontrer des tests de résistance rapides. Dans son exemple, l'approche consistait à fournir à l'assistant d'application une énorme quantité de données, forçant essentiellement l'application à se charger elle-même.

La vidéo dure près de six minutes. À mi-chemin, James demande : « Vous vous demandez peut-être pourquoi je ne veux pas m'arrêter maintenant. La raison en est que nous constatons une détérioration constante de la situation. Nous pourrions arrêter maintenant, mais nous pourrions voir quelque chose de pire si nous continuons. » Il a donc continué le test. Et peu de temps après, James a proposé une heuristique pour s'arrêter : nous nous arrêtons lorsque : 1) nous en avons découvert suffisamment Problème sérieux, ou 2) il n'y a pas de changements évidents dans le comportement du programme - le programme dans son ensemble fonctionne de manière stable, ou 3) l'intérêt de poursuivre le test n'en justifie pas le coût. Telles étaient les heuristiques permettant d’arrêter ce test.

Environ un an après avoir vu cette vidéo pour la première fois, j'ai décidé de décrire plus en détail les heuristiques permettant d'arrêter les tests dans une chronique du magazine Better Software. James et moi avons eu une conversation prospective à ce sujet. Vous pouvez trouver la colonne. Un an plus tard, la chronique est devenue une conférence informelle que j'ai donnée à plusieurs endroits.

Environ six mois plus tard, nous avons tous deux trouvé encore plus d’heuristiques pour arrêter les tests. Nous en avons discuté lors de STAR East 2009, et Dale Emery et James Lyndsay, qui passaient par là à ce moment-là, se sont joints à la discussion. Dale a notamment suggéré que lors d'une bataille, les tirs peuvent être arrêtés dans plusieurs cas : une accalmie temporaire, un ordre de « cesser le feu », un accord de cessez-le-feu entre les parties, le retrait des parties de positions de départ, désarmement de l'ennemi. J'ai trouvé cela intéressant.

En général, je vais maintenant vous raconter toutes les heuristiques que nous avons trouvées. J'insiste sur le fait que ces heuristiques d'arrêt sont précisément heuristique. Les heuristiques sont des moyens rapides et peu coûteux résolution de problème ou prise de décision. Heuristique sujet aux erreurs, c'est-à-dire qu'ils peuvent ou non fonctionner. Les heuristiques ne sont pas assez abstraites, elles peuvent se chevaucher et se croiser. Aussi des heuristiques dépend du contexte, ils sont donc censés être utilisés par des personnes possédant les connaissances et les compétences nécessaires pour les utiliser judicieusement. Ci-dessous, j'ai répertorié les heuristiques et pour chacune d'elles j'ai indiqué quelques questions avec lesquelles vous pouvez vérifier la validité de son utilisation.

1. Heuristique"Tempsil s'est avéré!» . Pour de nombreux professionnels des tests, il s’agit de l’heuristique la plus courante : nous arrêtons les tests lorsque le temps qui leur est imparti est écoulé.

Avons-nous reçu les informations dont nous avons besoin sur le produit ? Le risque d’arrêter les tests est-il trop élevé ? Pasétaitsitermeartificiel, arbitraire? Volontésiêtre effectuésupplémentairedéveloppement, lequelil faudrasupplémentaireessai?