Beaucoup considèrent les tests sur les environnements de production comme une pratique nuisible: cela n'aide pas à empêcher les problèmes d'atteindre les utilisateurs finaux, mais indique plutôt qu'ils sont présents. De plus, le testeur est détaché du flux de travail et des techniques standard utilisés dans l'environnement de test. Je m'appelle Olya Mikhalchuk, je suis ingénieur QA dans la fintech ID Finance. Dans cet article, je vais expliquer pourquoi les tests sur la prod peuvent considérablement aider votre projet.
Pourquoi avez-vous besoin d'un contrôle qualité sur la prod, s'il existe un environnement de pré-production
Au cours du processus de développement logiciel, il existe toujours plusieurs environnements sur lesquels l'application est déployée. L'environnement que les utilisateurs finaux utilisent, comme vous le savez, s'appelle la production. En règle générale, il est supposé que les tests doivent être effectués dans un environnement séparé, le plus souvent dans un environnement QA ou Staging (pré-prod), pour empêcher les erreurs d'atteindre les utilisateurs. Mais il existe une technique telle que l'AQ sur prod, qui aide parfaitement à résoudre des problèmes qui sont physiquement impossibles à résoudre dans un environnement de test.
Quelles tâches QA on prod aide
1. Le problème des différences entre les environnements de mise en scène et de production.
La mise en scène est souvent considérée comme une copie de l'environnement de production, qui est inaccessible aux utilisateurs finaux, mais ressemble le plus à l'environnement de combat. Lorsque l'application est assez complexe, la synchronisation et la maintenance d'une telle mini-copie deviennent une tâche longue et pas toujours rationnelle.
Par exemple, sur notre projet, la pré-production est davantage utilisée pour les tests fonctionnels sur des scénarios de test faits manuellement. Il ne dispose pas de moyens techniques comparables à l'environnement de production. De plus, nous ne synchronisons généralement pas complètement les configurations et les bases de données avec l'environnement de production, ce qui n'interfère pas avec les tests fonctionnels. Pourquoi ne copions-nous pas l'environnement prod? Imaginez combien de ressources il faudrait pour créer une copie de, disons, Facebook, avec les mêmes serveurs, services, bases de données et configurations super puissants que sur la production. C'est en fait comment déployer une autre application du même type.
De plus, lors de l'intégration avec des services tiers, vous disposez toujours de paramètres différents pour les environnements de test et de combat (la même API). Je ne dis pas que les environnements de test et de mise en scène sont inutiles. Il n’est tout simplement pas possible de garantir à 100% qu’après avoir réussi certains tests sur un environnement, les services ne tomberont pas sur un autre. Des tests supplémentaires pour la production peuvent aider à résoudre ce problème.
2. Niveaux réels de multitâche et de charge.
Certaines erreurs ne peuvent être détectées que sous un niveau long et réel de multitâche et de charge de travail. Cela s'applique aux fuites de mémoire, à la stabilité, à la vitesse et à la stabilité du système. Par exemple, nous avons eu une situation où le problème des performances du système est survenu du fait que deux tâches gourmandes en ressources ont été effectuées dans le même intervalle de temps. Les développeurs ont optimisé le travail des tâches, l'équipe a fait des tests sur l'environnement de pré-production, livré les modifications, puis fait un contrôle de production.
3. Erreurs de déploiement
D'après la définition, le déploiement est l'installation par un groupe de travail d'une nouvelle version du code du programme de service dans l'infrastructure de production. Par conséquent, la meilleure façon de voir les erreurs de déploiement consiste à effectuer des tests dans le processus de déploiement lui-même.
4. Absence de suivi sur la pré-production
L'un des moyens les meilleurs et les plus indispensables pour contrôler le fonctionnement de l'application comme prévu est de surveiller certaines mesures. Par exemple, à partir d'exemples simples et des plus critiques: suivi du nombre d'inscriptions de nouveaux utilisateurs par heure, de la conversion d'une action cible en une autre, du nombre de prêts émis. Bien entendu, une telle surveillance n'a de sens que dans un environnement de combat.
5. La capacité d'analyser des scénarios d'utilisateur final pour l'utilisation du système
Production - un entrepôt de cas de test pour le testeur. Si possible, le testeur peut voir et traiter les scripts utilisés par les utilisateurs finaux, le testeur peut identifier les scénarios les plus critiques, ou trouver la cause du défaut, ou prêter attention aux cas non triviaux lors des tests sur la pré-prod.
6. La capacité de maintenir des statistiques et des mesures plus fiables de la qualité des logiciels.
Par exemple, le nombre d'erreurs dans les journaux d'une application ou d'un composant, les rapports de bogues et autres rapports qu'un pro-testeur peut faire, démontrent de manière plus réaliste la qualité du logiciel par rapport aux mêmes rapports de l'environnement de test.
7. Il est toujours préférable que l'erreur sur le prod soit remarquée par «votre» testeur plutôt que par l'utilisateur final.
Habituellement, après la livraison de la tâche, le testeur effectue des vérifications de base des fonctionnalités nouvelles ou modifiées sur le prod. De plus, nous avons une personne distincte dans notre entreprise - un testeur sur prod. Je tiens à nouveau à noter que je ne positionne pas l'AQ sur prod comme un substitut aux tests de pré-production, et, bien sûr, il est nécessaire de prévenir les bugs et de prendre des mesures préventives. Mais de tels tests peuvent être une excellente technique supplémentaire pour garantir la qualité de votre projet.
Pratiques QA utiles sur la production qui fonctionnent efficacement sur notre projet1. Vérifier les tâches livrées afin de s'assurer qu'elles sont bien établies et fonctionnent dans le nouvel environnement.
Par exemple, lorsque nous introduisons l'intégration avec un nouveau partenaire, en plus des tests sur la pré-prod, nous vérifierons définitivement l'intégration après la livraison, car il y a beaucoup de paramètres en fonction de l'environnement (API, URL, composants). Il y a aussi des problèmes de tiers - les erreurs ne sont pas de notre côté, mais du côté des services intégrés.
2. Journalisation et audit.
Une bonne journalisation aide les développeurs et les testeurs à remarquer un problème avant même que l'utilisateur final ne le devine, ainsi que les endroits qui nécessitent une optimisation. Un audit des actions et des changements nous permet de toujours trouver les raisons d'un comportement particulier sans aucun problème. Par exemple, si un élément d'une politique de crédit ne peut pas se prononcer sur un prêt, pour analyser pourquoi cela s'est produit, nous nous tournons d'abord vers les journaux. Cet élément s'applique aux environnements de production et de pré-production.
3. Système de surveillance et d'alerte
Comme je l'ai mentionné ci-dessus, la surveillance par certaines métriques est l'un des meilleurs moyens de contrôler que tout va bien avec notre application. De plus, en cas de problème, vous devez envoyer une alerte aux parties intéressées (par exemple, le nombre de demandes de prêt est de 20% inférieur à celui attendu - nous enverrons une alerte aux services informatiques et commerciaux, la charge CPU est supérieure à la normale - informez les administrateurs et les vierges). Il est nécessaire de s'assurer que les alertes sur les problèmes sont opportunes et pertinentes, ainsi que d'indiquer réellement le problème.
4. Contrôle de régression et de stabilité
Une bonne pratique consiste à passer périodiquement des tests de régression pour s'assurer que rien ne s'est mal passé. Cela peut aider dans certains cas étroits et spécifiques lorsque la surveillance ne voit pas de problèmes.
5. Rapports et statistiques
Comme dans tout test, les rapports et les statistiques sur les résultats des tests prod rendent le processus plus transparent, la qualité du logiciel et les causes des défauts plus visibles.
Toutes les erreurs ne peuvent pas être détectées sur la pré-prod, elles tomberont donc dans l'environnement de combat. Si les utilisateurs les trouvent, cela affectera la réputation de l'entreprise et, en fin de compte, la perte d'argent. Les tests sur la prod permettront d'éviter cela.