Comment effectuer efficacement les tests post-lancement et minimiser l'impact de la publication sur les clients en direct

how perform post release testing effectively

Quand j'ai commencé ma carrière en tant que QA, je travaillais avec une entreprise qui proposait ses produits en SaaS. Les versions de production étaient essentielles et il y avait une possibilité d'affecter la fonctionnalité pour les clients en direct.

Au fur et à mesure que notre base de clients augmentait, pour gérer le risque et minimiser l'impact de la publication sur les clients en direct, l'équipe d'assurance qualité a adopté la pratique des tests après la mise en liberté.

Tout cela était nouveau pour moi et j'avais tellement de questions et de doutes en tête:

• Qu'est-ce que les tests post-publication?
• J'ai tout testé correctement, pourquoi devons-nous faire des tests après la sortie?
• Dois-je tout tester à nouveau? Que dois-je faire exactement lors de la vérification après la publication?
• Que se passe-t-il si je trouve un problème? Etc.

Je suis heureux d'admettre que j'ai trouvé toutes mes réponses dans mes premières versions de production.

Ici, je partage cette connaissance avec vous tous. J'ai choisi d'écrire l'article sous forme de questions et réponses pour vous montrer comment j'ai découvert les réponses.

Ce que vous apprendrez:

• Qu'est-ce que la vérification des versions post-production?
• Quelles tâches et activités sont incluses dans la phase de vérification après la mise en liberté?
• Dois-je tout tester à nouveau?
• Comment formuler une stratégie de vérification des versions post-production?
• Qui crée le plan de test de publication de post-production?
• Qui approuve le plan de test de version post-production?
• Quand dois-je créer le plan de vérification des versions post-production?
• J'ai terminé la vérification de la version post-production. Et après?
• Que se passe-t-il si je trouve un problème?
• Que dois-je savoir d'autre sur le processus de vérification des versions post-production?
• Conclusion:
• lecture recommandée

Qu'est-ce que la vérification des versions post-production?

Par définition, Poster moyens Après , Production fait référence au déploiement aux environnements LIVE / production et Vérification comprend s'assurer que les fonctionnalités publiées répondent aux exigences .

Lecture recommandée=> Comment préparer efficacement «l'environnement de test» avant de commencer le test

L'objectif est de vérifier la sortie sur les environnements de production / LIVE.

test sql questions et réponses pdf

Mais les questions se posent alors:

• Pourquoi avons-nous besoin de faire des tests de publication de post-production alors que j'ai tout testé sur l'environnement QA?
• Pourquoi prévoyons-nous des problèmes en production alors que nous avons testé la version en profondeur sur l'environnement de test?

Il y a de nombreuses raisons pour lesquelles nous aurions des problèmes de production même si nous aurions pu suivre Processus d'assurance qualité (c'est à dire. planification des tests , revue du plan de test, cycle de test, tests de régression etc.)

Raisons pour lesquelles nous aurions des problèmes de production:

1) Problème de données - Les données disponibles sur les environnements de production et de test peuvent varier. Cela peut faire en sorte que certains problèmes de cas secondaires ne soient pas détectés dans les environnements de test.

2) Problème de déploiement - Si votre entreprise a un processus de déploiement de build manuel, votre version peut être plus sujette à des problèmes de déploiement. Certains scénarios courants peuvent être la configuration ou les paramètres de site manquants, les scripts de base de données manquants, l'ordre de déploiement non suivi (code d'abord, puis DB, etc.), les dépendances mal installées, etc.

Lire aussi=> Ce que le testeur d'assurance qualité doit savoir sur le processus de déploiement

3) Zones d'impact non identifiées - Il peut y avoir certains scénarios pour lesquels les zones impactées peuvent ne pas avoir été identifiées correctement et complètement par l'équipe.

Par exemple, considérez un SaaS environnement.

