Get best of the week

Ce que nous avons appris en testant le système d'information de l'État

Bonjour à tous! 

Je dirige le secteur des tests dans le département d'analyse et de test des systèmes du département des systèmes d'entreprise LANIT. Je travaille dans ce domaine depuis 14 ans. En 2009, pour la première fois, j'ai dû tester le système d'information de l'État. Et pour LANIT, et pour le client - c'était un projet énorme et significatif. Il est commercialisé depuis plus de neuf ans.

La source

Ce texte vous présentera l'approche de test des SIG, qui est utilisée dans notre entreprise. En particulier, vous découvrirez (le lien vous mène au fragment de l'article auquel il est fait référence dans un paragraphe spécifique):


Avant LANIT, je travaillais dans un groupe de test de cinq personnes, où les tâches étaient confiées au chef d'équipe. Lorsque je suis arrivée chez LANIT, j'ai été chargée de gérer une équipe de test géographiquement répartie de quatre testeurs, qui ont été impliqués au début du projet pour tester le système d'information de l'État. Au fur et à mesure du développement du projet, le nombre de testeurs dans le groupe a augmenté proportionnellement à l'augmentation des fonctionnalités.

Chapitre 1. Début du premier projet de test SIG


Lorsque nous avons commencé à travailler avec les SIG, tout d'abord, nous avons dû faire face à de gros volumes de fonctionnalités (plusieurs dizaines de sous-systèmes, chacun avec jusqu'à des centaines de fonctions) qui devaient être testés en peu de temps. L'équipe avait pour tâche de ne pas se confondre dans l'étendue des fonctions et de minimiser les risques de défauts manqués.

La documentation normative, sur la base de laquelle les spécifications techniques ont été élaborées, était en constante évolution, et toute l'équipe a dû s'adapter aux innovations: nous avons révisé les spécifications techniques pour le développement et les priorités du projet (en conséquence, le plan de test a changé). 

Il était difficile pour les analystes de s'adapter au changement fréquent de la documentation réglementaire, ce qui a conduit à un manque de compréhension sur la façon de maintenir les spécifications techniques à jour, comment avoir toujours un ensemble de spécifications pertinentes pour chaque version du système, comment et où afficher le degré d'influence d'un changement d'une spécification sur de nombreux autres documents connexes . 

Étant donné que le résultat du travail des analystes a été utilisé par les développeurs et les testeurs, les questions sur la pertinence des spécifications techniques, la compréhensibilité de l'historique des spécifications, la conformité de l'ensemble des spécifications techniques de la prochaine version, étaient aiguës pour tous les participants de l'équipe de projet. Les conséquences de la confusion avec la documentation, la version des spécifications techniques ont affecté le coût du projet.

Parfois, la situation tournait à 180 degrés. D'accord, quand un train se précipite à grande vitesse, il est impossible de changer brusquement de direction sans conséquences.

J'ai assisté régulièrement à des réunions et compris la raison des changements dans le projet. La partie la plus difficile est d'expliquer aux testeurs à distance pourquoi nous avons testé le nouveau registre pendant un mois, et maintenant nous devons tout oublier et nous préparer à tester la fonctionnalité complètement repensée de ce registre. Les gens ont commencé à se sentir comme des rouages ​​dans une machine géante, et leur travail était considéré comme complètement inutile.

Au début, de tels changements ont ennuyé l'équipe et fortement démotivé. Mais l'équipe a accepté le fait qu'il est impossible d'influencer le changement des spécifications techniques, mais vous pouvez apprendre à travailler avec. Dans cette période difficile pour le projet, l'équipe de test avait une nouvelle tâche, qui était généralement absente sur les petits projets - les exigences de test. 

En conséquence, les inconvénients de la modification des exigences se sont transformés en avantages pour les testeurs sous la forme d'une nouvelle tâche de test et de la capacité d'influencer le résultat final du projet. 

En plus d'interagir avec les analystes, l'équipe de test s'est avérée dépendante des communications avec les systèmes externes avec lesquels ils doivent s'intégrer. Tous n'étaient pas prêts à fournir leur circuit de test et à informer les systèmes tiers de leurs dates de sortie et à échanger des informations sur les changements de services. Une telle désynchronisation des communications ou une attitude imprudente vis-à-vis de la notification de la composition des modifications des services Web par des systèmes externes a conduit à des erreurs de produit et à des difficultés dans la conduite des tests d'intégration. Les testeurs ont dû établir des communications avec des systèmes externes, développer la compétence de tester l'intégration et attirer des développeurs pour implémenter des stubs.

Toute l'équipe de test participant au projet a été confrontée à la nécessité d'immerger l'équipe de développement dans le processus de production. Au début du projet, l'équipe de développement a commencé à rechercher de nouvelles approches pour l'organisation du travail, a présenté les modèles de branchement Feature Branch Workflow et le modèle Gitflow. Le développement de petits projets se faisait auparavant sans un tas de branches, tout le monde était à l'aise. Mais face au problème de l'incapacité à stabiliser la version pendant quelques mois pour la prochaine démonstration de la phase intermédiaire du projet au client, après avoir analysé les raisons, le responsable du développement et l'architecte sont arrivés à la conclusion que le processus de création de logiciels devait être modifié. Ensuite, ils ont commencé à utiliser activement le workflow de branche de fonctionnalité et Gitflow sur le projet. Une autre nouvelle tâche de test est apparue: étudier les principes de fonctionnement des modèles de développement afin de s'adapter au processus de création de logiciels.

Le SIG consiste à diviser un projet en blocs fonctionnels, dont chacun comprend un ensemble de composants qui sont étroitement liés les uns aux autres par l'entreprise et / ou remplissent une fonction technique indépendante. Si au début du projet, tous les testeurs vérifiaient les blocs fonctionnels nouvellement arrivés et que tous les membres de l'équipe étaient interchangeables, avaient un niveau de connaissance égal de tous les blocs, alors que le projet se développait, le nombre de testeurs devait également être augmenté et divisé en groupes. La croissance de l'équipe a conduit au processus de séparation en groupes de test, à la répartition des rôles de projet au sein de chaque groupe.

