STLC - Le cycle de vie des tests logiciels dimanche 29 avril 2018

Dans le cadre d'un projet de développement logiciel, l'ensemble des activités de test peut être divisé en plusieurs étapes. Comme pour le cycle de vie de développement logiciel (SDLC), il existe également un cycle de vie pour les tests logiciels (STLC).

L'image ci-dessus est une représentation des différentes phases du cycle de vie des tests logiciels.

Phase 1 : Analyse des exigences

Il s'agit de la première étape du cycle. L'équipe de test analyse attentivement les exigences du produit. En cas de conflit, d'omission, d'imprécision ou d'incompréhension, l'équipe de test sera amené à discuter avec les différents acteurs du projet comme par exemple l'analyste fonctionnel ou l'architecte logiciel.

Phase 2 : Planification

Durant cette étape l'équipe de validation planifie l'ensemble des activités de test à travers la rédaction d'un plan de test. La rédaction de ce document sert principalement à déterminer :

• les objectifs à atteindre.
• les processus et les méthodes à mettre en place 
• l'environnement et les outils qui seront utilisés.
• les éléments à tester ou à ne pas tester.
• l'organisation de l'équipe et la répartition des tâches.
• les jalons des différentes activités.
• les risques qui peuvent survenir.

En plus de la rédaction du plan de test, une estimation des coûts est réalisé pendant cette phase.

Phase 3 : Rédaction des tests.

Un analyste de test rédige les cas de test et vérifie que chaque exigence est couvert par un ou plusieurs tests grâce à une matrice de traçabilité test/exigence.

Phase 4 : Installation de l'environnement de test

Un environnement permettant de tester l'application et de reproduire les anomalies doit être mis à disposition. Sa mise en place est vérifié via l’exécution de smoke test.

Phase 5 : Exécution des tests

Il s'agit tout simplement de l’exécution des tests. Durant cette phase, les testeurs peuvent identifier d’éventuelles anomalies et tester les correctifs des développeurs. En général, l'échec d'un test est associé à un un bug. Des tests de non régression automatisé peuvent être lancés régulièrement.

Phase 6 : Clôture du cycle 

Le logiciel va être déployé. L'équipe de validation se réunit pour analyser les résultats et identifier les choses à améliorer pour les projets avenirs.

* STLC = Software Testing Life Cycle


Références:

• « Cognizant TMMi Capabilities & Success Case Study - tmmi.org»
• « Towards Automation in Software Test Life Cycle Based on Multi-Agent - ieeexplore.ieee.org»

Rediger un plan de test dimanche 22 avril 2018

Selon l'Institute of Electrical and Electronics Engineers (IEEE), un plan de test est un document qui décrit l'étendue, l'approche, les ressources et la planification des activités prévues. Sa rédaction s'effectue généralement juste après la phase d'analyse des exigences.

Il existe deux types de plan de test :

• Le plan de test maître qui a pour but de décrire la stratégie de test sur un projet particulier.
• Le plan de test de phase qui a pour but de décrire de manière détaillé les activités à mettre en œuvre pour chaque niveau de test.

En fonction du contexte, le plan de test maître et le plan de test de phase peuvent former un seul et même document. D'après le standard IEEE 829-2008, ce document peut être structuré comme ci-dessous :

1. Identifiant
2. Références
3. Introduction
4. Eléments à tester
5. Fonctionnalités à tester
6. Fonctionnalités à ne pas tester
7. Approche stratégique
8. Critères de succès et d'échec
9. Reprise et de suspension
10. Environnement et outils
11. Rôles et répartition des tâches
12. Besoins en formation
13. Planning des activités
14. Risques et contingences
15. Livrables
16. Approbation
17. Glossaire

01. Identifiant

Il permet d'identifier le document sans ambiguïté. Il s'agit le plus souvent d'un identifiant alphanumérique. Cet identifiant doit être unique. Pour un meilleur suivi des modifications, le plan de test doit contenir un historique de révision avec la date, la description et l'auteur de la modification.

02. Référence

La partie « Références » a pour but de lister les documents qui ont permis la rédaction du plan de test. Il peut s'agir de documents externes ou internes à l'organisation. Le dossier de spécifications fonctionnelles détaillées ou le cahier des charges sont des exemples de document qui peuvent être listé dans cette partie. L'emplacement de chaque document doit être indiqué.

03. Introduction

