Tous les articles
Les tests statiques : Rois du ROI
Définition ISTQB : test d‘un composant ou système au niveau spécification ou implémentation sans exécution de ce logiciel (p.ex. : revues ou analyse statique du code) En fait les tests statiques correspondent à l’ensemble des tests qui ne nécessitent pas l’utilisation ou l’exécution du logiciel. Les tests statiques peuvent être utilisés à toutes les étapes d’un cycle en V : Le principal « type » de test statique c’est les « revues ». On a différents types de revues : · Les revues des documents tels que les expressions de besoins, les cahiers des charges, les plans de test… · Les revues de codes (pour le code et/ou les tests
La visibilité des tests
Suite à des entretiens passés récemment je me suis aperçu que le principal reproche remonté par les managers aux équipes de test était souvent le manque de visibilité sur les tests. « Je ne sais pas ce qui est testé », « je ne sais pas comment c’est testé »… Ces retours sont particulièrement présents sur des projets en mode Scrum et tendent à prouver qu’à un moment il y a un problème de communication, ce qui est particulièrement problématique car la communication est une des bases du métier du test. Les logiciels sont testés dans le but de récolter de l’information, de savoir si
Mesurer l’efficacité des campagnes de test
Ce poste est inspiré de cet article en anglais, qui, comme celui qui a inspiré mon précédent article, a été écrit par Ruslan Deystnikov. Le problème initial est simple : comment connaitre et mesurer l’efficacité des campagnes de test ? Comme vous le savez, la communication est une des bases du métier du test, un testeur doit donc savoir comment communiquer sur l’efficacité de son travail… Cela se révèle néanmoins assez compliqué, en effet mesurer des évènements qui ont été évités (et donc n’ont pas eu lieu) est un exercice qui peut se révéler compliqué. Pour pouvoir répondre au moins en partie à
Automatiser ou ne pas automatiser? Telle est la question.
Cet article est fortement inspiré de celui-ci, que j’ai lu grâce au groupe Ministry Of Testing un groupe que je recommande fortement à tous les testeurs qui ne sont pas allergiques à la langue de Shakespeare. Pour ces mêmes personnes voici ma version (librement interprétée, ce n’est pas une traduction) mais dans la langue de Molière. L’idée est de déterminer s’il est intéressant ou non d’automatiser et si oui, quels sont les problèmes fréquemment rencontrés avec l’automatisation. Pour rappel j’avais déjà fait un article sur l’intérêt ou non d’automatiser. Ce dernier va étudier le sujet plus en profondeur. Les conditions pour que
KDT: Keyword Driven Testing
On parle toujours de tests manuels et de tests automatisés mais rarement de Keyword Driven Testing (KDT). A quoi cela correspond exactement le KDT ? Repartons de la base. Les tests manuels Un test manuel bien écrit est une suite d’actions entraînant chacune un résultat à vérifier Prenons un exemple : lire un mail sur une application android : Ici si un résultat n’est pas validé ou une action impossible alors le cas est en échec. Sinon il est en succès. Les tests automatisés A partir d’un cas de test manuel bien écrit on peut développer un cas de test automatisé. Pour une application