À mesure que le projet se développait, les caractéristiques des systèmes d'information de l'État ont commencé à apparaître. 

Chapitre 2. Caractéristiques du SIG. Comment les testeurs vivent et travaillent avec eux


Tout d'abord, les grands SIG sont soumis à des exigences accrues de fiabilité et de charge, de fonctionnement du système - 24h / 24 et 7j / 7, les dysfonctionnements du système ne devraient pas entraîner de perte de données, le temps de récupération du système - pas plus d'une heure, le temps de réponse - pas plus de 2 secondes et beaucoup plus. 

Puisqu'il s'agissait d'un portail Web, les testeurs ont dû se plonger dans le processus de test des portails Web multi-utilisateurs et construire une approche de la conception des tests et du processus de test, en tenant compte des particularités de l'interface Web.

Une application Web peut être utilisée par un grand nombre d'utilisateurs en même temps. Il était nécessaire de fournir des tests de charge de la partie ouverte du SIG utilisée par tous les utilisateurs, de prévoir le modèle de charge et d'effectuer des tests de charge.

L'utilisateur peut avoir ses propres niveaux d'accès. Il était nécessaire de tester la matrice des rôles d'utilisateur dans le sous-système d'administration d'application à l'aide de techniques de conception de test.

Les utilisateurs peuvent accéder à une seule entité, ce qui conduit à un accès compétitif. Afin que les données d'entrée d'un utilisateur n'écrasent pas les données d'un autre, nous avons dû effectuer une analyse de test des situations dans lesquelles il est possible de modifier simultanément les données dans les tableaux de bord personnels des utilisateurs, pour inclure dans les tests les contrôles de tests corrects avec des messages de diagnostic.

L'une des caractéristiques du système était l'utilisation du moteur de recherche SphinxSearch.avec laquelle l'équipe de test ne savait pas comment travailler. Pour comprendre les subtilités des tests, Sphinx a dû consulter les développeurs et comprendre comment l'indexation des données se produit.

Les testeurs ont maîtrisé les caractéristiques des tests de recherche par formes de mots, fragments de mots, synonymes, en cherchant dans les documents joints, ils ont commencé à comprendre pourquoi les données de recherche nouvellement créées n'apparaissaient pas dans le résultat de la recherche et s'il s'agissait d'une erreur. 

Le projet comportait un sous-système d'administration appliquée, qui comprenait non seulement l'enregistrement des utilisateurs, mais était compliqué par la présence d'une matrice de rôles d'utilisateurs. Il a été configuré dans les comptes personnels des administrateurs d'organisations. Le nombre de combinaisons de contrôles de la matrice des rôles était énorme et le nombre de types d'organisations n'était pas non plus faible, c'est-à-dire que le nombre de combinaisons de contrôles a augmenté de façon exponentielle. Il était nécessaire de changer l'approche familière de la conception des tests utilisés précédemment sur les petits projets. 

Étant donné que le système supposait une interface Web, il était nécessaire de fournir des tests inter-navigateurs, ce qui n'était pas prévu à l'origine. Au début du projet, Internet Explorer 7.0 était le seul navigateur prenant en charge la cryptographie domestique et la majorité des utilisateurs utilisaient ce navigateur. Par conséquent, au début du projet, pour tester la logique et la fonctionnalité du travail des comptes personnels, seul IE de cette version a été utilisé, mais pour la partie ouverte du portail, un support était requis pour tous les navigateurs existants à cette époque. Cependant, à ce moment-là, ils ne pensaient pas aux tests inter-navigateurs.

Quand ils m'ont demandé: "Comment se comporte le système dans toutes les versions connues des navigateurs?" - J'étais dans une panique, pour le dire légèrement, car le volume du modèle de test était énorme (environ 4000 cas de test), le jeu de tests de régression était d'environ 1500 cas de test, et l'équipe de test a vérifié la foule entière exclusivement sur un navigateur sélectionné par défaut. Ce cas devait être résolu très rapidement et utilisé avec ingéniosité afin de rattraper les délais de la première version et de couvrir les principales versions du navigateur avec des tests.

Sur Internet, il y avait alors peu d'articles sur les tests, le développement de modèles de tests. Pour notre équipe, à l'époque, une tâche incompréhensible était de savoir comment créer, où stocker et comment maintenir à jour un grand modèle de test. Il n'était pas clair comment s'éloigner des tests de recherche, qui pouvaient devenir infinis, et il n'y avait pas de ressources pour le test sans fin: ni humain ni temporaire.

Après la mise à l'essai du SIG, puis dans le secteur industriel, une nouvelle tâche est apparue: gérer les incidents des utilisateurs. 

Avant la création d'un service d'assistance utilisateur SIG à part entière, l'équipe de test a répondu au premier appel de demandes d'utilisateurs, car elle était la plus plongée dans les détails du système, essayant de combiner les principales tâches de test de nouvelles améliorations, ainsi que de traiter en temps opportun les incidents entrants qui ont été superposés par le SLA.

L'équipe de test n'a jamais rencontré une telle tâche auparavant. Le flux d'incidents devait être traité, systématisé, localisé, corrigé, vérifié et incorporé dans le nouveau cycle de publication. 

Le niveau de compréhension et de maturité du processus d'exploitation a augmenté et s'est amélioré au fur et à mesure que le système se développait. 

Je n'ai répertorié qu'une partie des fonctionnalités rencontrées par l'équipe de test lors de l'utilisation du SIG.

Chapitre 3. Problèmes de test des SIG et méthodes pour les résoudre. Recommandations pour tester les managers d'équipes.


