👨🏽‍🤝‍👨🏼 💾 😉 Pourquoi et comment testons-nous la mise à jour 😧 👨🏽‍💻 #⃣

Dans cet article, j'expliquerai pourquoi il est si important de ne pas oublier de tester les mises à jour des produits et comment ce processus fonctionne dans notre entreprise. La stabilité des mises à jour dépend de la réputation du produit et de la confiance des utilisateurs dans vos innovations. D'après ma propre expérience, je peux dire que parfois avant de commencer une mise à jour, par exemple au téléphone, je préfère attendre au moins un jour et lire les commentaires (ils ne sont toujours pertinents que pour la dernière version). Si les commentaires sont abusifs, la probabilité que je décide de mettre à jour tend à zéro. La note de l'application en raison de commentaires négatifs baisse, et il n'est pas si facile de la restaurer, car il faut pouvoir intéresser l'utilisateur à l'installation d'une nouvelle mise à jour, ce qu'il craindra désormais.

De quoi les utilisateurs sont-ils généralement mécontents?

l'application ne fonctionne plus du tout après la mise à jour. Par exemple, il ne sait tout simplement pas quoi faire des données dans l'ancien format;
les bonus, les remises, les sauvegardes des utilisateurs (jeux, magasins, cafés) ont été perdus;
la nouvelle fonctionnalité pour laquelle la mise à jour est annoncée ne fonctionne pas;
une nouvelle fonctionnalité fonctionne, mais certaines des anciennes sont tombées;

Tous ces problèmes sont pertinents à la fois pour l'application mobile et pour le système DLP que nous testons à domicile. Plus loin sur ce que nous avons affaire.

Ce que nous publions et ce qui doit être mis à jour

Notre entreprise offre aux clients une solution de protection contre les fuites d'informations d'entreprise avec la possibilité de configurer séparément pour chaque organisation, en fonction de ses besoins. Les principaux éléments du système sont ses paramètres (selon quels critères les intrus seront-ils fouillés) et les événements (incidents enregistrés).

Le produit se compose de plusieurs parties, dans cet article, nous considérerons le serveur d'analyse et de stockage des incidents InfoWatch Traffic Monitor. Le produit fonctionne sur la famille Linux OS, possède sa propre base de données. Le responsable de la sécurité utilise la console Web pour travailler. Deux distributions Linux différentes et deux bases de données sont actuellement prises en charge. Le système peut être installé de plusieurs façons: tout-en-un, lorsque tous les composants sur une seule machine; et une installation distribuée lorsque des composants du système existent sur différentes machines physiques.

En plus de la fonctionnalité déclarée du système, nous devons garantir une mise à jour des versions majeures N-1 et N-2 à N, ainsi que la mise à jour de toutes les versions mineures - correctifs et correctifs de chaque version. Cela est dû au fait que nos clients ont souvent une infrastructure informatique assez compliquée, la mise à jour peut prendre du temps, il est donc important de limiter le nombre de mises à jour, de ne pas les effectuer trop souvent, en évitant les temps d'arrêt.

Toutes ces conditions donnent un ensemble suffisamment large de configurations de notre produit, pour chacune desquelles nous devons garantir une mise à jour réussie. On entend par là une mise à jour, à la suite de laquelle:

les données utilisateur ne sont pas perdues
les anciennes fonctionnalités ne sont pas cassées
de nouvelles fonctionnalités sont disponibles pour une utilisation

Dans ce cas, la priorité des exigences de la liste ci-dessus est en ordre décroissant d'importance. Par exemple, si vous transférez des priorités du plan de travail avec les systèmes DLP vers le plan des applications utilisateur mentionnées ci-dessus, la sauvegarde de l'utilisateur du jeu est probablement plus importante que la possibilité de démarrer un nouveau jeu. Et l'utilisateur des applications de commande de nourriture ne se soucie pas de la beauté du nouveau menu si le bouton "Envoyer la commande" ne fonctionne plus.

Considérez l'exemple avec notre tableau de mise à jour lorsque la version principale 3. est publiée. Pour la version 1.0.0, deux correctifs et trois correctifs ont été publiés, et pour la version 2.0.0, il y avait deux correctifs.

1.0.0	2.0.0	3.0.0
1.0.1	2.0.1
1.0.2	2.0.2
1.1.0
1.1.1
1.2.0

