V&V ne signifie pas vendetta

Au cours des six dernières années, j'ai développé et accepté de tester une variété d'applications en termes de complexité et de taille pour mener et maintenir des essais cliniques. Big data, un grand nombre de visualisations et de vues, entreposage de données, ETL et similaires. Le produit est utilisé par les médecins, la direction 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é en production plus d'une trentaine d'applications. Dans cet article, je parlerai brièvement des tests d'acceptation et du développement d'outils dans un petit groupe.

Remarque: Je ne prétends pas être la vérité ultime et je comprends que la plupart de ce que j'écris concerne les preuves du monologue du capitaine. Mais j'espère que la description se révélera utile à la fois au niveau d'entrée et aux équipes qui rencontrent cela dans leur travail quotidien, ou du moins s'il plaît à ceux qui ont des processus plus simples.

FDA

Les études cliniques à travers le monde sont une étape intégrale dans le développement de médicaments, qui précède son enregistrement et son utilisation médicale généralisée. Dans les essais cliniques, un nouveau médicament est étudié pour obtenir des données sur son efficacité et sa sécurité. Wikipédia

En d'autres termes, pour qu'une pilule «de la tête» arrive à un comptoir de pharmacie quelque part à Brighton Beach, elle passe 3 phases d'essais humains, au cours desquelles il est déterminé combien de substance active doit être contenue dans le comprimé, dans quelle mesure il est sûr et s'il guérit du tout maux de tête.

Qu'est-ce que la FDA pour nous et comment affecte-t-elle le processus de développement et le cycle de publication?

La Food and Drug Administration (FDA, USFDA, lettres. Food and Drug Administration) est une agence du département américain de la Santé et des Services sociaux, l'un des départements exécutifs fédéraux. Le département est impliqué dans le contrôle de qualité des produits alimentaires, pharmaceutiques, cosmétiques, produits du tabac et de certaines autres catégories de marchandises, et surveille également le respect de la législation et des normes dans ce domaine. Wikipédia

La FDA ne concerne pratiquement pas le processus de développement lui-même, nous travaillons sur le SCRUM habituel (ou plutôt, pas tout à fait SCRUM - ils disent qu'il est maintenant à la mode d'appeler un tel "SCRUM modifié") avec un cycle de sortie non sprint. Nous n'allons pas au prod à la fin du 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 quelque chose comme une cascade.

Les tests dans notre cas sont divisés 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 (si nécessaire). Le processus est construit selon la méthodologie V&V: exigences utilisateur et fonctionnelles en entrée, tests et ensemble de documentation à la sortie.

Le cycle de publication dépend du volume de travail, les versions ne passent généralement pas par des itérations. Après la publication, l'application peut rester inchangée pendant une longue période, c'est-à-dire une pause entre les versions - de quelques mois à un an ou plus.

V&V

De quel type d'animal s'agit-il, V&V, et comment cela se reflète-t-il dans 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

Traduction gratuite:

