La vérification et la validation font-elles partie du processus de test?


9

Sur la base de nombreuses sources, je ne crois pas que la définition simple qui vise à tester soit de trouver autant de bugs que possible - nous testons pour nous assurer que cela fonctionne ou non. Par exemple, les objectifs de test du formulaire ISTQB sont les suivants:

  1. Déterminer que (les produits logiciels) satisfont aux exigences spécifiées (je pense que sa vérification)

  2. Démontrer que (les produits logiciels) sont adaptés à l'usage (je pense que c'est la validation)

  3. Détecter les défauts

    Je conviens que les tests sont la vérification, la validation et la détection des défauts. Est-ce exact?


1
La première chose que disent les livres sur les tests est que "les tests ne sont pas le processus de montrer que le logiciel fonctionne correctement. C'est le processus de détection des défauts". Et que les livres apportent de nombreuses raisons de définir des tests comme ça. C'est donc plutôt que la vérification est le processus consistant à trouver où le logiciel ne répond pas aux exigences.
superM

Selon la définition, la vérification garantit que les exigences ont été respectées. En fait, les livres définissent les tests comme un processus de mesure de la qualité des logiciels. Donc, si vous vérifiez que le système fonctionne (positif) avec l'intention de voir s'il fonctionne, il ne teste pas parce que vous ne recherchez pas de bogues? :) Sur Wikipédia: Les techniques de test incluent, sans s'y limiter, le processus d'exécution d'un programme ou d'une application dans le but de trouver des bogues logiciels
John V

Je pense que la meilleure façon d'identifier les limites du mot test est de penser à tester une hypothèse, dans ce cas, vous essayez de vérifier qu'il n'y a pas d'erreurs ou d'inexactitudes dans l'hypothèse, ce n'est pas la même chose que de vérifier son utilité ou valider son applicabilité, il s'agit simplement d'identifier sa portée de comportement entière, quel que soit le but.
Jimmy Hoffa

Avoir un bonus "belle question" :)
Andrew

Réponses:


1

Je pense que vous avez parfaitement compris.

  1. La vérification et la validation sont des choses différentes et sont en fait assez bien définies. Bien que je n'aime pas beaucoup le document, l'ISO 9000ff est très pertinent pour l'AQ et définit la vérification comme comparant un produit à ses exigences et la validation comme vérifiant s'il correspond réellement aux besoins du client / utilisateur et nous savons tous que cela peut différer .

  2. Les deux peuvent être effectués par le biais de tests. La vérification conduirait à des tests générés par les exigences du formulaire. La validation conduit à des tests effectués par des tests sans référence directe aux exigences. Je pense que cela est souvent appelé test exploratoire. Évidemment, cela doit être fait par des personnes ayant une réelle compréhension des besoins réels des utilisateurs, donc les tests alpha et bêta par de vrais utilisateurs sont des options évidentes.

  3. Sur une base théorique, je suppose que l'on pourrait affirmer que tout ce qui est couvert par les deux premiers n'est pas un bug et donc trouver des bugs comme objectif séparé n'a pas de sens. Mais je pense qu'il y a des choses que vous ne pouvez pas vraiment vérifier ou valider. Par exemple, la sécurité: comment validez-vous ou vérifiez-vous qu'un système logiciel est protégé contre les attaques? Au lieu de cela, vous essayez de trouver des vulnérabilités. Cette recherche ne vérifie ni ne valide rien si elle ne parvient pas à trouver de problèmes, mais elle trouve des bogues si elle réussit.


Le problème est que de nombreuses sources mentionnent que la vérification n'est que statique, tandis que la validation est dynamique. C'est très confus. Quel serait alors le test fonctionnel? Je dirais sa vérification dynamique ..
John V

1
Quelles sources utilisent cette définition de la vérification et de la validation? D'un autre côté, je ne connais pas de définition claire et généralement acceptée de tout ce qui se termine par -test. Je ne sais donc pas vraiment ce qu'est un test fonctionnel pour vous.
Jens Schauder

Par exemple, ISO 12207 limite les tests en tant que processus de validation uniquement.
John V

3

De Wikipedia: "... En d'autres termes, la validation garantit que le produit répond réellement aux besoins de l' utilisateur et que les spécifications étaient correctes en premier lieu , tandis que la vérification garantit que le produit a été construit conformément aux exigences et aux spécifications de conception. . La validation garantit que "vous avez construit la bonne chose". La vérification garantit que "vous avez construit la bonne chose". La validation confirme que le produit, tel que prévu, remplira son utilisation prévue. "

Vous ne pouvez pas tester les besoins des utilisateurs et vérifier si les spécifications étaient correctes par code. La validation ne se fait donc pas par test.

La vérification suppose que vos exigences et votre conception sont correctes, vous pouvez donc les tester en écrivant du code (testing).


Je ne suis pas d'accord - les tests ne sont pas seulement des tests de code, il y a aussi des tests de documentation, etc. programme par son exécutioan et investagion si oui ou non c'est ce que l'utilisateur voulait.
John V

En fait, vous avez raison. Le processus de test comprend également l'acceptation des tests, mais j'ai parlé des tests d'unité, d'intégration et de système. Si nous pensons au processus de test dans son ensemble, la vérification et la validation se font par test.
Mert Akcakaya

1

Pour le monde réel, les tests sont la vérification et la validation du logiciel qui répond aux exigences du logiciel (métier / fonctionnel / non fonctionnel). Leur objectif est de déterminer si le logiciel est adapté à l'usage prévu. Tout comportement qui ne répond pas aux exigences de l'application est un défaut - dont la gravité devra être pondérée avant de déterminer si le logiciel est adapté à l'usage prévu.