Au cours du travail de l'équipe de test sur plusieurs grands SIG, nous avons formulé des recommandations pour les responsables de test. Plus tard, ils ont été transformés en méthodologie du processus de test de tels systèmes dans notre département et continuent de s'améliorer lors de la résolution de nouveaux problèmes dans des projets d'une échelle similaire.

Que faire quand beaucoup de fonctionnalités?


Ne paniquez pas et ne divisez pas le fonctionnel en blocs / modules / fonctions, connectez l'analyste à l'audit du résultat, assurez-vous que la vision des blocs fonctionnels est correcte. 

Nous recommandons de faire:

  1. .

    , , , , production. , .
  2. //.

    , , — ,   ///. , , , - , , , / // , , « » , .

Que faire des matrices de connaissances et de la couverture des exigences fonctionnelles?


La fonctionnalité ne diminue pas. Maintenant, il y en a encore beaucoup, mais c'est dans une nouvelle représentation (sous la forme d'une matrice). Il est nécessaire de déterminer quelles fonctions sont les plus importantes d'un point de vue commercial et ce qui ne peut pas être fourni aux utilisateurs sous une forme brute. Commence alors la hiérarchisation des fonctionnalités. Idéalement, si l'analyste aide le testeur à cela. Au minimum, il appréciera l'exactitude des priorités placées par les tests.

Les fonctions / blocs / modules les plus importants se verront attribuer une priorité élevée pour le test, les moins importants seront couverts par les tests de deuxième priorité, les autres seront les troisièmes, ou si les «délais sont respectés», vous pouvez reporter leur test pour un temps plus calme. 

Ainsi, nous avons la possibilité de tester la fonctionnalité qui est vraiment importante pour le client. Nous mettons les choses en ordre dans un grand nombre de fonctions, nous comprenons ce qui est couvert par les tests, et ce qui reste à couvrir, nous savons qu'à l'intérieur, il est nécessaire de renforcer les tests, en cas de maladie / licenciement des testeurs responsables, nous comprenons à quels testeurs les équipes doivent passer des améliorations au test (dans correspondance avec la matrice de connaissances), quelles nouvelles fonctions / modules / sous-systèmes intéressants puis-je proposer au conditionnel Vasya, Pete, Lisa, quand ils sont fatigués de tester la même chose. C'est-à-dire que j'ai un outil visuel pour motiver les testeurs qui veulent apprendre quelque chose de nouveau sur le projet.

Que faire lorsque les exigences ne prennent pas en charge l'historicité, sont confuses, dupliquées, comment les testeurs fonctionnent-ils avec cela?


Nous vous recommandons d'implémenter le processus de test des exigences sur le projet. Plus un défaut est découvert tôt, plus son coût est faible.

Les testeurs distribués par la matrice de connaissances, dès la préparation des spécifications techniques pour le développement, commencent immédiatement à les étudier et à les vérifier. Afin de faire comprendre à tout le monde quelles sont les erreurs dans les exigences, un ensemble de règles pour les analystes «Recette pour les exigences de qualité» a été développé, selon lequel ils ont essayé d'écrire des exigences, et des modèles de spécifications techniques ont été créés pour les décrire dans un style unique. Des règles pour le format des spécifications techniques et des recommandations pour la description des exigences ont été émises aux testeurs pour comprendre quelles erreurs rechercher dans les exigences.

Bien sûr, la tâche principale du testeur était de trouver des incohérences logiques ou des moments d'influence non comptabilisés sur les fonctions / sous-systèmes / modules connexes que l'analyste pourrait manquer. Après avoir détecté des défauts, ils ont été corrigés dans le bugtracker, attribué à l'auteur de l'exigence, l'analyste a arrêté le développement et / ou bavarder avec le testeur et le développeur a informé que la condition serait modifiée en fonction du défaut (afin de ne pas ralentir le développement), apporter des corrections et publier la version corrigée exigences. Le testeur a vérifié et fermé le travail sur le défaut aux exigences. Cette procédure a donné à l'équipe l'assurance qu'après quelques semaines de développement, le problème détecté ne se poserait certainement pas lors du test.

En plus de la détection précoce des défauts, nous avons reçu un puissant outil de collecte de métriques sur la qualité du travail des analystes. Disposant de statistiques sur le nombre d'erreurs dans les exigences, l'analyste principal du projet pourrait prendre des mesures pour améliorer la qualité du travail dans son groupe. 

Que faire lorsqu'il est nécessaire d'effectuer des tests de charge?


Il est nécessaire d'étudier les exigences de la charge, d'élaborer son modèle, de développer des cas de test, de coordonner le modèle de test de la charge avec l'analyste et de développer des scripts de charge avec la participation de spécialistes compétents dans les tests de charge. 

Bien sûr, vous ne pouvez pas deviner la charge avec le modèle de test, mais pour un résultat plus précis, en plus de l'analyste, vous pouvez attirer un architecte ou un spécialiste DevOps qui, après avoir analysé les informations, les statistiques, les métriques, peut dire quels autres cas sont nécessaires dans le modèle de charge proposé.

Il est également utile de mettre en œuvre le processus d'exécution des tests de charge, de prendre les résultats de la charge et de les transmettre aux développeurs pour éliminer les goulots d'étranglement.

Le processus de chargement doit être effectué régulièrement avant la sortie de chaque version, changer périodiquement le modèle de charge afin d'identifier de nouveaux goulots d'étranglement.

Que faire lorsqu'il est nécessaire de réaliser des tests d'intégration dans lesquels il n'y a pas d'expérience?


Il existe des moyens de base: par exemple, vous pouvez suivre des formations avancées sur le thème des tests de l'API Rest, lire des articles sur Internet, obtenir un échange d'expérience avec des collègues via Skype, avec une démonstration du processus, embaucher un spécialiste qui connaît bien les tests de l'API Rest au groupe de test. 

