Vidéo sur le “test reporting”

https://youtu.be/BBmA5Qp6Ghk

C’est une vidéo simple, pas longue, et d’une grande clarté.

Elle montre le lien entre les tests scenarios et les test cases.

Comme le dit le formateur durant la vidéo, “Testing is all about being very specific” :  quelles données va-t-on utiliser comme intrant (input) exactement pour faire le test ?  (dans le cas d’un formulaire Web, comme une page de login d’une application).

Il présente le concept de “test data”, c’est-à-dire l’input utilisé pour faire des tests.

Le formateur insiste sur l’importance de documenter les tests, c’est-à-dire de consigner par écrit démarche, résultat des tests, etc.

Il évoque l’importance d’écrire un verdict (pass / fail) après chaque test fait, parce qu’il faut communiquer un verdict pour que d’autres employés de l’entreprise (les développeurs, par exemple), soient informés du résultat des tests.

Advertisements

La technique exploratoire

C’est une vidéo sur la technique de test dite “exploratoire”.  Le message que le formateur y communique, c’est que, si on teste toujours de la même façon, on va toujours trouver les mêmes types de défauts.  Il faut explorer ailleurs, tester autrement, pour pouvoir aussi trouver d’autres types de défauts.

Il y a aussi des lignes directrices qui orientent le regard du testeur.  Le parcours suivi par le testeur n’est pas complètement aléatoire.

https://www.youtube.com/watch?v=piNigC1cRV4

Les langages de programmation les plus utilisés à Montréal

Je me suis demandé à l’été 2016, “quels sont les langages de programmation les plus utilisés à Montréal”.  En passant en revue les offres d’emploi qui étaient alors affichées sur le Web et en comptant le nombre de fois que revenait chaque langage de programmation, j’ai conclu que les 5 langages les plus utilisés étaient HTML, SQL, JAVA, C++ et C-# qu’on appelle “C-sharp”.  Je me suis rendu compte au cours du mois de novembre 2016 que les technologies .NET (comme le langage ASP.NET) étaient aussi très présentes.  JQuery et javascript sont aussi assez utilisés, mais pas aussi fréquemment que les précédents.

Quand on se promène sur l’Internet et qu’on pose (en anglais) une question comme “Quels sont les langages de programmation qu’il faut apprendre actuellement ?”  on liste des langages émergents comme Ruby ou Python.  Ces langages sont encore peu utilisés à Montréal.  Perl semble faire son apparition dans le domaine du test de logiciels pour faire des scripts d’automatisation des tests, mais son emploi est loin d’être généralisé.

Quand est-ce qu’on arrête de tester ?

Une des grandes questions, dans le test de logiciels, c’est de déterminer quand on va finir de faire des tests.  On peut fort bien dire “on va arrêter de tester quand on aura testé tout ce qu’on devait tester”, mais la réponse, dans les faits, n’est pas aussi simple.

Tester prend du temps.  Le plus souvent, on arrête de tester à cause de contraintes de temps et/ou de budget.  Le rapport de l’ISTQB qui présente l’état de la profession de testeur de logiciels en 2015 abonde dans le même sens.  (On peut lire ce rapport en cliquant sur cette phrase)  Il faut comprendre, dans ce cas, qu’on voulait tester X, Y et Z, mais, dans les faits, comme on n’a pas eu assez de temps pour le faire, on n’a testé que X et Y.  Ce qui veut dire qu’on teste incomplètement des logiciels et on les lance comme tels.
Des testeurs prônent qu’on décide de façon rationnelle quand s’arrêter de faire des tests.  (Ces testeurs parlent souvent d’une façon scicientifique, plutôt que rationnelle ;  peu importe le terme utilisé, l’idée est la même.) “Rationnelle” veut dire que l’idée d’arrêter de tester d’après des contraintes de temps et de budget ne leur apparaît pas justifiée.  Ils prônent donc qu’on s’assure de couvrir suffisamment le logiciel avant de mettre fin aux tests.  Le concept de “coverage” est donc apparu.  Le concept de “coverage” renvoie habituellement au code de l’application.  Il faut tester jusqu’à ce qu’on couvre un certain %, jugé acceptable par l’entreprise, du logiciel :  100 %, 80 %, etc.  Les tests prennent fin lorsque cette norme est atteinte.

On peut cependant penser que le concept de coverage s’applique à d’autres composantes du logiciel que son seul code.  L’ensemble de ses fonctions, par exemple.  Ainsi, le concept de coverage voudrait que .. %  des fonctions de l’entreprise soient testées par des tests fonctionnels.

On dit habituellement que Wikipedia n’est pas une référence.  Cette phrase cependant, quant aux avantages du “white box testing”, est sans équivoque :  “White-box testing give clear, engineering-based, rules for when to stop testing”.  Engineering-based, scientifique, rationnel :  ce sont tous des termes différentes pour communiquer le même concept :  l’idée d’avoir une règle pour déterminer quand arrêter les tests, qui ne relève pas de contraintes de temps ou financières.   Le rapport de l’ISTQB sur la profession de testeur de logiciel dans le monde en 2015 montre que l’idée d’arrêter de faire des tests selon un % de coverage du code du logiciel fait son chemin dans le milieu du test de logiciels.

L’AST, une association de testeurs de logiciels, prône aussi une méthode “scientifique” dans l’exécution des tests, et on peut donc penser, la détermination du moment où mettre fin aux tests également.

Quand j’ai écrit cet article-ci, je ne voulais pas me poser la question “qui a raison” et “qui a tort”.  Je voulais simplement montrer qu’il y a différents points de vue sur quand on devrait s’arrêter de faire des tests.