Il contient les objectifs et un résumé des informations que donnera le plan de test. Cette partie peut également contenir une brève description du produit et une explication du contexte. Le rôle des parties prenante concernés par la rédaction du plan de test doit être évoqué.

04. Eléments à tester

Il s'agit tout simplement de la liste des matériels et des logiciels à tester. Cela correspond à ce qui sera livré avec le produit et non les fonctionnalités fournies par le produit.

05. Fonctionnalités à tester

Cette partie décrit les caractéristiques fonctionnelles et non fonctionnelles qui doivent être testées. Il contient les références aux documents de spécification des exigences.

06. Fonctionnalités à ne pas tester

Ce sont les caractéristiques fonctionnelles et non fonctionnelles qui ne seront pas testées. Dans cette partie, les raisons expliquant pourquoi ces fonctionnalités ne seront pas testées doivent être décrites.

07. Approche stratégique

Il s'agit de la stratégie globale qui sera utilisé pour tester le produit. C'est dans cette partie que seront décrits le processus de gestion des anomalies, les types et les niveaux de test, les dispositifs de suivi et de contrôle des activités de test, etc

08. Critères de succès et d'échec

Cette partie décrit les critères à utiliser pour déterminer si une campagne de test est un échec ou un succès. On peut par exemple considérer qu'une campagne avec 98% de test à l'état réussi et deux bugs cosmétiques est une réussite.

09. Reprise et suspension

Dans cette partie, il faut spécifier les critères à utiliser pour suspendre ou reprendre les activités de test. Il faut également décrire les tâches à réexécuter en cas de reprise.

10. Environnement et outils

Il s'agit de lister les outils et les matériels nécessaires à l'exécution des tests et éventuellement de décrire le fonctionnement de l'infrastructure.

11. Rôles et répartition des tâches

Il faut identifier les tâches nécessaires à la préparation et à l'exécution des tests et indiquer les personnes responsables de chaque tâche.

12. Besoins en formation

Il s'agit de déterminer les compétences et les besoins en formation. Cela peut inclure les formations sur l'utilisation de l'application à tester et des formations sur l'utilisation d'outils et de méthodes.

13. Planning des activités

Il s'agit d'établir un planning pour les différentes activités de test.

14. Risques et contingences

Il s'agit d'identifier les contraintes et les risques important qui peuvent survenir durant l'exécution des activités de test. Il faut définir un plan d'urgence pour chaque risque.

15. Livrables

Il s'agit d'identifier tous les livrables qui seront produits au cours des activités de test, par exemple les cas de test, les rapports d'anomalies, les rapports de test, les fichiers logs.

16. Approbation

Il contient la liste des personnes qui doivent lire et approuver le plan de test. Les approbations doivent être datées et signées.

17. Glossaire

Cette partie doit fournir une définition des termes, des abréviations et des acronymes utilisés dans le plan de test.

Remarque :

Pour la rédaction des plans de test, il existe une autre norme beaucoup plus récente:  ISO/IEC/IEEE 29119-3 (Part 3) - Test Documentation

A lire aussi:

• « STLC - Le cycle de vie des tests logiciels »
• « Comment rédiger un rapport de bug ? »

Références:

• « Glossaire CFTL/ISTQB des termes utilisés en tests de logiciels »
• « Syllabus Niveau Avancé Test Manager »
• « IEEE Std 829-2008 : Standard for Software and System Test Documentation »
• « ISO/IEC/IEEE International Standard - Software and systems engineering - Software testing - Part 3 : Test documentation »

TestLink - Guide d'installation samedi 17 février 2018

L'installation de TestLink nécessite plusieurs prérequis:

• Un serveur web (Apache 1.3.x, 2.x, IIS 3 , etc).
• Un système de gestion de base de données (MySQL, MariaDb, Postgres).
• Php 5.2 ou Php 5.6 .

Pour effectuer une mise à jour consulter l'article ci-dessous:
TestLink - Comment effectuer une mise à jour de version ?

Environnement :

Système d'exploitation	Debian 9.3
Serveur web	Apache 2.4.25
PHP	PHP 7.0.27-0
Système de gestion de base de données	MariaDB 10.1.26

Etape 1: Télécharger TestLink

$ wget https://github.com/TestLinkOpenSourceTRMS/testlink-code/archive/1.9.16.tar.gz

Vous avez aussi la possibilité de téléchager les différentes versions de TestLink: https://github.com/TestLinkOpenSourceTRMS/testlink-code/releases

Etape 2: Ensuite décompresser le fichier

