Tous les articles
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
Les plans de test
Définition ISTQB : un document décrivant l‘étendue, l‘approche, les ressources et le planning des activités de test prévues. Il identifie entre autres les éléments et caractéristiques à tester, qui fera chaque tâche, le degré d‘indépendance des testeurs, l‘environnement de test, les techniques de conception des tests et les techniques de mesure des tests à utiliser, et tout risque nécessitant des plans de contingence. C‘est un document reprenant les processus de planification des tests [d‘après IEEE 829] Un plan de test définit donc ce que l’on va tester, comment on va le tester mais aussi ce qui ne va pas être testé. Une
TDD: Test Driven Development
Définition Le TDD (Test Driven Developement) est, comme son nom l’indique, une méthode de développement. Elle consiste à écrire les tests avant d’écrire le code. Le but est donc pour l’équipe projet de développer un logiciel construit par la validation de tests plutôt qu’un logiciel construit par le suivi des spécifications. Le TDD est donc une méthode de travail différente du BDD (Behaviour Driven Developement) où le développeur développe en fonction des spécifications fonctionnelles puis écrit les cas de tests unitaires, les autres niveaux de tests étant exécutés ultérieurement. Fonctionnement du TDD Le TDD fonctionne par cycle. · On écrit d’abord un