Tous les articles
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
Les données de tests
Les données de test font partie intégrante des environnements de test et de leurs qualités dépend la qualité des résultats des tests exécutés. En effet, de mauvaises données peuvent engendrer des résultats de test erronés ou faire perdre beaucoup de temps d’analyse aux personnes travaillant sur l’analyse des bugs détectés. Quels sont les problèmes pouvant engendrer de mauvaises données de test ? Comment faire pour éviter résoudre ces problèmes et avoir des données de test de bonne qualité ? J’espère que vous aurez, au moins en partie, une idée de la réponse à ces questions après avoir lu cet article. Les problèmes engendrant des