$ tar zxvf 1.9.16.tar.gz

Etape 3:  Renommer le dossier testlink-1.19.16 et déplacer le dans le répertoire web

$ su
# mv testlink-code-1.9.16 testlink
# mv testlink /var/www/html

Etape 4: Donner les droits en écriture à certains sous-dossier du répertoire TestLink

# chmod 777 /var/www/html/testlink/gui/templates_c
# chmod 777 /var/www/html/testlink/logs
# chmod 777 /var/www/html/testlink/upload_area

Etape 5: Créer les dossiers qui serviront au stockage des pièces jointes et des logs.

# mkdir /var/testlink
# mkdir /var/testlink/logs
# mkdir /var/testlink/upload_area
# chmod -R 777 /var/testlink

Etape 6: Créer le fichier "config_db.inc.php" dans le dossier /var/www/html/testlink/
Ce fichier contiendra les paramètres de connexion à la base de donnée de TestLink.

# touch /var/www/html/testlink/config_db.inc.php
# chmod 777  /var/www/html/testlink/config_db.inc.php
# exit

Etape 7: Ouvrir un navigateur web et saisir l'url pour accéder à la page d'installation de TestLink (http://votre_host/testlink/install). Puis cliquer sur "New Installation".

Etape 8: Cocher la case "I a agree to the terms set out in the licence" et cliquer sur continuer.

Etape 9: Lors du contrôle des prérequis systèmes, vérifier qu'il n'y ait pas de messages d'erreur.

Etape 10: Définir les différent paramètres qui serviront à la création d'un base de données pour TestLink.

Etape 11: Démarrer le processus d'installation en cliquant sur "Process TestLink Setup".

Etape 12: Vérifier si l'installation s'est déroulé correctement

Etape 13: Connectez-vous à TestLink. Le login est est "admin" et le mot de passe est "admin".

Lien de connexion: http://votre_host/testlink/login.php

Etape 14: Désactiver les messages d'avertissement


$ su
# nano /var/www/html/testlink/config.inc.php

Remplacer 'FILE' par 'SILENT' et enregistrer les modifications (CTRL + O).



A lire aussi:

• Introduction à TestLink
• TestLink - Guide rapide d’utilisation
• TestLink - Comment effectuer une mise à jour de version ?
• TestLink - Automatiser le reporting des résultats d'une campagne de test

Références:

• « TestLink Installation manual - github.com »
• « TestLink - Open Source Test Management - linkedin.com »

Introduction à TestLink samedi 3 février 2018

TestLink est une application web permettant la gestion des activités de test. Comme tout outil de gestion de test, il fournit quatre fonctionnalités principales qui sont :

• La gestion des cas de test.
• La gestion des exigences. 
• La gestion et l’exécution des campagnes de tests.
• Le report des résultats.

TestLink peut s'intégrer avec différents gestionnaires d'anomalie comme Jira, Mantis, Bugzilla ou Trac. Il offre aussi la possibilité d’automatiser un certain nombre d'action via une API utilisant le protocole XML-RPC. Les cas de test, les exigences et les résultats peuvent être exportés sous divers formats comme word ou excel.

TestLink est codé avec le langage PHP et son usage nécessite l'installation de MySQL, Postgres ou MS-SQL.

Fonctionnement


L'utilisation des fonctionnalités de TestLink ne peut se faire sans la création d'un projet de test. C'est l'objet principal de TestLink. Un utilisateur peut par exemple créer un projet de test pour un produit. Les exigences, les cas de tests, les campagnes de tests et les résultats sont inclus dans un projet de test. Des comptes utilisateurs avec des rôles différents peuvent être associés à un ou plusieurs projets.

Licence

Le code source de TestLink est sous licence GPL v2 et peut être consulté sur GitHub. Le projet est maintenu par une communauté de testeurs. De nombreux membres de l'équipe occupent des postes de management dans le domaine de l'assurance qualité.

Bilan

+    Open source.
+    Ergonomique et intuitif.
+    Accessible depuis un simple navigateur web.
+    Outil assez complet.

-     Les analyses graphiques proposées sont assez pauvres.


A lire aussi:

• Installer TestLink
• [TestLink] Automatiser le report des résultats
• TestLink : Configurer les paramètres SMTP

Références:

• « TestLink Project - sourceforge.net »
• « TestLink Project - github.com»
• « TestLink - Open Source Test Management - linkedin.com »
• « Forum TestLink XML-RPC API - forum.testlink.org »