Testing pour les programmeurs

La plupart des programmeurs ne aiment pas les testeurs. Il est évident de ne pas aimer quelqu’un qui critique ton travail. L’expérience en testing chez les programmeurs se limite à des tests JUnit, qu’ils jettent à tester une fonction ou une parte de code. Donc logiquement qu’ils pensent testeurs ne sont pas nécessaires et si un programme a été écrit correctement et testé correctement au niveau des fonctions, ce programme va aussi marcher très stable quand on le mettra dans l’environnement « prod ». Les utilisateurs finaux, qui arrivent plus tard pour se plaindre que le bouton « finish » après l’affichage d’un image provoque un erreur fatale , ça donne à notre ami programmeur mal de tête et l’intention de jeter le PC à l’utilisateur.

Je ai travaillé comme un testeur pendant 3 ans après avoir travaillé comme développeur pour 4 ans et je peux dire que le travail dans le monde testing m’a vraiment aidé à devenir un meilleur programmeur. Mais non parce que on apprend de nouveaux trucs , mais parce que on gagne la vision de l’utilisateur final sur notre programme, une vision de métiers, donc ma manière de programmer devient plus « user friendly » (j’ai commencé à prêter plus d’attention puisque mes programmes seront confortables pour travailler avec).

Donc, maintenant on ouvre les horizons de testing pour les développeurs et de regarder au-dessus de JUnit. On utilise un exemple pour écrire un cas de test pour un écran de veille, qui est un rectangle, qui vole autour de l’écran et change sa couleur après une certaine période.

Vous voudrez poser les questions suivants à l’utilisateur:

– La taille du rectangle
– La couleur du rectangle
– Si le temps de changement devrait être dynamique ou constante et comment ça devrait être déterminé par l’utilisateur
– La vitesse du mouvement du rectangle , avec quelle il change sa position
– Sur quel système cet écran va être déployé?

Donc, ce sont les reqs qui sera la base pour les futurs cas de test. Ce sont aussi exactement les mêmes critères qui seront testés après.

Premier chose, qu’on doit être faire après que les spécifications du programme sont étés rédigés et approuvés, est d’écrire des scénarios de test basés sur ces spécifications. Chaque cas d’utilisation sera traduit dans le cas de test :

1. Tester la taille durectangle correspond aux specs
2. Tester la couleur durectangle correspond aux specs

…

Etc.

Pour être sure qu’on teste toute la fonctionnalité on fait une « matrice de couverture », ou on va inclure nos tests. La matrice donc va indiquer, si toute la fonctionnalité demandée par les utilisateurs (et résumée dans le document de l’analyse) sera testée. Donc, on prend un fichier Excel et note chaque « use case » avec son cas de test correspondant et vous assurer de couvrir 100% . On peut même essayer d’inventer nos propres use cases pour casser le programme!

Dans le rapport de test devraient figurer deux paramètres importantes: le pourcentage de tests exécutés et le taux de réussite, ce est à dire le pourcentage de tests ok vs ko. Pour chaque suite de tests on doit mesurer ce ratio, puis obtenir le total. On peut faire ca facilement avec Excel avant de jeter dans un joli tableau pour présenter aux chefs.

Une chose très importante est l’automatisation de test. Il existe des produits liés à QA-sur le marché tels que HP Quality Center (QC) ou IBM Functional Tester, qui vous aident à effectuer répétitions fastidieuses des suites des tests avec les paramètres différents. QC est en fait une suite complète, qui assure également le suivi sur les progrès de test et peut vous aider à recueillir des statistiques pour la présentation :

IBM Rational Functional Tester est une bête d’IBM semblable à HP QC:
Ou SmartBear TestComplete:

Pour certains types des tests il faudra besoin d’écrire nos propres scripts d’automation, ces scripts analysent différents params avec chaque course au programme et le relancent .

Dernière chose à mentionner: le testeur ne doit jamais être la même personne qui a développé le programme. La raison en est que le développeur sera «trop doux» avec son propre programme, plus on parle ici de principe de « 4 œil ». Il faut avoir quelqu’un autre qui devrait essayer de casser le programme avec les paramètres bizarres, ouvrir 40 fenêtres au même temps, etc. La meilleure chose est de donner à l’utilisateur final pour tester le programme. Cela devrait être fait après tous les tests fonctionnelles et non-fonctionnelles sont étés terminés et est une partie très importante afin d’obtenir moins de plaintes d’utilisateurs.