Comment améliorer la qualité du logiciel chez Spark Archives ?

Une partie de la réponse est dans la présence d’une activité de tests soutenue !

Parfois les tests sont là, au bon endroit et au bon moment, ce qui peut laisser croire que le principal est fait. Mais cela reste insuffisant sans une certaine rigueur, sans méthode, ou même sans traçabilité. L’optimisation de toutes ces tâches est au cœur des préoccupations de Spark Archives et nous y répondons de plusieurs manières.

Trouver des alliés performants

Tout d’abord, afin d’appliquer des bonnes pratiques, nous nous appuyons sur des normes reconnues :

• ISO 12207 : Processus du cycle de vie du logiciel.
• IEEE 829 : Documentation pour le test logiciel.
• IEEE 1044 : Classification des anomalies.
• ISO 27034 : Sécurité d'une application.

Après adaptation à notre propre contexte, nous avons défini une stratégie de test, dont une partie comporte la description de phases successives de tests techniques puis fonctionnels.

Les tests techniques

Les développeurs de la R&D s’acquittent des tests techniques, une multitude de types de tests sont réalisés tous les jours : qualité du code, tests unitaires, test de migration, test d'intégration, test de performance, test d’IHM ... certains tests de non-régression sont automatisés. Quant aux tests de sécurités, enjeu majeur pour un logiciel d’archivage électronique et nécessitant une expertise pointue, nous les avons externalisés chez un Prestataire d'Audit de la Sécurité des Systèmes d'Information (PASSI),  entreprise spécialisée dans le domaine.

Les tests fonctionnels

Après le travail de la R&D, une équipe de fonctionnels reprend le sujet afin de gagner en indépendance, celui qui créé n’est pas celui qui vérifie, cela permet d’assurer un œil critique plus performant dans la détection des défauts. A l’instar des développeurs, les méthodes sont multipliées. Nous commençons par une première batterie de tests en largeur, c’est-à-dire que nous nous assurons de passer partout au moins une fois. Après une première phase de correction, la deuxième batterie peut commencer, mais avec des tests en profondeur cette fois ci, les tests sont déroulés d’après leurs degrés d’importance. La deuxième phase de correction terminée, il s’agit enfin de tester le logiciel avec, en plus, des tests exploratoires réalisés par des archivistes. Cette étape permet de sortir des sentiers battus et aide à lutter contre le paradoxe du pesticide, qui veut que « les bugs finissent par s’adapter si on utilise toujours le même produit ».

Adapter les tests aux types de vérifications

Au « noyau » du logiciel testé, vient maintenant s’ajouter le paramétrage sélectionné par nos clients. Ces derniers ayant chacun leurs particularités, nous adaptons nos efforts suivant chaque besoin. Si un de nos clients demande une modification de paramétrage sur le logiciel déjà installé, l’effort sera différent d’un nouveau client qui souhaite reprendre toutes les données de son ancien système. L’optimisation des tests prend tout son sens dans ces cas de figures. Nous élaborons une succession de phases de tests adaptés à chaque client suivant sa demande, de plus chaque phase contient des procédures de tests uniques qui correspondent à son paramétrage propre.

Les tests en amont

Afin de tester au plus tôt, nous avons instauré, en plus des tests dynamiques cités plus haut, les tests statiques. Les spécifications sont confiées à l’équipe de test afin de déceler d’éventuelles incohérences ou oublis. Les cas de tests créés sont mis à disposition du développeur qui peut ainsi profiter en plus de sa propre analyse, de celle du testeur. Cette étape permet de prévenir l’erreur dans le code très en amont. Elle a l’avantage de réduire drastiquement le coût de correction des anomalies.

Le traitement des anomalies

L’activité des tests mène à la création de fiches anomalies. Celles-ci sont traitées par ordre de priorité. Les corrections des anomalies bloquantes sont un prérequis à toute livraison. Une solution de contournement peut être proposée en accord avec les clients lorsque la situation l’exige. Quant aux anomalies majeures et mineures, elles sont soumises à arbitrage afin de définir le réel intérêt à la correction et dans quel délai. Tout ceci est déterminé après concertation et approbation entre toutes les parties prenantes du projet.

Encore des tests

Lorsque toutes ces activités sont terminées avec les résultats attendus constatés, le logiciel peut être installé chez le client ou dans notre centre d'hébergement. Les tests ne sont pas pour autant terminés. Il est probable qu’une évolution soit demandée dans le futur. Afin de préparer cette éventualité, une campagne de tests de non régression est préparée à la clôture de chaque projet. Elle sera ainsi jouée ultérieurement s’il y a nécessité, à chaque application d’une évolution.

Le chemin ici décrit vous semble bien balisé ?

Je vous rassure, il ne l’est jamais, il faut constamment remettre en question ses choix, enrichir ses méthodes et les adapter, l’imprévu est le quotidien de l’équipe de test. Mais c’est aussi tout l’intérêt, celui qui permet d’entretenir la qualité d’un testeur : La curiosité !

Hamida VANDERDONCKT
Test Manager – Certifié ISTQB

Voir également

• La certification ISTQB
• Crédit photo : 123RF/Tashatuvango