Serie of training videos on virtualization with Hyper-V

One of our teachers said it is very important for testers to know how to do virtualization.  I’ve found a very good serie of training videos on Youtube on that topic.  Here’s the link for the video playlist :

 

According to this teacher, virtualization is important as it enables testers to install a version of the application they can test, rather than do their tests in the application “in production mode”, i.e., that is currently running and being used by company employees or clients.

Some frameworks contain unit tests

Developers often use frameworks when they develop an application. A framework is a tool that writes parts of code for programmers, so that they don’t have to write it themselves. It fastens up the development of an application and makes it easier. Frameworks contain other resources that can be used : some of these are unit tests. These tests can be used to perform test on the application this is being or has been developed.

Page Wikipédia sur le test de logiciels

Je mets le lien vers l’article de Wikipédia sur le test de logiciels comme je trouve qu’il amène des idées différentes qu’il veut la peine de lire.

  • Concept de test de «hardware», en sus de celui du test de logiciel
  • L’article parle de «comportement problématique» d’un logiciel plutôt que de «défauts».
  • Il y a l’idée que le système doive réagir non seulement de la façon prévue par le client, mais aussi par les développeurs.
  • L’article affirme qu’on bon test doit être répétable.

L’article renvoie à plusieurs autres pages que vous pourriez trouver intéressantes.

Voici le lien pour l’article sur le test de logiciels sur Wikipédia :

https://fr.wikipedia.org/wiki/Test_%28informatique%29

Testing according to the “extreme programming approach”

Extreme programming proposes another approach to white box testing.  I’ve found it interesting, so I’ve entered it here :

Most code in a system is unit tested, but not necessarily all paths through the code. Extreme programming mandates a “test everything that can possibly break” strategy, over the traditional “test every execution path” method. This leads developers to develop fewer tests than classical methods, but this isn’t really a problem, more a restatement of fact, as classical methods have rarely ever been followed methodically enough for all execution paths to have been thoroughly tested.[citation needed] Extreme programming simply recognizes that testing is rarely exhaustive (because it is often too expensive and time-consuming to be economically viable) and provides guidance on how to effectively focus limited resources.

Source :
https://en.wikipedia.org/wiki/Unit_testing#Unit_testing_limitations

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.