A great book on white box testing

Cem Kaner – a famous author on software testing – says that the book “The Craft of Software Testing: Subsystem Testing Including Object-based and Object-oriented Testing” by  Biran Marick on white box testing is a very good one.  If he says so, then it must be a very good one indeed.  Here’s the link on how to find the book on Amazon :

https://www.amazon.com/Craft-Software-Testing-Object-Based-Object-Oriented/dp/0131774115

 

 

Vidéo “How to write effective test cases”

https://youtu.be/-VvQKEvsPpE

Le formateur insiste sur l’importance que les tests cases fassent un coverage complet.

Le formateur propose une façon d’écrire des tests cases en n’y mettant pas trop de texte. Il montre 2 façons différentes d’écrire des tests cases et les compare à 7 minutes 17.  Le formateur suggère que “plus il y a de texte, plus il y a de chances d’erreurs dans le texte” (et donc dans la test case, qui ne testerait pas alors convenablement l’application).

Plusieurs offres d’emploi en test logiciel à Montréal demandent Excel.  On voit dans cette vidéo que le logiciel utilisé pour écrire la “test case” et consigner les résultats est Excel.  L’avantage d’utiliser Excel, selon le formateur, est d’avoir un “test case” sous la forme de tableau.

Le formateur dit qu’il est préférable d’écrire les test cases avant de faire les tests, plutôt qu’après, parce qu’elles peuvent servir de guide. (On peut imaginer qu’une personne fasse des tests et puis écrive les tests cases par après dans le but d’y consigner les résultats de ses tests. C’est le cas par exemple quand on utilise la technique “exploratoire”, puisqu’on explore, et on peut se retrouver dans une situation où on teste des applications sans avoir écrit des tests cases au préalable.)

Ce formateur a une série de vidéos sur Youtube.  Vous pouvez regarder les autres aussi !

Des testeurs parlent de leur profession

https://youtu.be/OLxaG0TNgMM

Toutes les offres d’emploi en test logiciel à Montréal soulignent l’importance de savoir bien communiquer. Les gens interviewés dans la vidéo donnent une idée pourquoi c’est important de savoir communiquer quand on travaille en test logiciel.

Une personne dit que si on ne fait que des tests fonctionnels, on pourrait ne pas voir certains défauts de l’application (pêut-être par rapport au code, par exemple).

Une autre personne interviewée rappelle que c’est utile de connaître le secteur (“business rules”, c’est-à-dire les règles propres à un domaine, exemple, en éducation, pour avoir une note en %, une personne doit être inscrite à un cours d’abord) pour lequel une application est faite.  Elle parle aussi de l’importance du “coverage”, de “couvrir” suffisamment l’application à tester.

Une autre personne dit qu’il faut savoir quoi choisir, c’est-à-dire quoi tester, parce que les testeurs vont manquer de temps pour faire leurs tests.

Integration Testing (black box non fonctionnel)

https://youtu.be/QYCaaNz8emY

https://youtu.be/fjOlGWR_hvI

La 2e vidéo présente plus en détail ce dont la 1re vidéo fait un survol.

La vidéo à 4:07 montre clairement les étapes, du “unit testing” au “system testing” en passant par le “integration testing”, du moins, dans le modèle de développement d’un logiciel en “V”.

La vidéo montre aussi que la “software architecture” tient compte de l’association de tous les modules développés par chaque programmeur, pour constituer le produit final.

On apprend dans la 2e vidéo que les “stubs” et les “drivers” sont des particules de code qui remplacent un module de l’application qui est absent, parce qu’il n’a pas été encore développé.

7 principles of testing

https://youtu.be/rFaWOw8bIMM

Un des principes proposés par la vidéo, quant au test de logiciels, est que “Exhaustive testing is not possible”.
C’est démontré de façon évidente dans la vidéo.

Le formateur souligne l’importance de créer de nouveaux “test cases” pour trouver de nouveaux types de défauts dans les applications testées, plutôt que de trouver toujours le même type de défauts (genre, la page de login ne fonctionne pas…)  D’ailleurs, on voit régulièrement dans les offres d’emploi la tâche, chez les testeurs, d’écrire des tests cases et de les mettre à jour.

Le but du test de logiciels, selon le formateur, c’est de trouver des défauts.  C’est pas parce que les tests n’ont pas trouvé de défauts, qu’on peut assurer les utilisateurs que le locigiel est sans défaut.  Il y a des défauts :  c’est juste qu’on ne les a pas trouvés…

Le formateur amène l’idée, dans sa vidéo, de “early testing”, pour prévenir la formation de défauts durant le développement de l’application, et éviter de tout devoir corriger à la toute fin de la programmation de l’application…

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.

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.