Il existe de nombreuses façons de vous immerger dans ce type de test. Un spécialiste expérimenté a été embauché dans mon équipe, qui à l'avenir m'a formé ainsi que toute l'équipe de test, développé des manuels: que rechercher lors du test de l'API Rest, comment élaborer une conception de test pour vérifier l'intégration, organisé des webinaires avec une démonstration du processus de test pour toute l'équipe. 

Nous avons proposé des tâches de test sur lesquelles chacun a eu l'occasion de s'exercer et de s'immerger dans ce processus. Maintenant, le matériel qui a déjà été développé au fil des ans ne fait que s'améliorer, et le processus d'apprentissage et de plongée dans les tests de l'API Rest prend 1-2 semaines, tandis qu'auparavant il fallait un mois ou plus pour plonger, selon la complexité du projet et le volume du modèle de test. 

La source

Comment ne pas se perdre dans les branches de code, les stands, les déploiements et tester le code nécessaire?


Alors que le SIG est au stade initial de développement, il n'y a que deux branches de code: master et release. Le second est séparé à l'étape de stabilisation pour effectuer des tests de régression finale et corriger les défauts ponctuels de la régression.

Lorsque la branche de publication a été envoyée en production et que la prochaine itération de développement a commencé, nous avons décidé à un moment donné de paralléliser le développement de nouvelles tâches afin que la tâche plus importante prévue dans la version puisse être terminée à temps. À un moment donné, il y avait 3 ou 4 branches de ce type ou plus. Il y a plus de trois bancs d'essai déployés dans le but de commencer à tester les tests des futures versions dès que possible.

Les testeurs sont sûrs que le spécialiste de l'infrastructure a installé, par exemple, la révision n ° 10001 sur l'un des bancs d'essai, a tout exécuté correctement et ils peuvent démarrer le test. Le spécialiste de l'infrastructure a effectué le déploiement à partir de la branche du code, a indiqué que le stand était déployé, que le code avait été installé et qu'il pouvait être testé.

Nous commençons le test et comprenons que:

  • il y a des erreurs qui ont déjà été corrigées;
  • la fonctionnalité du bloc existant diffère considérablement de la fonctionnalité similaire qui se trouve sur un autre banc de test et se prépare pour la prochaine version prévue, alors qu'il ne devrait y avoir aucune modification dans la branche de code transférée;
  • nous commençons à enregistrer les défauts, les développeurs les renvoient, l'holivar commence dans les chats du projet et détermine ce que nous avons réellement installé et pourquoi pas ce que nous attendions.

Nous avons effectué une analyse et découvert que les développeurs n'avaient pas donné au spécialiste de l'infrastructure des instructions sur la branche à partir de laquelle déployer, l'employé collecté dans la branche de développement et le développeur avait réussi à fusionner uniquement une partie du code de la branche de fonctionnalité dans la branche de développement. 

Le testeur, qui ne comprenait pas du tout la gestion de la branche, a obtenu la tâche et un lien vers le stand, a couru pour tester, a passé du temps, a eu beaucoup de défauts, la plupart d'entre eux n'étaient pas pertinents en raison de toute cette confusion.

Ce que nous avons fait pour éviter des situations similaires à l'avenir:

  • le développeur prépare des instructions pour le spécialiste de l'infrastructure indiquant où déployer le déploiement, l'instruction est transmise à jira par le biais de la tâche;
  • le spécialiste des infrastructures n'est pas confus et fait ce qu'on lui a donné;
  • GIT, , jira ;
  • jira : 

  • Gitflow , , hotfixes develop,  .


, ,   ?


Nous vous recommandons d'élaborer une stratégie de test à l'avance, mais comme vous avez manqué ce point, mon expérience sera probablement utile.

Tout d'abord, vous devez comprendre quels navigateurs sont spécifiés dans les exigences. Si vous avez décidé, mais il n'y a absolument rien de temps, nous regardons les statistiques des navigateurs les plus couramment utilisés, par exemple, ici . Ensuite, nous essayons d'atteindre trois ou cinq des navigateurs les plus populaires.

Étant donné que le projet est important et que l'équipe de test était grande, il était physiquement possible d'attribuer un navigateur populaire en fonction des statistiques à chaque testeur. Il effectue ses cas de régression sur une version dédiée du navigateur, une attention particulière doit être portée à la mise en page, la cliquabilité des boutons et des liens. Ce processus ressemble à ceci: par exemple, il y a 100 scripts pour un test de régression, l'équipe a 5 testeurs, chacun peut utiliser 20 scripts pour fonctionner, chacun est affecté à un navigateur. Pour une régression, chaque testeur a vérifié ses cas dans l'un des navigateurs. La couverture n'est finalement pas complète, mais comme de nombreux scénarios se répètent encore à un degré ou à un autre, le pourcentage de couverture a augmenté en raison du passage d'une partie des scripts de régression par différents navigateurs. 

Bien sûr, cela n'a pas donné une couverture de test à 100% de toutes les fonctionnalités, mais cela a permis de réduire considérablement les risques de défauts inter-navigateurs entrant en production selon les principaux scénarios commerciaux du système.

De plus, non seulement sur la régression, mais aussi sur le test des améliorations et la validation des défauts, nous avons effectué des vérifications sur différents navigateurs, élargissant la couverture de la compatibilité entre navigateurs.

À l'avenir, ils ont commencé à appliquer l'approche en distribuant les testeurs par les navigateurs sur le test de raffinement, sans attendre l'étape de test de régression, augmentant ainsi encore le pourcentage de tests couvrant différentes versions de navigateurs.

Ce que nous avons obtenu:

  • coûts de test optimisés, à la fois financiers et temporels, pour un intervalle de temps, nous avons vérifié à la fois le test de régression et le cross-browser;
  • , Severity;
  • , , .

