Trolldi : la phase de tests dans le cycle de vie d'un développement logiciel expliquée en images

Dans le cycle de vie d’un développement logiciel, la phase de tests a pour objectif de s’assurer que le système réagit de la façon prévue par ses développeurs ou, le cas échéant, est conforme aux besoins du client.

Tout d’abord, la version alpha, qui n’est pas censée être accessible à un large public. Ici, il s’agit de la première phase de développement concret du logiciel après avoir codé l’application. Très souvent, le produit en alpha test n’a pas toutes les fonctionnalités prévues pour le produit final. En alpha test le produit peut présenter un nombre important de bogues. Dans notre test de martelage de clou, bien que le marteau vient frapper contre le clou, il s’effrite après que le clou se soit quand même planté dans le bois.


Puis la bêta test. Durant cette phase, le logiciel est soumis à l’appréciation d’un plus grand panel d’utilisateurs. Il présente moins de bogues que dans sa version alpha. Rappelons qu’une bêta test peut être fermée (elle nécessite une invitation pour y participer) ou ouverte / publique. Les Alpha et Bêta ainsi que les Bêta entre eux sont souvent complémentaires car ils situent différemment les problèmes divers et variés. Dans notre test de martelage de clou, le marteau n’a plus la forme rudimentaire qu’il arborait en alpha.


Il arrive que certains tests soient fastidieux et en inadéquation avec les impératifs de développement actuels. Des tests de régression ou des tests à grande combinatoire par exemple voient leur réalisation être aussi répétitive que chronophage. C’est à ce moment qu’intervient l’automatisation des tests, qui nécessite tout de même que le test réponde à certains critères :

• le test est systématique : il doit être exécuté à chaque nouvelle version de l'application ;
• le test est répétitif : il est présent dans de nombreux scénarios de test ;
• le test est automatisable : il est possible techniquement de faire jouer le test par un robot.

Pour vérifier la stabilité, un test de stress peut être lancé. Il va servir à analyser le comportement d’un logiciel lorsqu’il est soumis à des cas de non conformité des applications. Le test de stress permet de révéler le comportement de l’application et prévoir les causes afin de rendre son logiciel plus fiable. Ici, l’activité maximale attendue tous scénarios fonctionnels confondus en heures de pointe de l’application sera simulée, pour voir comment le système réagit au maximum de l’activité attendue des utilisateurs. Dans notre cas, une pluie de clous et de marteaux est déversée, pourtant au final un seul clou sera planté.


Les tests fonctionnels de bout en bout quand à eux couvrent l'ensemble des intégrations nécessaires pour la mise en œuvre d'un service logiciel répondant à une problématique fonctionnelle. Contrairement au test unitaire qui va permettre de vérifier le bon fonctionnement d'une partie précise d'un logiciel ou d'une portion d'un programme (module), ici chacun des modules indépendants du logiciel est assemblé et testé dans l’ensemble.


Un test manuel (ou encore test d’utilisateur / d’utilisabilité) permet d’observer directement la façon dont l’utilisateur se sert d’une application et ainsi identifier concrètement les véritables difficultés qu’il rencontre (problèmes d'utilisabilité). Ici, l'utilisateur doit suivre des scénarios d’utilisation construits afin de vérifier les hypothèses identifiées précédemment. Ces scénarios correspondent généralement à des tâches typiques de l’utilisateur.


Source : Monkey User

Et vous ?

Comment organisez-vous vos tests ? Avez-vous des anecdotes à partager ?