Vérification vs. Validation : pourquoi vos exigences sont erronées

La vérification du code via des tests automatisés garantit que les choses fonctionnent correctement. En revanche, la validation des exigences garantit que vous travaillez sur les bonnes choses. Puisqu'il ne sert à rien de vérifier les mauvaises exigences, voici comment vous assurer que vos exigences sont valides.

D'une manière ou d'une autre, nous parvenons à fournir des applications qui, bien qu'elles réussissent tous nos tests, nos utilisateurs ne veulent pas. Voici pourquoi cela se produit (et comment arrêter de le faire).

Lorsque mon code a réussi tous mes tests automatisés, je peux dire que j'ai prouvé que mon code fonctionne. Dans le domaine des tests, ce que j'ai fait s'appelle « vérification » et cela répond à la question : « Mon code fait-il ce que les exigences disent qu'il était censé faire ? » C'est parce que mon code et mes tests sont tous deux pilotés par la même source : les exigences de l'application.

Vérification vs. Validation : Pourquoi vous intéressez-vous

Ce qui, bien sûr, suppose que ces exigences sont "correctes". Si les exigences ne sont pas correctes… eh bien, tout simplement, vérifier le code par rapport aux exigences qui ne sont pas correctes est une perte de temps. Et c'est lorsque les exigences ne sont pas correctes que nous livrons des applications qui, bien qu'elles fonctionnent « parfaitement » dans un certain sens technique du terme, ne font pas le bonheur de nos parties prenantes. Il s'agissait d'exigences importantes, mais ce n'étaient pas, en fin de compte, celles qui comptaient. Ah, vérification contre validation.

Si vous créez des applications depuis un certain temps, alors vous avez vécu cette expérience et, je suppose, n'avez aucune envie de la revivre.

Dans le tester biz, s'assurer que vous avez les "bonnes" exigences est appelé "validation". Prêter attention à la validation – s'assurer que les exigences sont « correctes » – vous empêche de fournir du code dont personne ne veut. Et vous devriez (évidemment) valider vos exigences. L'une des raisons pour lesquelles vous devriez le faire est que c'est facile : demandez simplement à vos utilisateurs ce qu'ils veulent. l'utilisateur veut. Et je suis d'accord : parfois, votre processus d'exigences fournit des exigences valides. Mais parfois, ce n'est pas le cas.

Par exemple, vous pouvez vérifier que votre code est conforme à certaines exigences réglementaires. C'est très bien, mais il y a un tas de questions auxquelles vous devriez avoir répondu avant de commencer à écrire votre code ou le test qui l'a vérifié : quelqu'un a-t-il confirmé que cet ensemble de code particulier devait être conforme à cette réglementation ? Le code démontre-t-il aux autorités nécessaires que vous vous conformez effectivement à la réglementation ? Savez-vous qu'il n'y a pas d'autres exigences réglementaires auxquelles vous devez vous conformer? Ce sont toutes des questions de validation et non de vérification. Certaines de ces questions ont peut-être trouvé une réponse. D'autres… peut-être pas. Comment le sauriez-vous ?

À ce stade, vous vous attendez probablement à une discussion philosophique très floue avec beaucoup de gestes de la main, ainsi que des instructions qui se résument à « faire le bien et ne pas faire le mal » … mais aucune pratique direction. Alors permettez-moi de préciser : le problème avec les exigences est que vos parties prenantes imaginent, en fonction de leurs besoins, ce que le système que vous fournirez va faire.

C'est encore trop philosophique. Permettez-moi d'être encore plus précis sur le problème :

• Vos parties prenantes en savent beaucoup plus que vous sur ce dont elles ont besoin, mais une grande partie de cette connaissance est supposée et n'est jamais énoncée à haute voix.
• Le système que vos parties prenantes imaginent est bien plus performant que celui que vous construisez.

Le résultat est que les exigences qui vous sont données ne font qu'approcher ce que vos parties prenantes imaginent, et le système que vous construisez ne fait qu'approcher ce qu'ils attendent. La validation est le processus consistant à concilier les rêves de vos parties prenantes avec la triste réalité que vous allez livrer. avec vos parties prenantes en des termes qui ont du sens pour votre partie prenante.

Cela signifie, même si vous n'avez aucun intérêt pour la conception de l'expérience utilisateur, fournir aux parties prenantes des prototypes de vos interfaces utilisateur ainsi que des maquettes de tout résultat avec lequel les parties prenantes interagiront… et puis travailler sur des scénarios typiques avec vos parties prenantes à l'aide de ces outils. En effet, vous modélisez le monde de vos parties prenantes – ou plutôt le nouveau monde dans lequel vous déplacez vos parties prenantes – dans le contexte de votre application.

Ces simulations doivent impliquer à la fois les parties prenantes qui vivront avec le final produit et les développeurs qui livreront le code. Faire travailler les développeurs avec les parties prenantes sur ces simulations fait deux choses : cela approfondit la compréhension des développeurs de ce que signifient les exigences, et cela fonde les attentes des parties prenantes sur ce qui sera réellement fourni.

Vous ne devriez pas être surpris si, dans ce cas processus, les intervenants disent des choses comme : « C'est génial ! Maintenant, où puis-je trouver x ? » ou "C'était facile. Alors, comment saura-t-il quand c'est  ? » Ou, même, « Oh, mon cher. Cela fonctionne mais nous devons le faire chacun de ces . Nous n'aurons jamais assez de temps pour le faire / nous accumulerons des heures supplémentaires chaque jour. Ou même, un jour ou deux plus tard, une partie prenante vous appelle pour vous dire : « Vous savez, j'ai réfléchi à et… ça ne va pas vraiment marcher. »

Nous ne demanderons pas comment je sachez-le.

Mais c'est la réalité de la validation des exigences : la modélisation et la simulation du monde de vos parties prenantes font apparaître des exigences validées dont vous aurez besoin pour créer du code à implémenter et des tests à vérifier. Ne les considérez pas comme de « nouvelles » exigences : ces exigences ont toujours été là… vous ne les connaissiez tout simplement pas. Étant donné que vous alliez de toute façon vous faire infliger ces exigences, en les obtenant tôt, vous êtes «proactif» (soi-disant une bonne chose).

Écoutez: je mets le meilleur tour possible sur ce que je peux.[19659003]Et vous ne faites pas cela une seule fois, d'ailleurs. Lorsque vous commencez à créer votre application, vous devez réintégrer vos parties prenantes afin que vous puissiez tous les deux participer à des exercices de simulation plus détaillés et plus complets avec votre code de travail en cours.

Vous devez prendre le temps de modéliser vos parties prenantes. ' nouveau monde : c'est l'étape essentielle pour transformer les rêves de vos parties prenantes en exigences valables. Seules ces exigences méritent votre temps car seules ces exigences sont celles qui comptent.

En parlant de ce qui compte, le seul test qui compte vraiment est tester à travers les yeux de l'utilisateur.