API testing

 

Developers use Application Programming Interfaces (API) when they work in developing an application. Frameworks are one example of that (I already talked about frameworks in a previous article). One type of testing that testers use to assess the quality of an application integration testing.  Integration testing aims at checking if the modules of the application, developed by various programmers, integrate well with one another. You can refer to my article on integration testing in that blog. Testers can not only test the application that is being tested : they can also test the tool (API) programmers use to develop their application. APIs provide means to facilitate the communication between various elements within the application itself, and with external elements such as the operating system. By testing the API directly, the tester will know if there will be any problems in relation to the communication of all these elements between each other, as the means provided by the API to the application being developed will be defective. I suggest you to read the following article on Wikipedia to know more about API testing :

https://en.wikipedia.org/wiki/API_testing

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…