V&V pas pour vendetta

Au cours des six dernières années, j'ai travaillé au développement et à l'acceptation des tests des applications pour mener et soutenir les essais cliniques. Applications de tailles et de complexité variées, big data, un grand nombre de visualisations et de vues, entreposage de données, ETL, etc. Les produits sont utilisés par les médecins, la direction des essais cliniques et les personnes impliquées dans le contrôle et le suivi de la recherche.

Pour les applications qui ont ou peuvent avoir un impact direct sur la vie et la santé des patients, un processus de test d'acceptation formel est requis. Les résultats des tests d'acceptation ainsi que le reste du dossier de documentation sont soumis pour audit à la FDA (Food and Drug Administration, USA). La FDA autorise l'utilisation de l'application comme outil de surveillance et de réalisation d'essais cliniques. Au total, mon équipe a développé, testé et envoyé à la production plus d'une trentaine d'applications. Dans cet article, je parlerai brièvement des tests d'acceptation et de l'amélioration des outils utilisés pour cela.

Remarque: Je ne prétends pas être la vérité ultime et je comprends parfaitement que la plupart de ce que j'écris est un monologue de Captain Obvious. Mais j'espère que ce qui est décrit peut être utile à la fois au niveau d'entrée et aux équipes qui rencontrent cela dans le travail de tous les jours, ou du moins il peut rendre heureux ceux qui ont des processus plus simples.

FDA

Les essais cliniques sont des expériences ou des observations faites en recherche clinique. Ces études prospectives de recherche biomédicale ou comportementale sur des participants humains sont conçues pour répondre à des questions spécifiques sur les interventions biomédicales ou comportementales, y compris les nouveaux traitements (tels que les nouveaux vaccins, les médicaments, les choix alimentaires, les compléments alimentaires et les dispositifs médicaux) et les interventions connues qui justifient une étude plus approfondie et comparaison. Les essais cliniques génèrent des données sur l'innocuité et l'efficacité. Wikipédia

En d'autres termes, pour que la pilule contre les maux de tête se rende à un comptoir de pharmacie quelque part sur Brighton Beach, elle passe par 3 phases d'essais humains, au cours desquelles il est déterminé la quantité de substance active qui doit être contenue dans le comprimé, sa sécurité et s'il guérit du tout les maux de tête.

Qu'est-ce que la FDA en termes de ce que nous faisons et comment cela affecte-t-il le processus de développement et le cycle de publication?

La Food and Drug Administration (FDA ou USFDA) est une agence fédérale du département américain de la Santé et des Services sociaux, l'un des départements exécutifs fédéraux des États-Unis. La FDA est chargée de protéger et de promouvoir la santé publique par le contrôle et la supervision de la sécurité alimentaire, des produits du tabac, des compléments alimentaires, des médicaments pharmaceutiques sur ordonnance et en vente libre (médicaments), des vaccins, des produits biopharmaceutiques, des transfusions sanguines, des dispositifs médicaux, des rayonnements électromagnétiques dispositifs émetteurs (ERED), cosmétiques, aliments et aliments pour animaux et produits vétérinaires. Wikipédia