?


Assez rapidement, nous avions une question sur l'exécution de tests dans un référentiel unique, leur mise à jour et sur la possibilité d'exécuter des tests avec des marques sur le résultat de l'exécution.

L'équipe comprenait des employés ayant de l'expérience avec le système de gestion des tests TestLink . Il s'agit du seul système de gestion de cas de test open source, il a donc été choisi pour fonctionner. Dans ce système, une interface graphique très simple et une conception sans fioritures inutiles. Nous avons rapidement rempli le programme de tests, la question s'est posée de savoir comment le maintenir. Au début, beaucoup de ressources ont été consacrées à la mise à jour des cas pour chaque révision; cette option s'est avérée inopérante.

Après avoir consulté l'analyste et l'équipe de test, nous avons décidé qu'il n'était pas nécessaire de toujours mettre à jour un modèle de test aussi volumineux en raison des coûts de son support. 

Tous les cas ont été divisés conformément à la matrice des exigences fonctionnelles en dossiers, chaque module / sous-système fonctionnel stockant un ensemble de cas dans un dossier séparé. Cela nous a permis de structurer visuellement les cas de test. Des mots-clés ont été créés dans TestLink, à l'aide desquels le cas appartient à un groupe particulier, par exemple:

  • fumée - utilisée pour les cas de test inclus dans le test de fumée ( effectuer un ensemble minimum de tests pour détecter des défauts évidents de fonctionnalité critique );
  • test automatique - utilisé pour les cas de test par lesquels des tests automatiques sont développés;
  • Priorité 1 - utilisé pour les cas de test liés aux fonctions commerciales étiquetées Priorité 1.

Par conséquent, une conception de test est toujours conçue pour de nouvelles améliorations, à la suite de quoi un document de liste de contrôle apparaît. Dans ce document, les contrôles sont classés par ordre de priorité, et seule une partie des contrôles relève de la «priorité 1» ou des cas de test de fumée et de régression sont déjà créés sur eux dans le système TestLink.

Comment avoir toujours un modèle de cas de régression réel pour une version planifiée et un HotFix soudain en production?


Avant le début du test de régression, tous les travaux préparatoires, y compris la mise à jour ou l'ajout de nouveaux cas à la régression, étaient terminés. Et cela signifie que si vous exécutez un scénario de test exécuté pertinent pour la nouvelle version, ils peuvent entraîner des défauts lors de la vérification de HotFix sur ces scénarios de test. 

Des corrections de correctifs ont été apportées à l'ancienne branche de code (dernière version) et des modifications ont été apportées au code par des corrections de défauts, tandis que les cas de test actuels auraient pu être modifiés à partir des améliorations de la future version. En d'autres termes, l'exécution de cas de test pertinents pour une future version peut entraîner l'enregistrement de faux défauts et retarder la publication de HotFix.

Pour éviter l'enregistrement de faux défauts et l'interruption des délais de test HotFix, nous avons décidé d'utiliser un mécanisme quelque peu similaire à la maintenance des branches de code. Seules la fusion et la mise à jour des cas entre les branches (lire «dossiers») de TestLink ont ​​été effectuées manuellement par les testeurs selon un certain algorithme, alors que dans le modèle Gitflow cela se fait automatiquement par Git.

Voici un ensemble de cas de test dans TestLink:


Le processus de mise à jour des cas dans TestLink a été inventé

  • Le gestionnaire de tests copie le dossier avec les cas "Test Project 1.0.0" et crée une nouvelle suite de tests, qui est nommée le numéro de la prochaine version prévue. Il s'avère que le dossier avec les cas "Test project 2.0.0".
  • Après avoir étudié les améliorations d'une future version, les cas de test du dossier «Test Project 2.0.0» sont analysés pour la nécessité de les mettre à jour pour de nouvelles améliorations.

