Bonjour chers lecteurs. Aujourd'hui, nous aimerions coïncider avec le lancement du cours "Python QA Engineer" . Anticipant d'éventuelles questions, nous avertissons qu'il n'y a pas un mot sur Python dans l'article, mais néanmoins nous trouvons ce matériel utile aux testeurs, nous avons donc décidé de le partager avec vous.
Il n'est pas possible de tester les moindres détails du code.Par conséquent, les tests de régression doivent effectuer une vérification complète et se concentrer sur un domaine spécifique dans son intégralité. L'objectif principal est de garantir qu'aucune erreur de régression ne nuise à un processus métier critique. C'est cet effort qui permet de bénéficier de l'automatisation. Une approche de test automatisée visant à réduire les erreurs de régression contribuera grandement à établir de bonnes relations avec les clients et à accroître la valeur de la marque.
Mon équipe est chargée de tester une application comptable qui utilise des calculs sophistiqués et enregistre les écritures comptables dans le système comptable. Tout cela est un flux de travail, et la fermeture de livres chaque mois est la plus importante.
Avec chaque version, il y a des changements dans les calculs, par exemple, pour le compte, il peut être nécessaire d'augmenter le débit ou le crédit, ou la valeur existante peut être divisée entre les deux comptes. De tels changements dans une application complexe qui a de nombreuses dépendances internes et externes conduisent souvent à un comportement imprévisible, y compris des erreurs de régression, dans des endroits inattendus et apparemment sans rapport.
Traitons une erreur de régression, elle est parfois appelée incident critique ou problème de production. Après avoir travaillé pendant plusieurs années dans l'industrie du logiciel, vous vous rendez compte que l'erreur de régression qui a fui en production est beaucoup plus importante que la nouvelle fonctionnalité qui fonctionne incorrectement. Le fait est que la nouvelle fonction est toujours cachée, donc lorsqu'elle tombe en panne, l'impact sur le composant métier est minime, tandis qu'avec une erreur de régression, l'utilisateur s'appuie sur la fonction de travail et n'a probablement pas de version de sauvegarde du système de travail.
Les erreurs de régression sont causées par des changements qui n'ont pas été pris en compte par le chef de projet ou le responsable produit lors des tests d'acceptation; architecte, développeur lors de la revue de code au stade de la conception ou de l'implémentation; ou par un analyste QA et un testeur dans des cas de test. Tous les réseaux de sécurité ont raté une erreur et l'utilisateur est tombé dessus. Si une erreur dans une mise à jour récente a été détectée à l'une des étapes ci-dessus, c'est-à-dire des équipes, des parties intéressées ou de tout autre lien présent dans votre organisation, puis il a été examiné avant la publication, ou du moins évalué en termes de criticité.
Les erreurs de régression entraînent plusieurs coûts: correction urgente, amendes pour violation potentielle du contrat de niveau de service et, surtout, elles nuisent à la confiance de vos utilisateurs dans votre produit. Ils peuvent décider qu'une nouvelle version cassera quelque chose qui fonctionne déjà.
Il est devenu important que mon équipe vérifie absolument tout.
Cependant, il est bien connu que cela n'est pas possible, ou du moins trop coûteux et prend du temps. Par conséquent, «tout tester» s'est concentré sur les deux choses suivantes: les processus métier critiques et la conviction que le comportement dans les principaux processus métier critiques sera le même que dans la dernière version, avant le changement. En général, nous voulions nous assurer que dans la dernière version, une erreur de régression n'apparaissait pas dans le processus métier critique.
Nous avons évalué nos approches typiques des tests automatisés pour vérifier les calculs et vérifier que toute la logique est décrite dans le code de test de l'automatisation. Cette approche a soulevé une question classique: "Qui teste le code du testeur?" Si le cas de test n'a pas réussi, il y avait la même chance que le problème était dans le code du testeur. En outre, à chaque modification de l'application, le code de test doit également être mis à jour et ces modifications se sont produites fréquemment.
De plus, grâce aux tests automatisés, nous nous sommes assurés d'avoir un ensemble fixe d'entrées et un ensemble bien connu de sorties. En raison de la complexité de l'application, il était impossible de soumettre tous les ensembles possibles de données d'entrée à la fois. Divers ensembles de données étaient également nécessaires pour la fin du mois, du trimestre et de l'année. Le calendrier était un problème sérieux, car il fallait beaucoup de temps pour générer un énorme ensemble de données d'entrée et de scripts correspondants.
Il y avait une autre variable: les données utilisateur. Nous avions un privilège spécial: nous recevions chaque mois des copies de sauvegarde des données des utilisateurs. La qualité du test dépend directement des données utilisées pour les tests, et les données de la production sont toujours meilleures que les données générées, donc notre privilège était un énorme avantage que nous ne voulions pas manquer.
Identification et mise en place de tests de régression
Notre idée était d'utiliser des tests automatisés, qui nécessitent le minimum de maintenance nécessaire, et qui renforcent la confiance des parties prenantes que la version sera de bonne qualité.
Nous avions donc besoin d'une stratégie de test pour les analyses de rentabilisation critiques, qui garantirait l'absence d'erreurs de régression et, bien sûr, que nous pourrions rapidement mettre en pratique.
Notre processus de préparation ressemblait à ceci:
- Sauvegarde de la base de données de production, restaurée deux fois;
- Deux systèmes de test sont installés et fonctionnent en parallèle:
- Un avec un code de production;
- Un autre avec la version actuelle de l'application en cours de test.
Cette approche fournit deux systèmes identiques avec des différences de code dans une seule version:
Il est très important d'avoir deux systèmes, car cela aide à comprendre que tout problème ne survient qu'en raison des dernières modifications de code.
Les tests sont séparés, donc du processus standard «effectuer une action et obtenir une réaction», nous procédons au fait que les actions sont effectuées d'un point à un autre tout en maintenant le workflow, après quoi les rapports d'erreur sont comparés. C'est la clé pour détecter les erreurs inattendues.
Lorsque le testeur se concentre sur une nouvelle fonction ou une sorte de changement, le test se concentre spécifiquement sur elle, c'est-à-dire la pertinence d'un changement particulier est vérifiée. Le test de régression est différent en ce qu'il doit vérifier que rien d'autre n'a changé. Cette différence se reflète dans les scénarios d'automatisation. Il rend les scripts de test de fonction spécifiques inappropriés pour rechercher des erreurs de régression, donc une approche différente est nécessaire ici.
Par exemple, si vous travaillez avec un système de gestion des commandes, vous aurez besoin d'un script pour passer des commandes avec beaucoup de données d'entrée pour passer des commandes pour deux systèmes de test installés (de préférence en parallèle), puis vous obtenez un rapport sur les commandes de la journée passée et comparez chaque valeur. Ensuite, toutes les commandes sont confirmées ou approuvées (cette action) et les rapports, tels que les commandes quotidiennes confirmées, les commandes de stock, les rapports d'entrepôt, les commandes de chaque transporteur, le type d'expédition, le type de paiement, etc. sera comparé dans deux systèmes. Cela se poursuit tout au long du flux de travail. Vous pouvez combiner des actions, telles que passer et confirmer des commandes, puis comparer des rapports à des étapes distinctes.
Un autre exemple est le système de gestion hôtelière, dans lequel les actions individuelles sont définies comme des processus commerciaux critiques, tels que l'enregistrement, la facturation dans un restaurant et la réception de l'inventaire. Tous ces processus se verront attribuer leurs propres actions et rapports. La différence dans ce système par rapport à l'exemple précédent est que les suites de tests peuvent s'exécuter en parallèle, et il n'est pas nécessaire de terminer l'étape avant de commencer la suivante.
Une comparaison des deux rapports est un moment de vérité et devrait être irréprochable, en ce sens qu'aucune des parties intéressées ne devrait avoir de doutes quant à son exactitude. La différence dans les rapports est la vraie différence.
Pour cette opération, nous utilisons l'interface de service Web. Tous les rapports sont envoyés en parallèle sur deux systèmes, par conséquent, la réponse reçue au format JSON est comparée.
La comparaison se déroule sur trois fronts:
- Source (production) moins cible (application en cours de test);
- Cible moins la source;
- Comparaison des valeurs pour obtenir l'intersection.
Cette méthode fonctionnera pour XML, XLS, CSV à largeur fixe ou tout autre format. Nous devons nous assurer qu'il n'y a pas d'enregistrements inutiles, qu'il n'y a pas d'enregistrements manquants et que toutes les valeurs des enregistrements correspondent.
C'est l'essence même de l'approche dont nous parlons. Tout cela est une information lisible dans l'application, qui est publiée sous forme de rapport ou, dans certains cas, fonctionne comme une interface avec d'autres applications.
Le succès de cette approche réside dans un outil de comparaison ou un utilitaire qui traite les cas liés à votre application. Vous pouvez vous considérer chanceux si vous trouvez quelque chose qui convient "hors de la boîte", sinon, il est important de comprendre que l'investissement dans un tel instrument en vaut la peine car il apportera de bons résultats.
Après toutes les discussions sur l'automatisation, vous devez insérer une remarque. Étant donné que certaines différences dans les rapports sont attendues, car elles doivent être présentes au besoin, tous les résultats doivent également être analysés manuellement. Il devrait y avoir des résultats clairs et positifs de réussite des cas de test, mais les résultats infructueux doivent également être analysés et leur validité doit être confirmée. Comme nous parlons d'erreurs de test de régression, elles doivent être corrigées avant la publication. Bien sûr, certaines exceptions sont gérées conformément à la demande.
Réglage du programme
Toutes les applications sont différentes, et leur installation et leur configuration se produisent également de différentes manières. Pour préparer la demande aux tests, certaines étapes supplémentaires peuvent être nécessaires, par conséquent, elles doivent être prises en compte au bon moment et au bon endroit pour exécuter les tests. Voici un ensemble d'étapes typiques:
«Confondre» les données de production en supprimant les identifiants de courrier électronique ou d'autres informations confidentielles, ou les remplacer par des données fictives;
Obtenez les données sous une forme appropriée pour exécuter le test;
Adaptez les paramètres de l'environnement QA, par exemple, en modifiant les relations d'intégration.
La seule chose à retenir est que les étapes ci-dessus doivent être effectuées pour les deux installations. N'oubliez pas qu'avant de démarrer la suite de tests, les paramètres doivent être identiques.
Souvent, des actions autres que la demande d'un rapport peuvent renvoyer un objet, par exemple, une action, telle que la création ou la modification d'une commande, peut renvoyer un nouvel objet de commande. Dans ce cas, vous devez comparer deux objets et ne pas attendre la comparaison des rapports. Cela peut aider à identifier l'erreur dans les premiers stades à la racine.
Il est également recommandé de diviser l'ensemble complet en ensembles plus petits, par exemple en regroupant les transactions et les rapports associés. Les ensembles peuvent être exécutés en parallèle pour économiser l'exécution. Cependant, pour une application avec un flux de travail typique, cela ne fonctionne que si vous pouvez diviser les cas verticalement et horizontalement, ou vice versa.
Les variations peuvent commencer avec des technologies - JSON, XML ou scalers (int / string / float), et s'étendre jusqu'à ce que l'application testée et la production réagissent avec différentes structures, mais restent conformes à l'architecture. Par exemple, la version de production peut utiliser l'ancien fichier JAR, qui fonctionne dans un format spécifique, et dans la nouvelle version, le fichier JAR a été mis à jour et maintenant le format de réponse a changé, de sorte que leur comparaison montrera des incohérences. Pour les comparer correctement, vous avez besoin d'un plug-in temporaire.
Il y aura probablement peu de telles situations. Dans de tels cas, il est parfois plus facile de modifier la conception ou de les considérer dans le contexte d'une solution de contournement.
Il existe plusieurs options pour gérer ces comparaisons:
Ignorez certains champs, tels que les identifiants et les dates;
Ignorer les différences numériques inférieures à 0,0001;
Ignorer la sensibilité à la casse;
La structure change en deux réponses.
Amélioration des tests de régression
Les tests de régression doivent être holistiques et se concentrer sur un domaine entier. Cet équilibre permettra de capitaliser sur l'automatisation. Une approche de test automatisée contribuera à réduire le nombre d'erreurs de régression et aidera à établir de bonnes relations avec la clientèle et à accroître la valeur de la marque.
Maintenant, dans un rythme de mouvement vers l'avant constant, notre équipe veut essayer d'abandonner les deux installations de système identiques que nous utilisons maintenant et de mettre en œuvre la même stratégie sur une installation. Nous voulons conserver les réponses des réalisations passées et les utiliser à des fins de comparaison. L'approche des tests peut toujours être améliorée. Souhaitez-nous bonne chance!
La traduction a été préparée spécialement pour les étudiants du cours "Python QA Engineer" .