«Dans la gestion de projet, les tests et le développement de logiciels, la vérification et la validation (V&V) est le processus de vérification que le logiciel développé répond aux spécifications et remplit sa fonction prévue. Elle peut également être attribuée au contrôle qualité en général. En règle générale, les ingénieurs de test sont responsables de la vérification et de la validation du cycle de vie du développement logiciel. En termes simples, la vérification du logiciel peut être décrite comme suit: «Supposons que nous devions développer le système X. Avons-nous atteint l'objectif sans bogues ni hypothèses?» Par contre, la validation du logiciel est «Le système développé X est vraiment quelque chose Que voulions-nous obtenir? Le système X répond-il aux exigences de haut niveau? "

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 (SIT), le second en maintenance (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, naturellement pas un tas d'entre eux sont stockés). Dans le cas où l'exigence n'est pas couverte et ne le sera pas, nous expliquons pourquoi.

Quand l'exigence de couverture n'est-elle pas nécessaire?

Par exemple, CFR Part 11 (les règles établies par la FDA concernant les enregistrements électroniques et les signatures électroniques ) contient un grand nombre d'exigences qui sont déjà couvertes par Microsoft et si nous utilisons Windows AD pour l'authentification, nous n'avons pas besoin de les couvrir à nouveau.

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é du 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 Owner, Scrum Master , Chef de projet, analyste commercial, responsable technique, responsable de test SIT, responsable de test UAT, QC global, ingénieur de support, de déploiement et autres.

Notre rôle spécifique est Global QC . Il s'agit de la personne du côté du client, qui est responsable de la conformité aux 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 l'audit externe.

Documentation d'acceptation

Dans le cadre de la version du produit, un package de documentation est créé avec 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 manière et pas autrement, et ce qui a été spécifiquement testé et ce qui a été omis:

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

Stratégie de test - un document qui ne s'applique pas à une application spécifique, mais qui est créé pour une branche de produit distincte ou pour une branche de test distincte. Par exemple, comment et pourquoi nous déterminons ce que nous automatiserons et ce qui ne le sera pas; quelles technologies; comment nous organiserons les tests manuels (listes de contrôle ou scripts de test, ou les deux ensemble, ou quelque chose de complètement différent); comment nous décidons si nous conduirons la charge ou non; et ainsi de suite et ainsi de suite.

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 fonctionnalité.

Matrice de traçabilité - tracez la matrice de l'exigence au test. Le traçage 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 la satisfaction de cette exigence est confirmé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 a été formellement couverte). 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 requis de vous. 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 déposer une base de données primitive de trois tables.

PDS - Product Design Specification, un document développé par un conseiller technique ou un architecte de projet, essentiellement une combinaison d'architecture d'application de haut niveau et de bas niveau (HLA et LLA).

FRS & URS ou BRS sont des exigences fonctionnelles et utilisateur, généralement sous la forme de deux documents distincts, mais parfois combinés dans la spécification des exigences commerciales.

Journal des défauts - un journal des défauts détectés pendant les tests (défauts et exigences de l'application).

Journal des problèmes mineurs - un journal des erreurs mineures dans les tests (fautes de frappe, exigences manquantes / inutiles, etc.) - toutes les erreurs qui ne modifient fondamentalement pas la signification du test).

Rapport de synthèse des tests - rapport sur les résultats des tests. TSR est le document de clôture du plan de test et contient:

• Informations sur les assemblys qui ont été testés (y compris les numéros de build et les dates de déploiement), le nombre de cycles de test et les résultats des tests.
• Description des violations commises concernant le plan de test et les procédures de test (SOP) approuvés pour exécution par l'entreprise.
• Liste des défauts ouverts expliquant les raisons du transfert vers la prochaine version.
• Lien vers le journal des défauts ou le journal lui-même.
• Un lien vers le journal des erreurs de test ou le journal lui-même.
• Une recommandation de décision d'installation en production.

Plan de déploiement - un document dont le support et l'intégration sont responsables, est compilé lors des installations sur l'environnement SIT et est ensuite utilisé pour déployer la version en production.

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

Approbation du document

Tout processus d'approbation de la documentation est conditionnellement divisé en 3 étapes:

• Préparation du document.
• Revue
• Déclaration.

Prenons l'exemple de Test Suite.

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.

Les composants du kit de test:

• Le nom du projet et de l'application.
• Version de sortie.
• Le nom et l'identifiant unique de l'ensemble.
• Description (ce que nous testons, quels types de tests nous utilisons).
• Tests.
• Liste des approbateurs.

À son tour, chaque test comprend:

• Nom et identifiant unique dans l'ensemble.
• La description
• Conditions préalables.
• Postconditions.
• Traçage (numéros d'exigences couverts par le test).
• Caractéristiques d'exécution (par exemple, instructions pour masquer les données sensibles).
• Étapes (actions requises, résultats attendus et réels).
• Le résultat du test.
• Accompli.
• Revuever.

Le cycle de vie normal d'un test ressemble à une cascade de rétroaction et ressemble à ceci:

1. Orthographe
   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. Test passage / passages sur vierges
   À ce stade, il est évalué dans quelle mesure l'application répond aux exigences, et la plupart des bogues possibles, y compris les bogues d'exigences, sont éliminés.
3. Examen du chef de projet (chef d'équipe SIT)
   Revue stylistique et logique.
4. Test de passage / passe sur l'environnement SIT
   À ce stade, les erreurs associées à l'installation, l'environnement et la configuration de l'environnement sont détectées (par défaut, on pense que l'environnement SIT est exactement ou presque complètement répété PROD). La réussite de cette étape signifie que la version qui est entouré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 des tests SOP écrits sont en place avec l'entreprise.
6. Approbation (QC global, PO technique, PO d'entreprise).
7. Exécution formelle des tests sur l'environnement SIT (version candidate à la sortie)
   Après l'approbation des tests de passage (p. 6) et la réussite des tests réussis sur l'environnement SIT (p. 4), le test est formellement effectué sur l'environnement SIT avec la fixation formelle du résultat. Si les bogues trouvés sur les passes de test ne sont pas formalisés et 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é sur la passe formelle, qui est inclus dans le package de documentation de sortie du produit.
8. Revue des résultats du passage responsable du projet (Chef d'équipe SIT).
   De même qu'au point 3, le style de remplissage est vérifié et les résultats sont analysés.
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 confirmations (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., 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 - méthode 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 que nous avons utilisés pour monter nos projets:

Un semblant de plaisir: un globe

Dans l'une des applications pour créer un effet wow et non seulement nous avions vraiment besoin de créer un globe interactif que vous pouvez faire tourner 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 trouvent (comme le 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.

Historique: les données ont été téléchargées dans le référentiel 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 lier 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 devrait s'y trouver, ou réfléchir à l'avance à l'applicabilité du mécanisme d'anonymisation et d'obscurcissement.

Flux de travail électronique vs papier en pratique

Celui qui a travaillé avec HP ALM ne rit pas du cirque.

La gestion électronique des documents 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 pas un épuisement dans le temps dans le contexte du temps de préparation des tests et de leur 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.

Avantages:

• Il est facile de maintenir la dernière version à jour.
• Moins fait à la main.
• Tous les membres de l'équipe ont à tout moment accès à l'état actuel d'un test particulier.
• Changer l'historique.
• Historique des passages.
• Vous pouvez suivre le temps nécessaire pour terminer le test.
• Il est plus facile de prévoir du temps pour d'autres passes.
• Nous devons essayer d'utiliser la mauvaise version du test pour le passage.
• Signature électronique.

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

• Beaucoup de temps est consacré aux tests de formatage.
• Problèmes périodiques avec l'outil lui-même.
• Absence d'un correcteur orthographique normal.
• 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.

Étude de cas liée à la paperasse et aux signatures manuelles: «Le cauchemar avant la libération»

Pour un soir, j'ai écrit 450 fois, "la couleur des points sur le graphique correspond à celle indiquée dans les conditions, le nom de famille est le nom de la date" et j'ai apposé une signature - simplement parce que nous avons imprimé sur une imprimante n / b, et la couleur des points sur les graphiques importait.



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

Deuxième histoire: «La gravité est bonne, la gravité est fiable»

Le flux de travail papier est du papier (qui en douterait). Pour la réception d'une application loin de la plus importante, elle peut s'avérer de l'ordre de cinq kilogrammes.



La conclusion qui se dégage des histoires ci-dessus (et de nombreuses inédites): malgré les inconvénients énumérés et non répertoriés de la gestion électronique des documents - 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 sur le côté de base) 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 - parce qu'elle est utilisée de manière incorrecte, pas là, et pas pour ça, mais c'est un sujet pour un rapport séparé, dont il y a un peu moins que "l'automatisation doit avoir !!!" ", Mais toujours en quantité.

La seconde consiste à 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 pour une raison.

Troisièmement, et principalement: pour déterminer l'algorithme par lequel nous pouvons consciemment prendre une décision sur 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 à la lumière du processus d'approbation de la documentation décrit ci-dessus en utilisant la suite de tests manuelle comme exemple, il devient clair que le processus d'automatisation ne doit pas être moins contrôlé.

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 vous pouvez configurer 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. Le test des composants * doit-il être automatisé pour être stable?
3. À quelle fréquence devons-nous exécuter des tests écrits pour un composant?
4. Cette fonctionnalité est-elle essentielle 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.
** , -.


:

1. FRS.
   (Design Matrix), — FRS. :
   
   • 1-5
   • Commentaires
2. , / .
3. .
4. Design Matrix . Gherkin , (Global QC, Technical Owner, Business Owner). Step definitions, page objects , . Global QC.

, , data warehouse, , .

Conclusion

, - , . , , , , . , , ?