Si l'équipe n'a pas identifié l'impact d'une table DB re-factorisée sur un client utilisant un schéma de table plus ancien (par exemple, perte de données, besoin de migration de données avant la sortie, etc.), etc. Ce problème est moins susceptible de se produire pour des projets bien planifiés avec des exigences précises. Mais, la possibilité existe toujours.

4) Zones d'impact inconnues - Cela peut se produire si la portée et les zones concernées de la version ne sont pas connues. Par exemple, dans une entreprise disposant de plusieurs logiciels partageant une base de données et une architecture communes, même un petit changement peut interrompre la fonctionnalité de nombreux produits.

Quelles tâches et activités sont incluses dans la phase de vérification après la mise en liberté?

Les tâches et activités de publication après la production comprennent généralement:

• Vérification de la version post-production
• Signaler les résultats de la vérification
• Signaler tout problème détecté en production
• Nettoyage des données de vérification après la libération
• Surveillance après la libération (le cas échéant)

Dois-je tout tester à nouveau?

Pas nécessairement. Cela dépend de la version à publier et de l'analyse d'impact.

Des tests détaillés doivent être effectués au cours du cycle régulier d'AQ. La vérification après la sortie doit être effectuée en suivant un plan de test de vérification de la version post-production qui doit être un dérivé du plan de test complet pour cette version.

Comment formuler une stratégie de vérification des versions post-production?

La planification de la vérification des versions post-production doit être effectuée de la même manière que la planification des tests habituelle.

La stratégie doit être sur les mêmes lignes que le flux de test suivi pendant le cycle d'AQ. Il est important d'inclure les étapes les plus importantes et les plus critiques qui permettent une couverture maximale des fonctionnalités.

meilleur bloqueur de pop-up gratuit pour chrome

Une bonne stratégie de publication de post-production devrait:

• Inclure des étapes pour tester les nouvelles fonctionnalités ainsi que les principales fonctionnalités existantes
• Vérifier les principales zones d'impact
• Autoriser une couverture maximale des fonctionnalités
• Facultatif: incluez tous les bogues critiques trouvés dans l'environnement de test
• Facultatif: inclure la priorité des cas de test

Qui crée le plan de test de publication de post-production?

Cela variera d'une entreprise à l'autre et dépendra de la structure organisationnelle.

Prenons un exemple de l'organisation de l'équipe d'assurance qualité suivante.

Dans ce scénario, le contrôle qualité travaillant sur le projet spécifique formulera le plan de test de publication de post-production initial.

Qui approuve le plan de test de version post-production?

Cela variera d'une entreprise à l'autre et dépendra de la structure organisationnelle.

En considérant à nouveau la même structure organisationnelle que celle indiquée dans la question précédente, le plan de test de mise en production postproduction doit être revu et approuvé par le Test Lead ou le QA Manager .

Quand dois-je créer le plan de vérification des versions post-production?

Le plan de test de version de post-production peut être créé à tout moment pendant le cycle de développement logiciel une fois que les exigences, la portée du développement et les zones d'impact ont été identifiées et verrouillées. Il est généralement plus facile pour le QA de créer le plan de test de publication de post-production au milieu du sprint. Cela garantit qu'il y a suffisamment de temps pour l'examen et l'approbation.

Il est recommandé d'inclure ce plan de test avec tout documents officiels d'approbation d'AQ avant que le projet n'entre dans la phase de déploiement et de publication.

J'ai terminé la vérification de la version post-production. Et après?

Une fois la vérification post-publication terminée, les étapes suivantes seront

1) Communication des résultats de vérification - Les résultats de la vérification doivent être communiqués aux parties prenantes, y compris tous les problèmes qui ont pu être détectés lors de la production.

2) Signaler tout problème détecté lors de la production dans l'outil de gestion des défauts - À faciliter l'analyse des causes profondes et traçabilité .

3) Nettoyage des données de vérification après la libération - Le nettoyage des données doit être effectué une fois la vérification terminée.

Par exemple, considérez un version pour une application de commerce électronique et disons que vous avez créé une commande test en production. Cette commande de test doit être annulée une fois la vérification terminée.

