Réponse.

L'organisation des tests manuels lors de la phase de lancement est un ensemble de mesures pour identifier rapidement et efficacement les défauts dans la version du produit prête à être mise en production, en se concentrant sur les fonctionnalités les plus critiques et les plus utilisées.

Historique de la question : Dans le passé, les lancements étaient souvent accompagnés de "crises nocturnes" : les testeurs se dépêchaient de tout vérifier, ce qui affectait la qualité des tests, des bugs "passaient" en production, et les ressources étaient utilisées de manière inefficace. Il a été progressivement remarqué qu'en établissant clairement les priorités, on pouvait obtenir de meilleurs résultats en moins de temps.

Problème : Le temps limité pour les tests avant le lancement ne permet pas de tout vérifier, de plus, le facteur humain s'accumule : fatigue, précipitation, stress. Souvent, des bugs critiques ne se manifestent qu'après le lancement, ce qui nuit à la réputation du produit et crée le chaos au sein de l'équipe.

Solution :

En collaboration avec l'entreprise, les analystes, évaluer les scénarios critiques et ayant une signification commerciale.
Élaborer une liste de contrôle de lancement avec des scénarios dits "coupants" — ceux qui sont les plus utilisés ou à risque.
Effectuer un dernier test de smoke et de sanity manuellement : vérifier le démarrage du système, le processus de connexion, la finalisation des commandes, les paiements, etc.
Clarifier les zones de responsabilité : qui est responsable des données de test, qui est responsable des rapports sur les défauts trouvés, qui est responsable de la communication avec le développement.

Caractéristiques clés :

Priorisation des bugs : identifier et escalader les critiques en premier.
Utilisation de cas de test courts et exécutables rapidement ainsi que de listes de contrôle.
Communication rapide avec l'équipe de développement pour une correction rapide.

Questions piégées.

Est-il possible de "précautionner" et de vérifier manuellement toute l'application avant le lancement ?

Non, il n'y a généralement pas assez de temps pour des tests manuels complets — une approche réfléchie avec un focus sur les scénarios clés donne de meilleurs résultats.

Faut-il signaler les "petits" bugs avant le lancement pour que l'équipe soit au courant ?

Non, en mode lancement, il est nécessaire d'escalader uniquement les défauts critiques et bloquants, tandis que ceux moins significatifs peuvent être documentés comme des problèmes connus et traités après le lancement.

Est-il obligatoire d'écrire manuellement des cas de test détaillés pour la phase de lancement ?

Non, il est souvent plus simple et plus rapide de travailler avec des listes de contrôle ou des mini-scripts dérivés des cas de test, ce qui permet de parcourir rapidement les scénarios pertinents.

Erreurs typiques et anti-modèles.

Reporter les tests jusqu'aux dernières heures — ce qui entraîne un travail effectué dans la précipitation, avec une perte de qualité.
Tester des scénarios rarement utilisés ou peu importants au détriment des scénarios clés.
Absence de tests de smoke/sanity juste avant le lancement.

Exemples de la vie.

Cas négatif.

Des tests de lancement sont effectués la nuit, tout en vérifiant rapidement les documents, et on oublie le flux critique de paiement. Le lendemain, les utilisateurs ne peuvent pas payer leurs commandes en masse.

Avantages :

Grande rapidité de vérification.

Inconvénients :

Un bug critique n'est pas détecté.
Risques stressants au milieu de la nuit, communication perdue avec le développement.

Cas positif.

Avant le lancement, l'accent est mis uniquement sur les scénarios critiques (connexion, paiement, sauvegarde de la commande, intégration avec des partenaires). Les résultats sont passés en revue selon une liste de contrôle, les bugs sont escaladés instantanément.