Tous les articles
Les tests vitaux : c’est Vital !
Introduction: Généralement pour toute application déjà en production il existe une campagne de tests de régressions. Ces tests visent à s’assurer que s’il y a des régressions sur le produit (malheureusement il est impossible d’assurer une absence totale de régression !) elles sont minimes (car non couvertes par les tests). Sur une application mail on a facilement 200-300 tests de régression, sur une application web également. Le temps d’exécution et d’analyse est donc long et prend facilement une semaine (voir plus). Ces tests ne peuvent donc pas être exécutés tous les jours hors lors du développement d’un produit ou de nouvelles fonctionnalités
Les couvertures de tests
Introduction : Il existe différents outils dans le métier du test. Un des plus connus et des plus instinctifs est la couverture. Mais que veut dire exactement j’ai une couverture de 100% ? Au risque de vous décevoir : rien ! En effet il existe 3 types de couvertures pour les tests. Les 3 sont totalement différentes et sont : La couverture des méthodes (des fonctionnalités) La couverture des instructions (du code) La couverture des chemins d’exécution Pour expliquer plus en détail ces couvertures je reprendrai l’exemple de l’application mail. La couverture des méthodes : Cette couverture correspond à la couverture la plus basique. Elle correspond au
Les défis du SCRUM pour une équipe de test
Lorsque l’on est dans une grande entreprise il n’est pas rare de se retrouver avec des équipes spécialisées dans le test. Ces équipes ne sont composées que de testeurs (en incluant les test manager et les tests coordinateurs). Pour ces équipes, la mise en place de process agiles tels que le Scrum est un vrai challenge qui se doit d’être relevé afin que cette « équipe de test » reste une équipe à part entière. Un grand nombre de ces difficultés est également partagés par les équipes de développeurs et de business analystes. Les défis du mode Scrum : Comment faire pour que le sentiment
Tests autos vs tests manuels
L’automatisation, le nouvel Eldorado ! Il faut automatiser tous les tests et une fois que ça sera fait, exécuter les cas de tests sera gratuit et parfaitement fiable, tout sera merveilleux ! Vraiment ? Dire cela montre juste un manque de connaissance du métier du test. Les tests ce n’est pas que l’exécution. L’automatisation a de nombreuses qualités (surtout avec des méthodes incrémentales, pour plus d’info lire mon post sur le testeur dans la méthode Scrum) indéniables et il serait dommage de s’en priver. Néanmoins les cas de tests manuels ont également de nombreux points forts non négligeables et souvent complémentaires avec les tests
La gestion des bugs
La phase d’exécution des tests : Avant même d’avoir un bug, il faut le provoquer. Pour cela, on exécute des cas de tests sur notre logiciel, certains de ces cas sont en « échec ». C’est dans ces cas en « échecs » que l’on trouve des bugs. On appelle cette partie l’exécution des tests. Suite à ces tests en échec (ou « failed ») on arrive à une partie plus difficilement automatisable (et donc avec plus de valeur ajoutée !) qui est une partie d’analyse du cas. A noter : lorsque le logiciel est déjà en production, de nombreux bugs sont remontés par des utilisateurs. Ils sont alors reproduits