4) Suivi de la mise en production après la production (le cas échéant) - Certaines versions nécessitent une surveillance en production.

Par exemple, si l'équipe apportait des améliorations pour améliorer les temps de chargement des pages dans l'application, cela devrait être surveillé sur une certaine période de temps pour s'assurer que l'amélioration était effectivement observée après la publication. La ou les personnes responsables du contrôle doivent être clairement identifiées et communiquées.

Que se passe-t-il si je trouve un problème?

Tout problème doit être signalé dans le Outil de gestion des défauts et communiqué aux parties prenantes. Si des problèmes critiques sont détectés lors de la production, la communication des résultats doit avoir lieu immédiatement car une décision doit être prise si la construction doit être annulée pour enquêter davantage sur le problème.

Il est important que tous les problèmes détectés soient signalés dans l'outil de suivi des défauts. Il est recommandé de les signaler en tant que type de problème distinct (par exemple, bogue de post-production) pour montrer la séparation des bogues du cycle d'assurance qualité régulier. Ces problèmes peuvent être facilement filtrés si nécessaire à des fins d'analyse des causes profondes.

Que dois-je savoir d'autre sur le processus de vérification des versions post-production?

Outre le processus, le plan et la stratégie de vérification des versions post-production, voici quelques conseils:

• Il est important de définir des attentes claires concernant la portée et le but de la vérification après la mise en liberté. Les parties prenantes (internes et externes) doivent être informées des
  • L'équipe ne peut pas tout tester en production
  • L'équipe ne peut pas réduire les jours de tests en quelques heures réservées à la vérification après la publication

Par conséquent, les tests de production seraient essentiellement basés sur un plan de test de mise en production post-production approuvé.

Limites:

Des précautions doivent être prises tout en décidant de l'étendue des tests de publication post-production. Il y a des limites à ce que nous pouvons réellement tester en production et dans quelle mesure. L'environnement de production contient des données client en direct et doit être traité avec beaucoup de soin. Une planification supplémentaire doit être effectuée pour les changements impliquant la migration, la mise à jour, la suppression des données, etc.

Exemple 1): Pour une entreprise eSurvey, si le test implique de répondre et de soumettre l'enquête, le contrôle qualité devra envoyer une demande de suppression de l'enquête de test après vérification afin de ne pas affecter les données de collecte de l'enquête client et leurs statistiques.

EST exemple n ° 2): Pour une entreprise de commerce électronique, supposons qu'une tâche SQL de mise à jour des prix s'exécute à minuit tous les jours et télécharge le prix définitif sur le site Web. Nous ne pouvons pas exécuter ce SQL à la demande, plusieurs fois à des fins de vérification post-publication, car cela peut entraîner le transfert de données non finalisées vers la production.

De plus, cela peut augmenter les chances de Blocages DB et une consommation élevée de ressources CPU et mémoire pendant les heures de pointe, ce qui peut affecter les performances de l'application cliente.

• L'effort requis pour les tests après la sortie et toutes les activités connexes doit être intégré et inclus dans le plan de projet. En fonction des règles de gestion et des spécificités du projet, cela peut être considéré comme une surcharge du projet ou inclus dans le cycle d'assurance qualité ou inclus dans le cadre du plan de gestion des versions.
• Pour les problèmes signalés lors de la vérification post-publication, une analyse des causes profondes doit être effectuée pour découvrir la raison pour laquelle le problème n'a pas été détecté tôt et ce qui peut être amélioré la prochaine fois pour éviter de faire face au problème. L'analyse des causes profondes peut aider l'équipe à tirer des leçons de ces problèmes passés et à combler les lacunes de la mise en œuvre. En fonction de la structure organisationnelle, le responsable du test ou le responsable QA peut effectuer l'analyse de la cause première avec la contribution de l'équipe de projet. Certaines causes fondamentales courantes peuvent être un problème de codage, un problème d'exigences, un problème de conception, un problème de données, des limitations tierces, un scénario de test manquant, etc. Des actions correctives et préventives correspondantes peuvent être créées et suivies.
• Journaux du serveur peut également être utilisé pour surveiller la construction après la publication. Journal du serveur peut contenir des événements ou des problèmes qui peuvent ne pas être visibles pour le client mais qui entraîneront des problèmes dans le backend. Cette surveillance peut être attribuée en tant qu'élément d'action au responsable du développement et à l'équipe DevOps.