En fait, la FDA ne concerne pratiquement pas le processus de développement lui-même, nous travaillons selon SCRUM habituel (pour être honnête, ce n'est pas tout à fait SCRUM - ils disent qu'il est maintenant à la mode d'appeler un tel processus "un SCRUM modifié") avec un non cycle de libération de sprint. Nous ne livrons pas à la production à la fin de chaque sprint (et même à la fin de trois sprints, et même dix si la chronologie implique 15 sprints), c'est-à-dire du point de vue de la livraison à l'utilisateur final , nous avons une méthodologie de type cascade.

Dans notre cas, le test est divisé en deux parties indépendantes avec des délais différents, des estimations différentes et des processus différents. La première partie est le test en développement habituel, où le testeur fait partie intégrante de l'équipe de développement et termine les sprints avec le développement. La deuxième partie est le test d'acceptation réel et la maintenance des activités connexes (si nécessaire). Le processus est construit selon la méthodologie V&V: exigences utilisateur et fonctionnelles à l'entrée, scripts de test et un ensemble de documentation à la sortie.

Le cycle de publication dépend de la portée du projet, les versions ne sont généralement pas itératives. Après la publication, l'application peut rester inchangée pendant une longue période, une interruption entre les versions peut varier de quelques mois à un an ou plus.

V&V

Qu'est-ce que V&V et comment cela affecte-t-il le processus d'acceptation?

«Dans la gestion de projets logiciels, les tests logiciels et l'ingénierie logicielle, la vérification et la validation (V&V) est le processus de vérification qu'un système logiciel répond aux spécifications et qu'il remplit son objectif. Il peut également être référé à un contrôle qualité logiciel. Il incombe normalement aux testeurs de logiciels dans le cadre du cycle de vie du développement logiciel. En termes simples, la vérification du logiciel est: "En supposant que nous devrions construire X, notre logiciel atteint-il ses objectifs sans bugs ni lacunes?" Par contre, la validation du logiciel est: "X était-il ce que nous aurions dû construire? X répond-il aux exigences de haut niveau? » Wikipedia

En d'autres termes:
Vérification: faisons-nous bien le produit?
Validation: faisons-nous le bon produit?

Cela signifie que nous devons tester les spécifications fonctionnelles et utilisateur avec l'exhaustivité nécessaire et suffisante. Pour nous, le premier V se transforme en test d'acceptation technique (SIT), le second en support d'UAT, où:

• SIT - Test d'intégration système
• UAT - Test d'acceptation des utilisateurs

La visualisation de la couverture des exigences est réalisée dans la matrice de traçabilité (un tableau régulier dans Excel ou Word, je m'y attarderai plus tard), ce qui permet de remonter des exigences au test et vice versa. Dans le cas de l'utilisation de la gestion électronique de documents, la matrice est construite automatiquement, les tests sont liés aux exigences qui sont stockées avec les tests (ensemble = HP ALM, bien sûr non mélangés). Dans le cas où l'exigence n'est pas couverte et ne le serait pas, nous justifions pourquoi nous ne la couvrons pas.

Lorsque la couverture des exigences n'est pas requise?

Par exemple, CFR Part 11 ( FDA Rules for Electronic Records and Electronic Signatures ) contient de nombreuses exigences qui ont déjà été couvertes par Microsoft, donc si nous utilisons Windows AD pour l'authentification, nous n'avons pas besoin de couvrir à nouveau ces exigences.

En fin de compte, l'essence des tests d'acceptation se résume à tester la conformité du produit avec les exigences et les exigences de conformité avec le produit.

Rôles

Un assez grand nombre de rôles participent au processus, qui sous une forme ou une autre sont familiers à toutes les personnes impliquées dans le développement de logiciels: Développeur (Junior, Moyen, Senior, Lead), Unit Tester, SIT Tester, Technical Product Owner, Business Product Propriétaire, Scrum Master, Project Manager, Business Analyst, Technical Lead, SIT Test Lead, UAT Test Lead, Global QC, Support, Deployment Engineer et autres.

Le rôle qui nous est propre - Global QC . Il s'agit de la personne du côté du client qui est responsable de l'observation et du respect des exigences du processus - Cycle de vie du logiciel et toutes sortes de procédures opérationnelles standard (SOP) du côté du client - pendant le développement et l'acceptation, et fournit en outre un ensemble de documents pour un audit externe.

Documentation d'acceptation

Dans le cadre de la sortie du produit, nous créons un package de documentation qui incorpore un grand nombre de niveaux d'imbrication, y compris une documentation relative à la façon dont le produit a été testé, pourquoi il a été testé de cette façon et non autrement, ce qui était spécifiquement dans la portée des tests et ce qui n'était pas:

Plan de validation et composition de l'équipe - PM est responsable de la création et de l'approbation du document. Le document comprend généralement la description du système, la liste des artefacts de développement et de test, la stratégie de validation, la liste des rôles et des responsabilités.

Stratégie de test - le document qui n'appartient pas à l'application spécifique mais existe pour la branche de produits ou une branche de test. Par exemple, comment pouvons-nous déterminer quelle partie des tests serait automatisée, que prévoyons-nous d'utiliser pour l'automatisation, comment prévoyons-nous effectuer des tests manuels, prévoyons-nous d'utiliser des listes de contrôle, des scripts de test, les deux ou quoi que ce soit d'autre sinon; comment prévoyons-nous de décider d'effectuer ou non des tests de performance / charge / volume; et des choses comme ça.

Plan de test - commun aux équipes UAT et SIT, comprend une brève description de l'objet de test, des restrictions possibles, des exigences d'environnement, du calendrier, des suites de tests, etc.

Suite de tests - un ensemble de tests ou de listes de contrôle formés par domaine fonctionnel, type de test ou toute autre caractéristique.

Matrice de traçabilité - une matrice avec des traces des exigences aux tests. Le traçage des exigences comme preuve de la couverture est une partie importante du processus. En utilisant l'identifiant de toute exigence, vous pouvez trouver une étape spécifique dans laquelle cette exigence est testée et fournir des preuves au réviseur (capture d'écran, fichier, etc.) pour une version spécifique de l'application (ou pour chaque version dans laquelle cette exigence était officiellement couvert). Par conséquent, reliez, reliez et reliez à nouveau les tests aux exigences (tâches), sur la base desquelles vous obtenez le résultat attendu, même si cela n'est pas exigé de vous, car cela vous simplifierait la vie à l'avenir. Si cela est impossible en raison de l'utilisation de différents outils non intégrants, vous pouvez toujours laisser des commentaires dans les tâches / tests, ou créer une matrice (Excel mentionnée ci-dessus), ou créer une base de données primitive de trois tables.

PDS - Product Design Specification, Tech Lead ou System Architect est responsable de la création du document. En fait, il s'agit d'une sorte de combinaison de documents d'architecture de haut et de bas niveau (HLA et LLA).

FRS & URS ou BRS - exigences fonctionnelles et utilisateur. Habituellement, il existe deux documents distincts, mais parfois il existe une spécification des exigences commerciales qui intègre les deux spécifications.

Journal des défauts - un journal des bogues identifiés dans l'application et / ou les exigences lors du SIT formel.

Journal des problèmes mineurs - un journal des changements mineurs dans les scripts de test (fautes de frappe, exigences de gauche ou redondantes, erreurs éventuelles).

Rapport de synthèse de test - un rapport sur les résultats de la phase de test, qui comprend les éléments suivants:

• Informations sur les builds utilisées pour les tests (y compris les numéros de build et les dates de déploiement avec des informations sur les raisons du déploiement), le nombre de cycles de test et les résultats des scripts de test (réussite / échec).
• Une description des écarts entre les SOP.
• La liste des défauts ouverts avec justifications.
• Le lien vers le journal des défauts ou le journal des défauts lui-même.
• Le lien vers le journal des problèmes mineurs ou le journal lui-même.
• Une recommandation sur le déploiement dans l'environnement de production.

Plan de déploiement - le document qui est utilisé pour le déploiement en production, comprend une description des annulations.

Rapport de synthèse de validation - le document de clôture du plan de validation.

Approbation de la documentation

Tout processus d'approbation de la documentation peut être divisé en 3 étapes:

• Préparation du document.
• Revue
• Approbation

Regardons l'exemple d'une suite de tests.

Pour écrire des scripts de test et les combiner dans des suites de tests, nous utilisons un modèle standard approuvé du côté client.

Paragraphes de la suite de tests:

• Nom du projet et de l'application.
• Version de sortie.
• Nom et identifiant unique de la suite.
• Description (que testons-nous et quels types de tests utilisons-nous).
• Scripts de test.
• Liste des approbateurs.

À son tour, chaque test consiste en:

• Nom et identifiant unique du script de test.
• Description.
• Conditions préalables.
• Postconditions.
• Références de traçabilité.
• Instruction d'exécution (par exemple, instruction de masquer des données sensibles).
• Étapes (procédure, résultats attendus et observés).
• Résultat du script de test.
• Testeur.
• Réviseur

Le cycle de vie normal du test ressemble à une cascade et ressemble à ceci:

1. Écriture
   Analyse des besoins. Définition et application de techniques de conception de test pour la couverture de fonctionnalité la plus adéquate. Étapes d'écriture.
2. Essais à sec sur environnement de développement
   À ce stade, nous essayons de trouver comment l'application répond aux exigences et de trouver la plupart des erreurs possibles, y compris les erreurs d'exigences.
3. Examen de la personne responsable (chef d'équipe SIT)
   Revue stylistique et logique.
4. Pistes sèches sur environnement assis
   À ce stade, les erreurs associées à l'installation, l'environnement et la configuration de l'environnement sont détectées (par défaut, nous supposons que l'environnement SIT répète exactement ou presque complètement PROD). La réussite de cette étape signifie que la version déployée est stable et que la version peut être considérée comme candidate.
5. Avis client (Global QC)
   Global QC vérifie que les exigences sont remplies et que les tests écrits correspondent aux SOP de l'entreprise.
6. Approbation (QC global, PO technique, PO d'entreprise).
7. Exécution formelle du script de test sur l'environnement SIT (version candidate à la sortie)
   Après l'approbation des tests d'exécution (p. 6) et la réussite des essais à sec sur l'environnement SIT (p. 4), le test est formellement exécuté sur l'environnement SIT avec la fixation formelle du résultat. Si les bogues trouvés dans les passes d'essai à sec ne sont pas formels et sont simplement saisis dans Jira de la même manière que ce qui se passe pendant le processus de développement, un formulaire de défaut distinct est créé pour chaque bogue trouvé dans l'exécution formelle, qui est inclus dans la documentation de sortie emballage pour le produit.
8. Examen de l'exécution du script de test (chef d'équipe SIT).
   Idem au point 3.
9. Avis client (Global QC)
   Global QC vérifie l'exactitude et l'exhaustivité du remplissage des résultats, les erreurs possibles, la présence de preuves (par exemple, des captures d'écran). Un point important, car c'est Global QC qui est chargé de fournir un ensemble de documents à un audit externe (par la FDA ou les clients).

Travailler avec des données personnelles

Étant donné que la recherche est menée en utilisant la méthodologie en double aveugle *, c'est le moindre de nos problèmes. Mais les données des médecins, les noms des entreprises, les numéros de protocole de recherche, etc., doivent être modifiés. D'un point de vue formel, si nous ne pouvons pas nous débarrasser des données sensibles, nous devons les masquer sur les captures d'écran, mais c'est une situation assez standard et compréhensible.

* en double aveugle - les patients sont répartis au hasard en deux groupes, dont l'un reçoit le médicament à l'étude et le second un placebo ou un médicament dont l'efficacité a été prouvée. En même temps, ni le médecin ni le patient ne savent à quel groupe le patient a été affecté. Cela élimine le biais du médecin et l'effet placebo. Dans le cadre du travail avec des données personnelles, cela signifie que dans la plupart des cas, l'identité du patient ne peut pas être identifiée sur la base de données stockées dans la base de données ou accessibles à l'utilisateur.

Mais le fait que ce soit le moindre de nos problèmes ne signifie pas qu'il ne peut pas créer de problèmes. Voici quelques râteaux (à ne pas marcher deux fois) que nous avons obtenus sur nos projets:

Peut être amusant (pas pour nous en ce moment): "The Globe"

Dans l'une des applications, pour créer un effet wow et pas seulement, nous avions vraiment besoin de créer un globe interactif que vous pouvez faire pivoter avec la souris, basculer jour / nuit et ainsi de suite. Sur le globe, il y a des marques sur les adresses, qui sont colorées en fonction des valeurs et des plages dans lesquelles ces valeurs se situent (une sorte de codage couleur). Après avoir anonymisé la base de données sur l'environnement de démonstration, deux heures avant la démonstration, grâce au script d'anonymisation, nous nous sommes retrouvés sans code postal avec toutes les conséquences.



Moralité: ne touchez pas aux données deux heures avant la démo.

Deuxième histoire: "À propos de l'anonymisation"

Contexte: Les données sont collectées dans le référentiel à partir d'un grand nombre de sources, les données appartiennent à différents domaines, mais sont interconnectées par des identifiants.

L'histoire: les données ont été téléchargées dans la base de données et anonymisées avant d'être utilisées à des fins de test. Il s'est avéré que les données n'étaient pas téléchargées à partir de toutes les sources nécessaires. Ensuite, ils ont chargé la partie manquante. Il n'a pas été possible de connecter la deuxième partie des données (non encore anonymisée) à la première partie déjà anonymisée. En conséquence, le démarrage des travaux sur l'environnement SIT a été reporté de deux semaines, pour lesquelles les équipes de déploiement et de support ont corrigé les données.

Moralité: avant l'anonymisation, vous devez vous assurer que la base de données contient tout ce qui doit s'y trouver et réfléchir à l'avance à l'applicabilité des mécanismes d'anonymisation et d'obscurcissement.

Flux de travail électronique vs papier en pratique

Le flux de travail électronique simplifie quelque peu la communication et le processus de révision et de passage du point de vue du travail manuel, mais ne donne pratiquement aucun gain en termes de temps de préparation aux tests et d'exécution. Voici les avantages et les inconvénients du flux de travail électronique par rapport au papier sur la base de l'exemple de HP ALM.

Bénéfices:

• Facile à supporter.
• Moins de travail manuel.
• Tous les membres de l'équipe à tout moment ont accès à l'état actuel d'un test particulier
• Historique des changements.
• Histoire des exécutions.
• Vous pouvez suivre le temps nécessaire pour terminer le test.
• Planification des prochaines courses facile.
• Il est difficile d'utiliser une mauvaise version du script de test.
• Signature électronique.

Inconvénients (spécifiquement pour HP ALM):

• Grande quantité de temps pour le formatage des scripts.
• Problèmes périodiques avec l'outil lui-même.
• Pas le meilleur correcteur orthographique.
• Interface peu pratique.
• Le temps consacré à la rédaction et à la révision des tests est pratiquement identique à celui des tests dans Word.
• Coût.

Une histoire vraie liée à la paperasse et aux signatures manuelles: «Un cauchemar avant la sortie»

Un soir, j'ai écrit 450 fois: «la couleur des points sur le graphique correspond à celle indiquée dans le cahier des charges. Nom, prénom, date »et apposez une signature - tout simplement parce que nous avons imprimé sur une imprimante noir / blanc et que la couleur des points sur les graphiques importait.



Moralité: le choix des moyens doit être cohérent avec les objectifs.

Une autre histoire: «Le lourd est bon, le lourd est fiable.» ©

Le flux de travail papier concerne le papier (qui en douterait). La phase de test d'acceptation pour une application loin de la plus importante peut être d'environ cinq kilogrammes de papier.



La conclusion qui se dégage des histoires ci-dessus (et de nombreuses inédites): malgré les inconvénients répertoriés et non répertoriés du flux de travail électronique - si vous pouvez choisir, choisissez définitivement l'électronique, même si HP ALM (plus HP).

Automatisation

Un grand nombre de visualisations ne permet pas d'automatiser de manière stable les applications, par conséquent, dans le cadre de l'approche initiale, nous nous sommes limités aux tests unitaires (y compris les tests côté base de données) et aux tests API, sans aucune tentative d'évolution vers E2E.

Comment et pourquoi en sommes-nous arrivés à une automatisation au moins partielle?

La première tâche a été de nous expliquer que dans certains cas nous gagnerions vraiment du temps. Oui, c'est compréhensible: tout le monde ne croit pas à l'automatisation et souvent son utilisation ne se justifie pas - car elle est utilisée de manière incorrecte, pas là, et pas pour cela, mais c'est un sujet pour une discussion séparée, dont il y a sont un peu moins que "l'automatisation doit avoir !!!", mais encore beaucoup.

La deuxième chose est d'expliquer au client qu'il gagnera du temps et qu'il sera suffisamment fiable et acceptable d'un point de vue formel. L'industrie est contrôlée et il y a des raisons à cela.

Troisièmement, et principalement: pour déterminer l'algorithme par lequel nous pouvons consciemment prendre une décision concernant l'automatisation du test d'une application particulière ou d'une partie de l'application, et obtenir le consentement pour l'automatisation. Ceci est important car il est clair que le processus d'automatisation ne doit pas être moins contrôlé que le processus décrit pour les scripts de test manuels.

Après avoir expliqué et justifié les deux premiers points à nous-mêmes et au client, nous avons rédigé une stratégie de test, demandé aux analystes commerciaux d'ajouter des champs supplémentaires aux exigences et formé un ensemble de questions, en fonction des réponses auxquelles nous pouvons former un ensemble pour l'automatisation.

La liste des questions dans notre cas:

1. Est-il possible d'automatiser les tests dans ce cas particulier?
2. Est-ce un composant stable *?
3. À quelle fréquence devons-nous exécuter des scripts de test pour ce composant?
4. Est-ce une fonction critique pour l'entreprise? **
5. Est-il difficile d'automatiser les tests?

* Stable = le composant n'a pas changé depuis un certain temps et aucun changement de composant n'est prévu pour les prochaines versions.
** Il est rempli en fonction de la valeur du champ ajoutée aux exigences par l'analyste métier.


En général, le processus décisionnel est le suivant:

1. À l'entrée, nous avons des exigences de FRS.
   Nous créons Design Matrix, où chaque ligne est une exigence FRS, et les colonnes sont:
   
   • Description des exigences
   • Questions 1-5
   • Décision d'équipe
   • Estimation approximative
   • Approbation
   • Commentaires
2. L'équipe pose des réponses aux questions et, sur la base des données reçues, détermine s'il vaut la peine d'automatiser le test d'une exigence / d'un groupe d'exigences spécifiques en tout ou en partie.
3. Le client examine la solution proposée et approuve la version finale.
4. Après approbation de la matrice de conception, des autotests sont écrits. Les scripts pour les autotests sont écrits en notation Gherkin et subissent une révision similaire à celle des tests manuels (Global QC, Technical Owner, Business Owner). Les définitions d'étape, les objets de page, etc., sont revus sur les demandes d'extraction, y compris par un spécialiste technique de la part du client. Les résultats de l'autotest et les rapports générés sont examinés et approuvés du côté QC global.

Dans les deux ans suivant la mise en œuvre, nous sommes passés à l'automatisation partielle des tests d'acceptation de deux applications liées au téléchargement, à la configuration et à l'affichage des données dans l'entrepôt de données, et dans un proche avenir, nous prévoyons de continuer à utiliser l'approche combinée sur d'autres produits développés pour le client, si possible.

Conclusion

En conclusion, je voudrais noter que les tests d'acceptation formels ne sont pas quelque chose d'effrayant ou d'inutile, comme cela semble à beaucoup de gens dans l'industrie. Il permet, en tirant pleinement parti de l'approche de test de scénario, de faciliter le test des futures versions, de confirmer le niveau nécessaire et suffisant de qualité logicielle, et en définitive de rassurer le client. Et qu'est-ce qui, sinon la tranquillité d'esprit du client, est important dans le développement de l'externalisation?