Rédaction de cas de test d'acceptation

Nous intégrons un processus de test dans notre processus SCRUM. Mon nouveau rôle est d'écrire des tests d'acceptation de nos applications web afin de les automatiser ultérieurement. J'ai beaucoup lu sur la façon dont les cas de test doivent être écrits, mais aucun ne m'a donné de conseils pratiques pour écrire des cas de test pour des applications Web complexes, et au lieu de cela, ils ont jeté des principes contradictoires que j'ai trouvé difficile à appliquer:

• Les cas de test doivent être courts: prenez l'exemple d'un CMS. Les cas de test courts sont faciles à entretenir et à identifier les entrées et les sorties. Mais que se passe-t-il si je veux tester une longue série d'opérations (par exemple, ajouter un document, envoyer une notification à un autre utilisateur, l'autre utilisateur répond, le document change d'état, l'utilisateur reçoit un avis). Il me semble plutôt que les cas de test devraient représenter des scénarios complets. Mais je peux voir comment cela produira des documents de test ouvertement complexes.

• Les tests doivent identifier les entrées et les sorties:: Et si j'ai un formulaire long avec de nombreux champs en interaction, avec des comportements différents. Dois-je écrire un test pour tout, ou un pour chacun?

• Les cas de test doivent être indépendants: mais comment puis-je appliquer cela si le test de l'opération de téléchargement nécessite que l'opération de connexion réussisse? Et comment cela s'applique-t-il à la rédaction de cas de test? Dois-je écrire un test pour chaque opération, mais chaque test déclare ses dépendances, ou dois-je réécrire le scénario entier pour chaque test?

• Les cas de test doivent être légèrement documentés: ces principes sont spécifiques aux projets Agile. Avez-vous des conseils sur la façon de mettre en œuvre ce principe?

Bien que je pensais que la rédaction de cas de test d'acceptation allait être simple, je me suis retrouvé submergé par chaque décision que je devais prendre (pour info: je suis développeur et non testeur professionnel). Ma principale question est donc la suivante: quelles étapes ou quels conseils avez-vous pour rédiger des cas de test d'acceptation maintenables pour des applications complexes. Je vous remercie.

Edit : Pour clarifier ma question: je suis conscient que les tests d'acceptation doivent partir de l'exigence et considérer l'ensemble de l'application comme une boîte noire. Ma question concerne les étapes pratiques pour écrire le document de test, identifier les cas de test, gérer les dépendances entre les tests ... pour les applications web complexes

Dans mes suites d'acceptation, je n'ai pas utilisé de contrôles spécifiques à la technologie, c'est-à-dire que pour les applications Web, n'utilisez pas css, n'utilisez pas d'éléments html si vous devez remplir un formulaire, faites les détails dans les étapes de configuration du SUT et non les tests d'acceptation réels

J'utilise du concombre pour mon acceptation et j'ai les éléments suivants

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

cet exemple est de retour par une application Web, mais je peux toujours utiliser le test pour tester une application de bureau car les étapes sont utilisées pour configurer le SUT et non les tests d'acceptation

ce test se situe à la fin d'un achat qui va

Générer -> Confirmer -> Paiement -> Imprimer le reçu

le test ci-dessus concerne l'étape de paiement, les autres étapes sont configurées dans d'autres tests car l'application est en mesure de configurer dans ces états avec des données ou des actions http dans ce cas, le paiement a une donnée qui fait les étapes de confirmation et la confirmation fait le générer des étapes pour qu'elles soient un peu cassantes à la minute

Vous devez d'abord définir les tests d'acceptation .

Ce que vous semblez décrire, c'est l' intégration ou les tests du système .

Donc, bien que je ne sois pas 100% d'accord avec les définitions sur wikipedia, elles sont toujours largement valables.

Fondamentalement, le but des tests d'acceptation est de vérifier que les processus `` commerciaux '' qui utilisent le logiciel que vous avez créé fonctionnent réellement comme prévu et sont adaptés à leur objectif - avec des données réelles. Donc, en tant que tel, vous ne créez pas de cas de test comme vous le faites pour les tests unitaires ou le reste. Il n'est pas censé être conçu de la même manière.

La question à se poser est "comment le système est-il utilisé?". Permet donc de le tester de la façon dont il est censé être utilisé. Bien sûr, maintenant vous remettez votre chapeau d'ingénieur et passez religieusement en revue les exigences commerciales pour dériver vos cas de test. Cela suppose que vous avez des exigences commerciales bien écrites.

Si vous ne le faites pas, il n'est pas trop tard, vous devez vous asseoir avec le ou les utilisateurs ou leurs représentants (et l'analyste commercial et le responsable de la conception technique) et noter ce qu'ils attendent du logiciel en termes commerciaux ( avec la mise en garde évidente que c'est trop peu trop tard, mais il vaut mieux commencer tard que jamais - et bien sûr ne pas introduire de nouvelles fonctionnalités). Voilà ce que seront vos cas de test.

Une autre façon de procéder (encore une fois si vous avez un tel document) est de parcourir le manuel d'utilisation. Bien qu'il s'agisse d'une étape retirée des exigences commerciales réelles, vous ne devez l'utiliser que si tout le reste échoue.

Lorsque vous allez acheter une voiture, vous n'allez généralement pas très loin sous le capot (sauf si vous êtes mécanicien automobile). Il vous suffit de vous asseoir au volant et de vérifier le confort, la convivialité, l'apparence, les sons ... c'est-à-dire les choses générales. Vous avez généralement confiance que si la voiture devait être entre vos mains en premier lieu (au moins pour une voiture neuve), elle est généralement sûre et bien construite (il y a une garantie, vous avez fait votre travail à domicile et regardé les spécifications ...). Alors maintenant, vérifiez si c'est la voiture que vous voudrez conduire au cours des prochaines années.

Même chose avec le logiciel.

Les informations contradictoires peuvent être frustrantes et difficiles à généraliser et à appliquer à votre situation spécifique. Ergo, vous devrez peut-être faire ce qui fonctionne le mieux dans votre contexte.

Je ne suis pas un grand fan de longs documents de test et j'ai utilisé des visuels assez efficacement pour quelques petits projets. Essayez ça? Comme un organigramme (ou tout autre diagramme UML comme un diagramme d'état, etc.) au lieu d'utiliser uniquement du texte? Indiquez les entrées, les sorties, les conditions, les boucles, les voies, les états, les interactions avec d'autres composants, etc., puis indiquez si elles ont réussi, échoué, transféré, autre (?) En fonction de vos critères.

Cela peut être un peu de travail au début, mais peut vous aider à rester sain d'esprit à long terme. Quelle que soit la méthode que vous choisissez, plus vous travaillez avec elle, mieux vous y arriverez.

HTH, et bonne chance!

KM

Je pense que vous avez déjà défini de bons critères. Votre deuxième point est un bon moyen de définir les étendues de vos tests, et je suggère également de tester les conditions d'erreur et les corrections (je préconise que chaque correction de bogue soit accompagnée d'au moins un nouveau test unitaire). Cela peut sembler écrasant maintenant, mais plongez, et après avoir acquis un peu d'expérience, reconnaître ce qui fait de bons tests deviendra plus facile.