Un exemple:

Aperçu du projet:

Les modifications suivantes doivent être apportées à une application de médias sociaux, en particulier au processus d'inscription

1. La validation du champ de nom doit être supprimée. Il était précédemment implémenté en tant que 'Le nom de famille doit comporter au moins 4 caractères' (Amélioration du champ existant)
2. Mettre en œuvre le bouton bascule à côté de l'adresse e-mail afin que l'utilisateur puisse définir les paramètres de confidentialité de l'adresse e-mail à afficher sur son profil (nouvelle demande de fonctionnalité)
3. L'utilisateur doit pouvoir choisir son avatar (nouvelle demande de fonctionnalité)
4. Réduisez les appels d'API pendant le processus d'inscription pour améliorer les performances des applications (amélioration)

Plan de vérification de la version post-production:

quel est le meilleur programme pour nettoyer votre ordinateur

Conclusion:

Avec la plupart des éditeurs de logiciels maintenant adopter la méthodologie Agile , le nombre de sorties de production a augmenté.

Par exemple, en utilisant Modèle de cascade , une équipe peut avoir une version de production tous les 1,5 mois, mais avec le processus Agile, la même équipe peut maintenant avoir une version de production toutes les 2-3 semaines.

Avec chaque version de production, nous avons la possibilité d'avoir un impact sciemment ou non sur les fonctionnalités des clients en direct. L'adoption de la vérification de la version post-production immédiatement après la publication peut apporter une confiance supplémentaire sur la version, tout en offrant le filet de sécurité de la restauration de la version avant que nos clients en direct ne rencontrent certains problèmes.

Pour les projets à fort impact / risque , le plan de vérification des versions post-production peut être structuré en fonction de la priorité du scénario de test. Le test de priorité critique peut être exécuté en premier et une communication envoyée aux parties prenantes sur les résultats et les problèmes éventuels. Si aucun problème critique n'est détecté, la vérification de la version post-production peut se poursuivre, sinon, la décision de restauration doit être prise afin de minimiser les temps d'arrêt des applications et leur impact sur les clients actifs.

Aditionellement, les tests de version post-production peuvent être automatisés et les scripts de test peuvent être exécutés à la demande après chaque version en tant que test de régression. Encore une fois, il faut être prudent lors de l'exécution des scripts de test automatisés en production, car cela peut affecter les données et les fonctionnalités du client en direct.

La vérification de la version post-production est la dernière ligne de défense pour toute entreprise de logiciels. Si nous n'attrapons pas les problèmes, nos clients le feront et cela peut être dévastateur pour la réputation de toute société de logiciels.

Afin de maintenir la fiabilité du produit, il est essentiel de vérifier les changements déployés en production immédiatement après le déploiement.

A propos de l'auteur: Cet article utile est rédigé par Neha B. Elle travaille actuellement en tant que responsable de l'assurance qualité et se spécialise dans la direction et la gestion d'équipes d'assurance qualité internes et offshore.

Partagez votre stratégie / conseils / expérience de test de publication de post-production avec nos lecteurs.

lecture recommandée

• Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
• Téléchargement de l'e-book 'Testing Primer'
• Mise en œuvre pratique en 7 étapes des tests manuels avant la mise en production
• Test de charge avec les didacticiels HP LoadRunner
• Flux de processus de contrôle qualité des tests logiciels pratiques (exigences de publication)
• Différence entre les tests de bureau, client-serveur et Web
• Qu'est-ce que le test gamma? L'étape finale du test
• Qu'est-ce que le test précoce: testez tôt, testez souvent MAIS comment? (Un guide pratique)