Si nécessaire, mettez à jour les cas:

  • le testeur responsable de la révision apporte des modifications au scénario de test dans l'ensemble «Projet de test 2.0.0»;
  • si vous devez supprimer un scénario de test, vous devez d’abord le déplacer vers le dossier «Supprimer», afin de pouvoir récupérer un scénario de test supprimé accidentellement ou si les exigences sont renvoyées et que le scénario de test est à nouveau demandé (le test cas uniquement du dossier correspondant à la suite de tests de la future version prévue, dans laquelle ce cas de test ne sera pas pertinent);
  • si nous ajoutons un cas de test, cela doit être fait uniquement dans le dossier correspondant à la suite de tests de la future version prévue;
  • les cas de test qui changent sont marqués du mot-clé «Modified» (nécessaire pour évaluer la métrique du degré d'influence des améliorations sur la fonction de régression);
  • les cas qui sont ajoutés sont marqués du mot-clé "Ajouté" (nécessaire pour évaluer la métrique par l'effet des améliorations sur la fonction de régression).

Ainsi, nous avons toujours une suite de tests réelle de cas correspondant à la version précédente du système et nous l'utilisons pour le test HotFix, ainsi que des travaux sur la mise à jour de la nouvelle suite de tests, la préparation des tests de régression et le processus de stabilisation de la nouvelle version prévue. À un moment donné, en même temps, 3-4 branches de test (lire «dossiers») de TestLink, correspondant à différentes versions du système, peuvent être obtenues à la fois, ce qui est particulièrement important lors du test des améliorations dans les branches de fonctionnalités.

Après chaque version, nous pouvons estimer dans quelle mesure notre modèle de régression a changé, sur la base des libellés «ajoutés» / «modifiés». 

Si le modèle de régression augmente beaucoup, alors que le volume des améliorations dans la version n'a pas changé de manière significative par rapport à la version précédente, alors c'est l'occasion de réfléchir à la justesse de la définition des priorités dans la liste de contrôle des contrôles de révision. Le testeur a peut-être fait le mauvais choix de cas de régression et il est nécessaire de prendre des mesures: par exemple, expliquer au testeur le principe de priorisation, impliquer l'analyste dans la coordination des priorités, changer le modèle de régression résultant en supprimant les cas de test redondants.

Comment optimiser le modèle de test de régression?


Nous avons commencé à travailler avec un modèle de test de régression, optimisé le processus de développement de cas de test de régression en mettant en évidence les priorités et en incluant uniquement les cas de «priorité 1» dans la régression. Face au fait que le modèle de test, après un certain temps, est devenu important, les coûts de fonctionnement de ses boîtiers ont augmenté et nous avons cessé de tomber dans l'intervalle de temps acceptable pour effectuer un test de régression sur le projet.

Le moment est venu de mettre en œuvre l'automatisation des tests, dont le but était:

  • réduire le temps nécessaire pour terminer les cas de test de régression;
  • utiliser des autotests pour créer des conditions préalables pour effectuer des vérifications ultérieures, optimisant ainsi le temps et les coûts humains de la création de données de test;
  • améliorer la qualité des tests de régression en éliminant l'influence du facteur humain sur les résultats d'un test manuel;
  • , .

Un cadre a été développé pour automatiser les tests GUI en Java (GIT a été utilisé comme système de version de contrôle de source).

Une équipe de test automatisée distincte a été impliquée dans le développement des autotests, qui ont réussi à faire face à la tâche. Pour les projets futurs d'une envergure similaire, il est prévu à l'avenir d'appliquer les développements existants et de lancer des tests automatisés en début de projet afin de bénéficier de son utilisation dans les meilleurs délais. Vous pouvez en savoir plus sur l'automatisation des tests de grands SIG dans un article de mes collègues qui étaient directement impliqués dans l'organisation et la réalisation de tests automatisés.

Du côté des tests manuels fonctionnels, le modèle de régression a également été optimisé. 

En utilisant deux grands SIG à titre d'exemple, l'équipe et moi avons conçu et mis en œuvre des sessions de test ou des visites de test, dont l'essence était la suivante: il était nécessaire d'analyser le processus métier dans chaque sous-système et de réfléchir à la session (tournée) de contrôles passant par ce processus métier, en simulant le plus Actions utilisateur fréquemment effectuées sur le processus. 

Dans un projet SIG, cela a été appelé «session de test», dans un autre, il a été appelé «tour de test». Mais l'essence est restée la même - nous avons réfléchi au scénario commercial clé de bout en bout (à travers toute la révision) qui couvre complètement l'idée commerciale de la révision mise en œuvre (il peut y avoir plusieurs de ces scénarios). 

Le scénario du tour de test a été convenu avec l'analyste, des cas de test de régression détaillés ont été élaborés et, dans les cas où ils n'ont pas réussi à effectuer le test de régression sur l'ensemble du modèle de test, ils pouvaient se limiter à mener une «session de régression» ou un «tour de test de régression», qui, en règle générale, a pris moins de temps et a permis de comprendre clairement s'il y avait des problèmes avec les processus commerciaux clés du système.

À l'avenir, les tournées de test ont été couvertes par des autotests, et les testeurs libérés des contrôles de routine sont passés aux améliorations des tests des prochaines versions prévues. 
Un exemple de tour d'essai: «création, édition, publication et annulation d'une entité». 

Un tour d'essai peut être compliqué, par exemple:

  • donner le droit de créer, éditer et annuler,
  • créer une entité dans le "Compte personnel" de l'utilisateur avec le rôle de "Spécialiste",
  • ,
  • ,
  • ,
  • « » «»,
  • , .

SLA?


Je recommande de ne pas traiter le processus de localisation des incidents des utilisateurs comme une tâche de bas niveau. Vous devez prendre cela dans le cadre du processus de test. De plus, il s'agit d'un processus beaucoup plus créatif que, par exemple, la vérification des cas de test. Il est nécessaire d'appliquer la logique, l'expérience des techniciens de conception de test, afin d'aller au fond de l'erreur, de la rattraper et de la passer en développement.

Bien sûr, il est conseillé d'organiser le processus de fonctionnement du SIG avec trois niveaux de support (idéalement) et, par conséquent, les incidents les moins évidents que souvent seuls les testeurs sont capables de localiser échoueront dans l'équipe de test, qui sont déjà filtrés sur les deux premières lignes.

Pour se conformer au SLA, nous recommandonsfaites du processus de localisation des incidents une tâche prioritaire dans l'équipe de test et essayez d'introduire des méthodes d'optimisation afin que la vitesse de lecture des incidents soit aussi élevée que possible. 

Pour optimiser le temps passé par les testeurs, vous pouvez:

  • maintenir une base de connaissances de projet avec des requêtes SQL typiques ou fréquemment rencontrées;
  • organiser le processus de classement des tâches entrantes dans le bugtracker afin que le testeur voit immédiatement un incident tombé sur le panneau indicateur et le fasse fonctionner en première priorité;
  • ajouter des compteurs de temps de compte à rebours dans JIRA pour les tâches qui ont des SLA;
  • mettre en place un système d'alerte pour les incidents;
  • production ( — ), , , , , , production;
  • « » « ». . 

À propos de la "matrice des connaissances" a été écrite ci-dessus. Quant à la «matrice de responsabilité», il s'agit d'un tableau dans lequel, par analogie avec la «matrice de connaissances», les blocs / modules / sous-systèmes fonctionnels sont écrits et lequel du groupe de test est responsable du test du fonctionnel, en règle générale, il s'agit du chef d'équipe ou du testeur principal / principal dans un groupe.

Que se passe-t-il si le testeur d'un bloc fonctionnel / module / sous-système ne comprend pas l'intégralité du processus métier du projet?


C'est un sujet sensible que nous avons rencontré dans plusieurs grands projets SIG. L'équipe a fait une «matrice de connaissances», les testeurs ont effectué une auto-évaluation du degré d'immersion dans le fonctionnel et se sont assignés à leur élément de fonctionnalité. Mais à un moment donné, des testeurs expérimentés qui ont participé dès le début du projet ont abandonné le groupe, et de nouveaux spécialistes n'étaient pas encore plongés dans tous les processus commerciaux et ne voyaient pas l'image complète. Cela a conduit au fait que lors du test des cas dans un module, les résultats de ce cas auraient dû être utilisés dans le module suivant, et par conséquent, si des résultats incorrects étaient fournis à l'entrée du deuxième module (les conditions préalables n'étaient pas idéales pour exécuter les cas du module précédent), il était alors nécessaire d'analyser la situation. et consigner les erreurs.

Mais les testeurs n'ont pas réfléchi à la raison pour laquelle de tels chiffres sont venus à leur entrée et ont simplement travaillé sur leurs cas. Formellement, le test a été effectué, tout va bien, aucun défaut n'a été trouvé, et lorsque l'analyste accepte le fonctionnel ou lors de la préparation des tests d'acceptation, des problèmes importants dans le travail de logique métier qui ont été manqués sur le test sont clarifiés. La raison en était un manque de compréhension du processus opérationnel de bout en bout effectué par le système.

Dans cette situation, les actions suivantes ont été entreprises:

  • immergé dans le fonctionnel avec l'implication de l'analyste;
  • une formation a été dispensée dans le groupe de test, un échange d'expériences, des histoires lors de rassemblements sur son sous-système et ce qui s'y passe, une discussion sur les nouvelles améliorations prévues pour le sous-système dans la prochaine version prévue;
  • attirer des analystes et introduire des modèles d'information dans les spécifications de spécification sur le degré d'impact des améliorations sur les modules / sous-systèmes tiers;
  • la mise en œuvre du processus de test pour les sessions de test (tours), qui sont des testeurs et les coordonnent avec les analystes (contribue à réduire les risques de mauvaise compréhension du processus métier par l'équipe et le nombre d'erreurs métier dans le système).

Fuh! J'ai essayé de rassembler les principaux problèmes et recommandations pour leur élimination, mais c'est loin de toutes les informations utiles que je souhaite partager.

Chapitre 4. Mesures pour déterminer la qualité du projet et la méthodologie pour évaluer les coûts de main-d'œuvre pour les tests


Avant d'introduire la collection de métriques sur le projet, nous nous sommes demandé: "Pourquoi devrions-nous faire cela?" Les principaux objectifs étaient de surveiller la qualité de l'équipe de test, la qualité de la version produite en production et de surveiller les indicateurs de performance des participants du groupe de test afin de comprendre comment développer l'équipe.

Une analyse a été effectuée sur les mesures nécessaires pour atteindre les objectifs. Ensuite, ils ont été divisés en groupes. Ensuite, ils ont réfléchi à ce qui peut être mesuré sans changements supplémentaires dans le processus, et où l'aide des autres membres de l'équipe de projet sera nécessaire.

Une fois toutes les étapes préparatoires terminées, l'assemblage régulier des métriques a commencé: une fois par mois / release / sprint / trimestre - selon le projet et les caractéristiques du processus de production.

Ayant collecté les premières métriques, il a fallu déterminer les indicateurs cibles que nous souhaitons viser à ce stade du développement du projet. Il restait ensuite à prendre régulièrement des métriques et à analyser les raisons de leur écart par rapport aux indicateurs cibles, à prendre des mesures visant à améliorer les indicateurs, c'est-à-dire à optimiser non seulement le processus de test, mais aussi l'ensemble du processus de production du projet.

Bien sûr, non seulement les testeurs étaient impliqués dans l'amélioration de la qualité, les analystes et le responsable du développement et des versions étaient également impliqués dans l'optimisation du processus, les ingénieurs DevOps étaient tous des participants clés dans le processus, car tout le monde voulait améliorer la qualité de la version et améliorer leur travail. 

Un exemple de la façon dont la collecte de mesures et d'objectifs sur l'un des projets terminés ressemble à:


Méthodologie d'évaluation des coûts de main-d'œuvre pour les tests


Afin d'informer le chef de projet des délais plus précis pour l'achèvement des tests, sur la base de la collecte de métriques provenant de projets similaires, une méthodologie a été développée pour évaluer l'effort de test, qui permet de rendre compte le plus précisément possible du temps d'achèvement du test et de notifier les risques des tests.

Cette technique est utilisée sur tous les projets d'implémentation SIG, les différences ne peuvent être que dans certaines valeurs métriques, mais le principe de calcul est le même.

Mesures utilisées pour effectuer une évaluation détaillée des coûts de test


Les métriques de temps sont obtenues par des mesures répétées des coûts réels des testeurs de différents niveaux de compétence sur différents projets, la moyenne arithmétique est prise.

Le temps d'enregistrement d'une erreur est de 10 minutes (le temps d'enregistrement d'une erreur dans le traqueur de bogues).
Le temps de validation de l'erreur / raffinement est de 15 minutes (le temps de vérifier l'exactitude de la correction de 1 erreur / raffinement).
Temps pour écrire 1 TC (cas de test) - 20 minutes (temps pour développer un cas de test dans le système TestLink).
Temps pour terminer 1 TC - 15 minutes (temps pour terminer les vérifications sur un cas de test dans le système TestLink).
Temps pour un test. Le temps total obtenu en ajoutant les coûts dans la liste de contrôle pour la colonne "Délai, min."
Heure du rapport de test - 20 minutes (temps pour rédiger un rapport selon le modèle).
Le temps des erreurs . Temps prévu pour l'enregistrement de toutes les erreurs / clarifications, (temps pour l'enregistrement de 1 erreur / clarification * nombre possible d'erreurs / clarifications (10 erreurs pour la révision - le nombre estimé d'erreurs par révision)).
Temps total sur DV (validation des défauts) . Temps prévu pour la validation de toutes les erreurs / raffinements trouvés et corrigés (temps pour la validation de 1 erreur / raffinement * nombre estimé d'erreurs / raffinements).
Préparation des données de test. Le temps de préparation des données de test est calculé subjectivement sur la base de l'expérience de test de tâches similaires sur le projet en cours en fonction de différents paramètres (l'étendue de la tâche du point de vue de l'analyste de test, les compétences de l'équipe de développement du code (nouvelle équipe inconnue ou équipe éprouvée pour laquelle il existe des statistiques sur la qualité du travail) , intégration entre différents modules, etc.).

