Test Agile/Test Cases, alternative légère à l'IEEE 829?

Question

Je construis une application web et je commence à créer un plan de test/des cas de test et des résultats.

J'ai jeté un oeil à la norme IEEE 829 http://en.wikipedia.org/wiki/IEEE_829 pour créer ce qui précède et il semble un peu trop pour mes besoins. Je me demande simplement si quelqu'un a des exemples d'un plan de test (et des cas associés et des résultats pour les tests GUI par exemple) qu'ils utilisent pour leurs propres projets Agile?

Un grand merci

Answer 1

Nous utilisons des scénarios BDD, qui décrivent les capacités du système à partir d'un point de vue de l'utilisateur. Nous les exprimons comme suit:

Given <a context> 
When <an event happens> 
Then <an outcome occurs> 

Vous pouvez utiliser n'importe quel nombre de données, tant le jour que le jour.

Given <a context> 
And <another context> 
When <an event happens> 
Then <an outcome occurs> 
And <another outcome occurs> 
When <another event happens> 
Then <yet another outcome>. 

Le BA écrit habituellement ces pour nous, mais je l'ai vu devs ou les testeurs les écrire en collaboration avec les analystes ou les parties prenantes de l'entreprise.

Vous pouvez utiliser un framework BDD comme Cucumber, SpecFlow ou JBehave pour les automatiser, ou les développeurs peuvent les implémenter avec un peu de DSL. Here's an example. C'est un vrai scénario qui s'exécute contre l'interface graphique d'un little C# pet shop. Ce que j'aime le plus dans les scénarios, c'est que vous pouvez avoir des conversations sur différentes choses que le système devrait faire, en demandant si différents contextes changent les résultats, s'il y a d'autres résultats importants qui ont été manqués, etc. puis générer de nouveaux exemples. Nous n'automatisons pas tout, mais nous automatisons assez pour montrer comment le système se comporte et nous donner une bonne chance d'attraper quelque chose de cassant. Par exemple, nous pouvons montrer une ou deux pièces de validation mais pas vérifier que tout est validé; cela peut alors être fait à un niveau de test unitaire. Les scénarios sont alors également suffisamment lisibles pour qu'un testeur les suive, et comme nous les générons avant d'appliquer le code, nous obtenons de meilleures estimations et un code de qualité supérieure. Les équipes off-shore ont vraiment bénéficié de scénarios clairs et de la liberté de poser des questions à leur sujet.