Les défauts de faible gravité ne sont probablement pas des obstacles à la transmission du logiciel à une utilisation de type production. Une gravité élevée peut nécessiter la production d'un correctif. Dans le monde réel, tous les logiciels présentent des défauts, certains sont des problèmes de codage et d'autres sont dus à des exigences manquantes - qui peuvent ne pas être testées car vous ne pouvez pas tester des exigences inconnues.


1

Il existe de nombreuses définitions de la vérification et de la validation. De nombreuses personnes utilisent même la balise V&V pour regrouper les deux en une seule activité. L'objectif est de s'assurer que le logiciel fait les bonnes choses et fait les choses correctement. Que ce soit pour vérifier la conformité aux exigences ou pour essayer de trouver des bogues n'est pas essentiel à ce niveau.

Les tests sont l'une des nombreuses techniques de vérification et de validation, et non l'inverse. La révision du code en est une autre, et une vérification formelle, avec des preuves mathématiques encore une autre.

Néanmoins, les tests doivent être effectués dans le but de trouver des bogues, et non dans le but de vérifier la conformité aux exigences.

La principale différence est dans l'esprit du testeur. Il est beaucoup plus facile de construire un cas de test montrant que le logiciel fonctionne comme prévu (vérification de la conformité), que de construire un cas de test montrant que le logiciel échoue (recherche de bogues).

Un grand testeur est passionné par la rupture de logiciels, pas par son exercice en toute sécurité.


merci, mais ne testons-nous pas également pour montrer que les exigences sont remplies? Nous nous assurons que le logiciel fonctionne (répond aux spécifications), puis nous essayons de trouver des défauts. Il ne s'agit donc pas seulement de trouver des bogues. Je me souviens d'un livre disant que l'objectif principal des tests était de mesurer la qualité, pas de rechercher des bugs. En ce qui concerne votre premier point, la révision de code, la preuve mathématique, etc. est également testée et elle est appelée statique.
John V

Des défauts ou des bogues existent contrairement aux exigences. La nature du travail est identique. Ce n'est qu'une différence dans la façon de penser du testeur pour améliorer son efficacité. En ce qui concerne mon premier point, il existe de nombreuses définitions de tous les termes utilisés dans la validation logicielle (et une première étape pour rejoindre une équipe est d'obtenir le dialecte local dans cette équipe), mais la majorité des gens conviennent que les tests ne sont qu'une dynamique technique. le test statique est un oxymore, ou se réfère à une technique différente, non loin de la révision, où le code est exécuté dans l'esprit du "testeur" et non par un ordinateur.
mouviciel

mouviciel: oxymore? Je ne pense pas, les tests statiques signifient la vérification d'éventuels défauts sans exécution, ce qui est tout à fait possible (problèmes d'exigences, défauts de conception ..). Ce n'est pas la même chose pour vérifier les exigences et vérifier les bogues: vous devez tester qu'un champ peut contenir une valeur int32. C'est tester que cela fonctionne. Ensuite, vous pouvez essayer d'entrer des valeurs plus élevées, c'est-à-dire tester les bugs ..
John V

1

Voyons cela d'un point de vue pratique. Pour les tests, vous devez définir des cas de test. En règle générale, vous définissez des cas de test selon les exigences spécifiées, et ils doivent couvrir les cas de «jour heureux» ainsi que les «cas marginaux» - en particulier, ces derniers sont souvent définis avec l'intention de casser le logiciel. Lorsque certains de vos tests échouent, ils présentent des bogues / défauts. Lorsque vous disposez d'un nombre raisonnable de cas de test pour chaque exigence, et que tous les tests réussissent, vous n'avez peut-être pas entièrement prouvé que toutes les exigences sont remplies, mais vous avez amélioré la probabilité de cela, donc effectué une vérification.

Donc, pour cette partie de la question, la recherche de bogues et la vérification peuvent n'être que les deux côtés du même processus:

  • les tests échouent: défauts trouvés

  • tests réussis: vérification effectuée (au moins, dans une certaine mesure, si vous fournissez suffisamment et les bons tests)

Concernant la validation: comme l'a souligné @Mert, la validation peut se faire par des tests d'acceptation, mais pas par d'autres formes de tests. Ainsi, les tests en général ne provoquent aucune validation, uniquement lorsqu'ils sont effectués en tant que tests d'acceptation, par certains des utilisateurs potentiels.


0

Tout dépend de votre définition de «vérification». Par exemple, la vérification formelle n'est généralement pas effectuée par une équipe d'AQ, mais relève plutôt de la responsabilité des développeurs. Presque personne ne procède à une vérification formelle en raison du coût élevé qui y est associé (manque de connaissances et ressources nécessaires).


0

Les tests de logiciels ne sont pas identiques à QA. Tu as totalement raison. Le test logiciel comprend globalement de nombreuses étapes (fumée, unité, régression, intégration, acceptation par l'utilisateur, etc.) en soi.

Ainsi, garantir que le logiciel fonctionne conformément aux exigences est l'objectif de QA (spécialiste de l'assurance qualité - alias autrefois appelé simplement testeurs il y a des années). Cependant, il ne s'agit pas uniquement de tests . L'assurance qualité s'assure qu'un ensemble approprié de processus pour effectuer le contrôle de qualité du produit en question est en place, ou du moins intégré à la phase de conception du projet.

Ainsi, idéalement, vous vous attendriez à ce que votre AQ vérifie l'application par rapport à un ensemble d'exigences et n'essaye pas simplement de la tester en cassant le logiciel et en trouvant des défauts.


L'AQ n'est pas seulement un test. Le contrôle qualité porte sur la qualité des processus de développement.
John V

Le contrôle qualité vérifie l'application par rapport à un ensemble d'exigences.
Yusubov
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.