Réponse.

Le test manuel lors de la phase de maintenance consiste à tester un système existant et fonctionnel lors de modifications, corrections de bogues ou intégrations de nouveaux composants.

Historique de la question

Auparavant, la maintenance était effectuée de manière résiduelle, souvent seuls les nouvelles fonctionnalités étaient testées. Cependant, au fil du temps, il est devenu évident que toute intervention pouvait affecter des scénarios déjà fonctionnels.

Problème

La situation suivante est typique :

Des modifications locales sont apportées, mais leur impact sur l'ancienne fonctionnalité est souvent sous-estimé
La régression survient dans des modules apparemment non liés
L'absence d'une approche systématique augmente le risque de « chutes » soudaines en production

Solution

Une organisation efficace du maintenance testing nécessite :

La création et la mise à jour constante d'un « ensemble de scénarios clés » qui sont vérifiés lors de chaque modification
L'utilisation de check-lists et de cartes de régression
L'intégration du testing exploratoire pour déceler des effets inattendus des modifications

Caractéristiques clés :

Réaction rapide aux petites modifications avec un minimum de retour en arrière
Focalisation sur des scénarios utilisateur réels qui peuvent être indirectement affectés
Flexibilité dans le choix de la méthodologie : des check-lists au testing exploratoire créatif

Questions pièges.

Faut-il tester uniquement les modules qui ont été modifiés ?

Non, il est nécessaire de tester également les parties du système qui y sont liées, afin de ne pas manquer les effets secondaires des modifications.

Un test de régression complet est-il suffisant après chaque correction ?

Non, il est souvent suffisant de vérifier les chemins clés (critiques), et un test de régression complet n'est effectué qu'avant une version ou lors de changements significatifs.

Peut-on complètement se passer du testing exploratoire lors de la phase de maintenance ?

Non, le testing exploratoire permet de trouver des bogues non triviaux en dehors de la couverture des scénarios et doit accompagner la phase de maintenance.

Erreurs typiques et anti-patrons

Négliger les modules liés : tester uniquement l'endroit « patché »
Absence d'un ensemble actuel de scénarios de régression
Ignorer la compréhension de l'architecture, ralentit la détermination des zones de risque

Exemple de la vie

Cas négatif

Après la correction d'un bogue dans un profil utilisateur, seul le profil est testé, mais l'authentification et l'affichage du profil sur d'autres pages ne sont pas vérifiés. En conséquence, un bogue apparaît : le profil n'est pas mis à jour sur la page d'accueil.

Avantages :

Conclusion rapide des tests d'une tâche spécifique

Inconvénients :

Omission de bogues dans des sections liées
Baisse de confiance envers QA et le produit

Cas positif

Le bogue corrigé dans le profil est testé tant séparément que de manière globale : vérification du profil partout où il est utilisé. Un check-list des scénarios clés est utilisée.