Au total, dans l'exemple, nous avons neuf versions, à partir desquelles nous devons mettre à niveau vers la nouvelle version 3.0.0. Il existe deux systèmes d'exploitation et deux bases de données pour chaque version de notre produit. Ceux. Au total, 27 configurations mises à jour sont publiées. Et si nous adoptons également différentes méthodes d'installation, ce nombre peut être multiplié par deux en toute sécurité, ce qui nous donne 54.

Chacune de nos versions contient un certain nombre de fonctionnalités sérieuses (en termes d'impact sur le produit). Les méthodes d'ajustement du système peuvent changer, les systèmes d'analyse sont affinés, les incidents sont complétés par de nouvelles données, la version des environnements, par exemple, la version du système d'exploitation ou de la base de données, etc.

Historiquement ...

Dans des temps immémoriaux, nous avons développé une approche de recherche lors du test des mises à jour de produits. Il a fait ses preuves dans les conditions d'une bonne connaissance du produit et d'un petit nombre d'environnements et de configurations testées. Mais le temps a passé, l'équipe s'est agrandie et a changé sa composition: les testeurs et les développeurs allaient et venaient, et certaines fonctionnalités non documentées étaient sûrement oubliées.

Planifier des tests de recherche sans une bonne connaissance des produits est une tâche ingrate, elle a été lourde de conséquences comme:

Tester les mises à jour à chaque fois a pris un temps différent. Plus souvent, le temps a été alloué selon le principe résiduel, puisque la mise à jour a été testée lorsque le produit est déjà stabilisé et que la touche finale reste avant la sortie.
Parfois, certains environnements étaient oubliés.
, , . , , , «» - .

La préparation préliminaire a également été effectuée principalement à la discrétion du testeur, qui a obtenu la tâche et parfois sans prendre en compte tous les changements dans la version.

En plus des caractéristiques internes du processus de test, le fait que la documentation ne décrit pas les changements survenus avec la fonctionnalité du produit a ajouté du carburant au feu. Ainsi, nous avons pu tester non pas ce qui changeait, mais ce qui n'était pas du tout affecté par la version actuelle.

En conséquence, il était impossible de comprendre clairement à partir du rapport de test de mise à jour quelles vérifications ont été effectuées, à quelles valeurs, etc.

Néanmoins, pendant un certain temps, nous avons été satisfaits des résultats des tests de recherche: il n'y avait pas tant de défauts militaires pour la mise à jour, et il n'y avait pas de ressources pour les changements pour l'avantage théorique.

Quelque chose a mal tourné

La situation a changé lorsque des défauts de mise à jour critiques pour nos clients se sont néanmoins glissés. Le plus souvent, ils ont été trouvés quelque part loin des principaux scénarios de mise à jour et étaient associés à des situations où, par exemple, un élément de technologie d'analyse créé et fonctionnant dans la version précédente a bloqué la mise à jour, ou certains événements ont été perdus dans la base de données client, ou le scénario le plus critique lorsque, après la mise à niveau, certains services n'ont pas démarré et nous avons reçu un produit inopérant. Des défauts liés à la base ont également commencé à apparaître chez nos clients.

Dans cette situation, le processus actuel ne nous satisfait plus. Il fallait changer quelque chose.
Nous avons commencé par formuler des problèmes qui, à notre avis, nous ont empêchés de mieux tester la mise à jour. Après la discussion, la liste de problèmes suivante a été établie:

;
, ;
, , , , ;
, ;
;
. ? ? ? ?

De plus, pour chaque problème identifié, nous avons essayé de trouver une solution valable. En plus de résoudre des problèmes spécifiques que nous avons formulés pour nous-mêmes, nous avons décidé au cours des discussions de proposer des exigences pour le processus de test lui-même, sur lequel nous aimerions travailler davantage.

Le processus devrait être rendu plus ouvert et transparent, pour cela nous abandonnons complètement les tests de recherche au profit des cas de test.

Pour créer les cas de test nécessaires, nous avons besoin d'informations sur les changements entre les versions. Ces informations doivent être demandées aux développeurs de produits et aux analystes.

Dans la nouvelle approche, nous utilisons une combinaison de contrôles sur les objets système (inchangés et changeants lors de la mise à jour) + contrôles de fumée des fonctionnalités (anciennes et nouvelles ou anciennes modifiées).

Pour la mise à niveau, l'option d'installation du système la plus difficile sera sélectionnée: l'installation distribuée. Pour tous les OS et DB. Les options les plus simples sont omises en tant que cas spéciaux.

Cette combinaison de contrôles nous permettra de tester les composants système suivants:

DB
Web (frontend, backend);
Composants Linux

En conséquence, la solution pour chacun de nos problèmes a été présentée comme suit:
Il n'y a pas suffisamment d'informations sur les changements dans la version actuelle. Connaissance insuffisante du système, informations insuffisantes sur le système. En collaboration avec des analystes et des développeurs, nous déterminons les domaines changeants du produit entre les versions mises à jour et actuelles.

Le test des mises à jour se transforme en régression. Les tests fonctionnels sont effectués, pas les objets système et les opérations sur eux. Nous testerons la mise à jour sur les cas de test sous forme de tests de fumée de la vérification fonctionnelle + des données.

Rapports incompréhensibles. La couverture et les résultats peuvent être tirés des cas de test.

Le processus est opaque. Après avoir résolu chaque problème individuel, un nouveau processus a été formé qui était justifié par nos besoins et également fixé de telle sorte que chaque membre de l'équipe puisse maintenant se familiariser avec ses principes.

Nouveau processus

En conséquence, nous avons construit un processus plutôt efficace.

Nous avons divisé les tests en plusieurs étapes, ce qui a donné encore plus de bonus imprévus, décrits ci-dessous:

Entraînement.
- Nous analysons les changements dans le système, préparés conjointement avec des analystes et des développeurs pour des domaines en évolution.
- Conformément aux résultats de l'analyse, nous compilons une liste d'objets système préparés pour tester les mises à jour.
- Pour chaque objet système, l'ensemble nécessaire d'états, d'états et de paramètres est déterminé.
- Nous créons des stands avec la version nécessaire (mise à jour) du produit.
- , .
- ( ).
- smoke- , .
:
- ;
- (, , , );
- , .
- .
- -, .
- .
- , .
- Contrôle des opérations sur les objets (création, édition, suppression).
- Vérification de l'interaction des objets avec d'autres objets (détection).

Avantages et inconvénients de l'approche

Nous avons atteint notre objectif, à savoir:

Le processus est devenu transparent. Nous savons que nous testons comment, combien de temps cela prendra et quels artefacts seront générés. Nous avons reçu des critères objectifs permettant de rendre notre verdict sur une mise à jour de produit fonctionnelle ou non fonctionnelle.
Les rapports sont devenus clairs. La présence de cas de tests et un rapport sur les résultats de leur passage ont permis de rapporter rapidement au chef de projet et au directeur technique la qualité de l'ensemble créé.
Couverture plus large et plus compréhensible qu'avec une approche de recherche.
Nous testons maintenant une modification des données et des fonctionnalités. Grâce à la réactivité des analystes et des développeurs, nous pouvons dire avec une grande précision ce qui a changé dans le système et où il y a un risque d'attraper un défaut.

Mais en exécutant une nouvelle stratégie de test, nous ne pouvions pas manquer de rencontrer les inconvénients évidents de la nouvelle approche - une augmentation significative du temps de test.

Nous avons commencé à consacrer du temps non seulement aux tests directs, comme ce fut le cas pour les tests de recherche. Les nouveaux coûts de temps étaient principalement associés à la préparation des tests, à savoir:

analyse du changement;
création, remplissage, maintenance de stands de mise à jour;
mise à jour d'anciens kits de test et création de nouveaux.

Ce moins pourrait bien devenir décisif pour décider d'abandonner la nouvelle méthodologie, si ce n'est pour un «mais».

Toute préparation, et c'est l'étape la plus longue, pourrait être effectuée dès que la composition finale de la libération a été formée, même sans produit fini. Ainsi, nous «répartissons» la préparation selon le plan de test, sans surcharger la période de pré-libération trop saturée. Il ne lui restait plus qu'à passer les tests sur le produit stabilisé fini.

Au total, selon les résultats de la première étape des améliorations, nous avons reçu ce qui suit: nous avons commencé à passer plus de temps à tester, mais en même temps nous avons un processus transparent, un affichage clair des résultats et plus de couverture, ce qui nous permet de:

détecter plus de défauts suite à la vérification des mises à jour des produits dans votre service;
réduire le nombre de défauts lors de la mise à jour de nos clients par les ingénieurs d'implémentation;
réduire le nombre de défauts reçus du support technique.

Et après? - sur l'optimisation

Cela aurait pu être réglé à ce sujet, mais le temps, c'est toujours de l'argent. De plus, déjà d'après les résultats du premier rodage de la nouvelle méthodologie, les moyens d'optimiser les coûts de temps sont devenus plus clairement visibles.

Nous y sommes allés de deux manières:

optimisation basée sur l'analyse des séries de tests: nous avons ici cherché à identifier les dépendances évidentes et implicites des résultats des tests sur les environnements utilisés. C'est ainsi que les tests fonctionnels se sont déroulés.
automatisation des tests. Ensuite, notre équipe d'automatisation est venue à la rescousse.

Je vais parler un peu plus de chaque chemin.

Première voie: optimisation basée sur l'analyse des cycles de test.

Nous avons ainsi choisi d'optimiser les tests de mise à jour entre les versions majeures entre ceux où il y avait un changement significatif de fonctionnalité.

La première chose que nous avons remarquée était les tests qui dépendent de la base de données et uniquement de la base de données. Nous avons pu comprendre quels contrôles suffisent à effectuer une fois sur chaque base, puis les exclure complètement de notre combinatoire avec l'OS.

La deuxième étape a été l '«effondrement» des contrôles volumétriques de l'ancienne fonctionnalité dans une liste de contrôle. Dans les premières itérations, la fonctionnalité, qu'elle apparaisse dans la version actuelle, dans la précédente ou qu'elle ait toujours été, reposait sur son propre test à part entière. Désormais, les tests à part entière ne reposent que sur de nouvelles fonctionnalités, tandis que les anciennes fonctionnalités sont vérifiées dans la liste de contrôle.

De plus, la même liste de contrôle nous a été très utile lors de la publication de correctifs et de correctifs, où en plus des mises à jour entre les versions principales, il est également important de vérifier les mises à jour dans la version.

La deuxième façon: l'automatisation des tests

Tout d'abord, je veux faire une réserve que nous n'avons pas conçu la mise à jour de l'automatisation des tests parce qu'elle était généralement acceptée et généralement de bonne tonalité, mais parce que la mise à jour est le type de test qui ne pouvait être exclu dans aucune version, qu'elle soit majeure version, correctif ou correctif. Nous avons choisi ce chemin pour réduire le temps de test des mises à jour pour les versions mineures, à savoir les correctifs et les correctifs, c'est-à-dire versions entre lesquelles la composition du fonctionnel ne change pas. Dans ce cas, l'automatisation des tests semblait très efficace.

À ce stade, le test des mises à jour lors de la publication des correctifs et des correctifs est presque entièrement automatisé.

Le test des mises à jour lorsque les versions principales sont publiées est divisé entre les tests manuels et automatisés. Vérifie manuellement les zones modifiables affectées par les fonctionnalités. Les tests pour les zones invariables sont automatiquement poursuivis, le plus souvent il s'agit d'une réutilisation plus fréquente d'autotests déjà écrits pour les versions précédentes avec peu de mise à jour pour une nouvelle.

Afin de lancer le processus d'automatisation des cas de test, nous avons dû les affiner davantage, car le langage des tests d'un testeur manuel permet bien plus de difficultés qu'un autotest ne peut se permettre. Autrement dit, nous avons également alloué du temps pour la préparation des tests d'automatisation, ce qui a vraiment porté ses fruits presque la toute première exécution.

Sommaire

Nous avions un processus de recherche pour tester les mises à jour. À un moment donné, il a cessé de nous satisfaire en raison d'une baisse notable de la qualité de la mise à jour. Nous n'avons pas choisi un remplaçant pour les tests de recherche comme technique toute faite, mais nous l'avons formé en fonction des problèmes que nous avons identifiés. La formation d'une nouvelle méthodologie, que nous utilisons et continuons d'améliorer, a été influencée par les solutions préparées aux problèmes, ainsi que par les souhaits généraux pour le processus de test.

Je ne pense pas que dans cette situation, nous avons inventé un vélo lorsque nous avons choisi de créer notre propre processus spécialement conçu pour notre projet et les caractéristiques de notre produit. Si nous démontons le procédé en ses parties constituantes, nous obtenons, en général, des techniques généralement acceptées et largement utilisées.

Malgré le fait que les résultats des travaux que nous avons rassemblés dans un article pas trop volumineux, le processus complet de la compréhension du problème à l'introduction de nouvelles solutions et à l'optimisation des tests nous a pris près de deux ans.

Nous avons essayé de décrire ici honnêtement tous les avantages et les inconvénients, ainsi que les pièges de nos décisions, afin que l'histoire ne ressemble pas exclusivement à une réussite «c'était mauvais - c'est devenu bon».

Nous espérons que notre expérience vous sera utile.

Auteur du matériel:tryzhova (Ryzhova Tatyana).

Pourquoi et comment testons-nous la mise à jour