En mesurant les coûts réels de l'un des projets, les éléments suivants ont été calculés: 

  • pas plus d'une heure par tâche jusqu'à 60 heures de développement,
  • pas plus de 3 heures par tâche jusqu'à 150 heures de développement,
  • pas plus de 4 heures par tâche jusqu'à 300 heures de développement.

Dans des cas particuliers, les coûts prévus pour la préparation des données de test peuvent changer en accord avec le responsable du test.
 
Il est temps d'écrire TC . Le temps pour écrire le TC, qui est estimé après que la liste de contrôle est prête pour l'inspection et la priorisation pour les tests. Pour le test de régression, les TC ont été marqués avec la priorité 0 (le nombre de contrôles de priorité 0 * 20 minutes (temps d'écriture pour 1 TC)).
Il est temps de régresser selon TC. Temps pour terminer une itération des tests de régression selon TC dans le système TestLink (nombre de TC * temps d'exécution moyen de 1 TC (15 minutes)). 
Des risques 15% du temps pour le test est posé (les risques signifient toutes les opérations manuelles, les chutes de stand, les problèmes de blocage, etc.). 
Temps total pour les tests.Le coût total des tests pour un HL (préparation des données de test + exécution du test + temps d'enregistrement des erreurs / clarifications + validation des erreurs / clarifications + temps de régression selon TC Priority 0 + risques) en h / h.
Temps total pour la tâche. Coûts totaux pour l'ensemble de la tâche de test, chiffre en h / h (temps total pour les tests + temps pour le rapport + temps pour la rédaction du TC).

Toutes ces métriques sont utilisées sur le projet pour résoudre diverses tâches liées à la planification, aux évaluations de travail, à la fois temporaires et financières. Comme la pratique l'a montré, une telle estimation donne une erreur minimale (pas plus de 10%), qui est un indicateur assez élevé de la fiabilité de l'estimation.

Bien sûr, vous ne pouvez pas utiliser de métriques ou vos métriques selon les statistiques peuvent différer considérablement, mais le principe d'estimation du coût du travail de test peut être appliqué à n'importe quel projet et choisir la formule de calcul la plus optimale pour votre projet et votre équipe.

Chapitre 5. Recette pour un processus de test SIG réussi


Il est important de montrer aux responsables de test et aux testeurs que face aux difficultés et aux nouvelles tâches, vous pouvez trouver des solutions, optimiser le processus de test et essayer d'appliquer l'expérience accumulée aux futurs projets. 

J'ai préparé des surprises pour tous les lecteurs - une recette pour un processus de test SIG réussi et des modèles de documents que vous pouvez télécharger et utiliser sur vos projets.
Ainsi, la recette sur la façon de réussir le processus de test d'un grand système d'information, et ce que nous recommandons d'inclure dans ce processus, je vais essayer de l'énoncer brièvement et de manière concise.

Du processus d'analyse:

  • Mettre en œuvre des modèles d'exigences techniques
  • mettre en œuvre les règles d'élaboration des exigences techniques dans un groupe d'analystes;
  • élaborer un règlement sur la notification de l'état de préparation des exigences techniques de l'équipe de projet.

:

  • - ;
  • ;
  • ;
  • :

    ○ - ;
    ○ -;
    ○ ;
  • , , , , , ;
  • , , , , ;
  • ;
  • ;
  • ;
  • ;
  • (, , ..);
  • , , ;
  • utiliser les recommandations de collègues plus expérimentés, les développements d'autres projets, des fiches de triche prêtes à l'emploi , mener des sessions de brainstorming avec l'équipe et rechercher de nouvelles méthodes pour optimiser et améliorer le processus.

Maintenant, je me prépare à tester le nouveau SIG. Voici à quoi ressemble mon Wiki de travail, qui prend déjà en compte de nombreux points que nous avons recommandé de faire:


Surprise pour les patients lecteurs.


Si vous lisez l'article jusqu'au bout, vous méritez un cadeau. Je veux partager avec vous des modèles utiles que vous pouvez utiliser dans votre travail:

  • le modèle de liste de contrôle , qui comprend l'ensemble minimal de recommandations pour tester les éléments d'interface des formulaires d'écran (bien sûr, il existe des options plus larges pour les contrôles, ce n'est qu'un exemple), comprend des formules pour calculer les coûts des tests avec des explications sur la méthode de calcul;
  • modèle de rapport de test ;
  • modèle de matrice : connaissance / distribution par les navigateurs / plates-formes / calendrier des vacances de l'équipe du projet;
  • Une liste de métriques clés pour le projet avec des explications.

J'espère que nos recommandations, exemples, idées, liens et mes modèles aideront de nombreuses équipes à construire correctement le processus de test, à optimiser leurs coûts et à faire face avec succès aux tâches d'un projet responsable et complexe. 

Si vous souhaitez rejoindre l'équipe de test LANIT et participer aux tests SIG, je vous conseille de voir les offres d'emploi de notre entreprise.

Venez dans nos écoles de tests!
, , .


Je vous souhaite tous les projets intéressants et bonne chance!

PS Il faut vraiment mener une petite enquête. 

More articles:


All Articles