Architecte de solution de test: qui est-ce et quand est-il nécessaire

Chaque jour, dans le domaine informatique, il y a de plus en plus de nouvelles tâches, y compris dans le domaine des tests. Si auparavant un testeur devait simplement tester en fonction des exigences (ou sans celles-ci), alors maintenant il doit d'abord comprendre comment il peut être testé, quelles technologies sont nécessaires pour cela, ce qui peut être automatisé et comment inclure un cycle de publication dans toute cette honte et etc. Qui devrait répondre à ces questions? Qui communiquera avec le client et clarifiera les exigences? Qui va créer les approches et tester l'architecture, les exigences?

En tant que leader et coordinateur des tests sur des projets pour de grandes entreprises et en résolvant tous ces problèmes en trois ans, j'ai réalisé qu'il est important d'attirer toujours une personne qui répondra à la question principale: "Comment faire des tests?"
J'ai mené une petite enquête et j'ai découvert qu'un tel rôle existe déjà, et il s'appelle Test Solution Architect (TSA), mais peu de gens le savent. Et la description des postes vacants de la TSA sur les sites Web des employeurs étonne par leur liste de tâches et de compétences, mais je pense que cela est probablement dû à un manque de compréhension de l'identité de la TSA.

Sur la base de mon expérience dans ce sens, j'ai décidé de montrer par l'exemple d'un des vrais projets qui est TSA et quand c'est nécessaire.

Brève description du projet

L'objectif du projet était de remplacer une base de données par une autre, plus précisément Cassandra et son appendice sous la forme de FilloDB ont été remplacés par SnowFlake, dans le processus métier d'un flux quotidien, horaire et même minute par minute de livraison et de traitement des données. Il y avait plus de 50 de ces flux, et comme prévu par les architectes, cela était censé résoudre un grand nombre de problèmes liés aux performances, à la perte de données, aux coûts de maintenance et à l'achat de licences supplémentaires pour Cassandra, etc. Mais lesquelles de ces attentes ont été satisfaites et lesquelles ne le sont pas - c'est le sujet d'un autre article.

Quels rôles de test étaient sur le projet?

Historiquement, les rôles suivants ont été distingués dans les tests: un testeur manuel ou un testeur fonctionnel, un outil d'automatisation des tests (celui qui écrit le code et les tests) et un gestionnaire de tests (celui qui résout tous les autres problèmes). Notre projet n'a pas fait exception. Le projet impliquait:

• 1 responsable de test ou responsable de test
• 40 testeurs manuels qui ont travaillé avec des équipes de mêlée (7 équipes)
• 2 développeurs (c'est plutôt une exception, car les développeurs n'aiment pas travailler sur des tâches d'automatisation) et 2 tests d'automatisation
• 2 testeurs qui ont fait des tests de résistance
• 1 testeur fonctionnel pour tester les produits développé par les développeurs et tester l'automatisation

Test manuel

L'objectif principal des testeurs fonctionnels était de tester l'application et de dire si elle répond aux exigences du client. Pour cela, les testeurs:

1. Créez des plans de test.
2. Créez une stratégie de test.
3. Créez des cas de test avec des étapes planifiées (avec le résultat attendu et actuel).
4. Effectuer des cas de test et conclure sur la qualité de l'application.

Nous n'avions pas d'exigences clients ni de descriptions de système. Il n'y avait que l'ancien système et le nouveau et le souhait: "Faites-le fonctionner, mais avec une nouvelle base." Par conséquent, nous ne pouvions utiliser que l'approche à périmètre constant - comparer les résultats des anciens et des nouveaux systèmes. Tout était compliqué par le fait que nous travaillions avec un système de production et des données mises à jour quotidiennement. Malheureusement, nous n'avons pas pu démarrer notre système en même temps que le système de production, et nous l'avons démarré plus tard, ce qui a conduit au fait que les données de l'ancien et du nouveau système étaient différentes.

À ce stade, des questions ont commencé à se poser:

1. Comment conclure que notre système a fonctionné correctement si, en raison d'un décalage horaire, nous obtenons des résultats différents de ceux que nous obtenions dans l'ancien système?
2. Peut-on sortir de la production de données et travailler sur des données stables? Quels sont les risques?
3. Et si nous arrivons néanmoins à des données stables, comment prouver que notre système fonctionnera correctement avec des données mises à jour quotidiennement?

Ce n'est que la pointe de l'iceberg de la liste des questions similaires qui se sont posées sur le projet lors des tests fonctionnels / manuels.

Automatisation des tests

Les ingénieurs (et développeurs) d'automatisation des tests avaient pour objectif d'écrire des applications qui pourraient automatiquement tester et / ou faciliter le travail des testeurs fonctionnels:

• auto-tests qui seraient intégrés avec CI / CD;
• les applications qui ont aidé à tester les testeurs fonctionnels;
• et d'autres développements nécessaires aux besoins internes du projet.

Dans le cadre du projet, toutes les applications développées pour les tests auraient dû être un produit distinct qui obéissait à toutes les règles de développement et aurait donc été livré au client. Et, en conséquence, des questions se sont posées:

1. Qui, avec le client, développera des exigences non fonctionnelles pour tester les applications? L'architecte de solution a déclaré que ce n'était pas son travail, car Les SA fonctionnent avec l'application commandée par le client.
2. Qui développera les exigences de fonctionnalité pour tester les applications? Il y a des exigences évidentes, mais il n'en existe pas. Par exemple, devons-nous stocker les journaux de nos applications et les analyser?
3. Qui élaborera l'environnement des applications avec le client et corrigera ces exigences? Par exemple, spécifiquement sur ce projet, il y avait une restriction sur spark 1.4, et cela n'a été découvert qu'après la création de l'application.

Et cela est également loin de tous les problèmes qui se posent sur le projet en termes d'automatisation des tests.

Test Leader, alias Test Lead

Le responsable de test doit organiser les processus de test du projet. Ses fonctions comprenaient la répartition des tâches, la tenue de réunions internes avec les testeurs, l'organisation du travail avec le client (recherche des détails, examen des résultats), etc. Autrement dit, il était concentré sur le processus actuel et la résolution des problèmes / tâches quotidiennes, et non sur l'élaboration des tâches de l'approche, de la stratégie, de l'architecture de test.

Si nous parlons du responsable de test technique, il était en charge des solutions techniques: organiser le développement d'applications pour les tests en tant que processus de création d'un produit logiciel distinct qui obéit à toutes les règles de développement, par exemple, la création de tests unitaires, l'intégration avec les processus CI / CD et etc.

Sur notre projet, ces rôles ont été joués par deux personnes, et chaque horaire ressemblait à ceci:


Dans les deux cas, Test Lead est occupé à travailler sur la stratégie de test déjà choisie, mais personne n'est responsable du choix de la stratégie elle-même, justifiant ce choix au client, l'adaptant aux changements et à d'autres problèmes. Par exemple:

1. Développement d'un plan avec le client pour entrer dans la phase de test d'acceptation par le client (UAT).
2. Étudier les exigences avec le client lorsqu'il est considéré que la fonctionnalité peut être transférée à l'UAT.
3. Etude avec le client des hypothèses de tests sur différents types d'environnements (point très délicat). Puisque généralement l'environnement de test ne correspond pas à la production, toutes les questions liées aux tests sur un autre environnement doivent être résolues avec le client.
4. Étudier avec le client une divergence acceptable de mesures dans divers types de tests. Par exemple, quel résultat un client s'attend-il à voir lors des tests de performances? Peut-être qu'il lui suffira que le système ne fonctionne pas moins bien.
5. La collecte de toutes les métriques possibles en nombre, par exemple, les écarts de données pour ce tableau n'est pas autorisée par plus de 10%, ou le script ne doit pas s'exécuter plus de huit heures.

Qu'est-ce qui ne va pas ici?

Les questions ci-dessus sont généralement posées sur les épaules de Test Lead, mais il existe une approche erronée:

1. On ne leur apprend pas les processus dans lesquels Test Lead doit résoudre tous ces problèmes avec le client. Le plus souvent, un responsable de test expérimenté comprend cela et sait peut-être même comment, mais le plus probable, une partie aussi importante que l'objectif de l'entreprise ou des améliorations spécifiques reste en dehors de la portée de sa compréhension. Par conséquent, des priorités incorrectes peuvent être définies.
2. Le responsable de test entre généralement dans un projet lorsque le développement est déjà en cours ou commence tout juste, c'est-à-dire il est confronté aux conditions qu'il existe déjà certains accords ou même que tout a déjà été fixé. Il est heureux que SA soit une personne suffisamment expérimentée et compétente et se dirige vers les tests - cela aidera à adapter les accords initiaux avec le client aux besoins des tests. Dans un autre cas, le plomb doit réinventer la roue.

Et ce ne sont pas tous les problèmes qui tombent sur Test Lead quand il n'y a pas de TSA.

Alors, qui est ce TSA et pourquoi est-il nécessaire?

Test Solution Architect est une personne qui considère la tâche du point de vue des affaires, de l'information et de la technologie, coordonne et développe les exigences avec le client, établit une feuille de route avec des délais et développe des solutions au niveau de l'interface.

Les projets imposent désormais d'autres conditions. Les projets sont devenus plus grands, plus compliqués en termes techniques et de processus, peuvent couvrir plusieurs industries et technologies. Les tests sont devenus non seulement un service, mais aussi un fournisseur (développeur) de logiciels pour le client. Par conséquent, lors des tests, il est nécessaire de mettre en évidence un rôle similaire. De plus, cette personne doit entrer dans le projet avec SA, qui est impliquée dans l'application de production, et commencer à travailler sur tous les problèmes en même temps.

Plus précisément, sur notre projet, le rôle de TSA a été joué par Test Lead, qui a rejoint le projet 3 mois après le début du développement, ce qui a nécessité beaucoup de travail supplémentaire sur l'harmonisation des exigences et des environnements, définissant la vision des résultats des tests finaux du client. En conséquence, le projet n'a pas respecté les délais pendant la majeure partie de sa durée de vie et les clients n'étaient pas satisfaits des fournitures et du résultat du test. Non pas parce que le travail a été mal fait, mais parce que le résultat produit par l'équipe n'a pas répondu aux attentes du client.

Quand le TSA n'est-il pas nécessaire?

Il est clair qu'un tel rôle n'est pas nécessaire dans tous les projets. Ci-dessous, je propose la manière la plus simple de déterminer le besoin de TSA sur un projet, en fonction de la façon dont le client voit l'approche de test.

Le premier type de projet - le client donne le réglage des processus de test à la discrétion de l'entreprise qu'il a embauchée.

Dans ce cas, le TSA entre dans le projet à partir du moment où il commence à travailler avec lui, développe les exigences de test, élabore un schéma de test de haut niveau, décide de ce qui sera automatisé / développé en tant qu'applications distinctes, détermine les exigences pour ces applications et, bien sûr, coordonne avec le client, priorise les objectifs du projet conformément aux attentes de l'entreprise.

Le deuxième type de projet - le client a sa propre compréhension des tests, une image claire et des processus rationalisés.

Dans ce cas, la TSA peut ne pas être nécessaire; les tests ne sont nécessaires que pour s'adapter à l'image existante du monde et la soutenir. Mais si la compréhension est superficielle, le TSA doit non seulement effectuer toutes ces actions comme pour le premier type de projets, mais aussi prouver au client que tout cela est nécessaire.

Le troisième type de projet - le client n'a pas besoin des services TSA.

Les raisons peuvent être différentes:

1. Un petit projet à court terme avec des fonctionnalités simples.
2. Le client a son propre TSA.
3. Le client a refusé de tester, etc.

Compétences TSA

La pratique de Solution Architect est appliquée avec succès en développement depuis très longtemps. Sur la base de cette expérience réussie, et en tenant également compte du volume et de la complexité des projets, des questions qui dépassent le domaine de responsabilité du responsable de test, nous pouvons dire que mettre en évidence le rôle de la TSA est un développement naturel des événements. De plus, le TSA doit être formé aux mêmes processus, techniques et approches que le SA.

En bref, à mon avis, la TSA devrait avoir:

1. Avec des connaissances techniques, à la fois en général et dans le domaine où il travaille, pour connaître les problèmes de ce domaine, les erreurs typiques, les problèmes et les moyens de les vérifier.
2. Bonnes compétences en communication, être capable d'attirer l'attention du client sur les problèmes de test, d'élaborer les exigences de test, les approches de test, les rapports de test et de nombreux problèmes connexes, tels que l'environnement de test.
3. Compétences en leadership et être proactif parce que Les tests essaient très souvent de partir pour plus tard.
4. Bonne connaissance des tests en général, de la documentation des tests, des processus de test, des rapports de test, des approches, etc.
5. Bonne connaissance des règles de développement logiciel: politiques de publication, politiques de version, compréhension des processus CI / CD, etc.

Sur la base de ce qui précède, TSA devrait avoir les mêmes connaissances que SA, mais se concentrer sur les tâches consistant à fournir au client un produit de qualité. Le travail de la TSA est compliqué par le fait qu’il est souvent nécessaire de changer l’opinion du client sur les tests comme exclusivement sur la cuisine interne du projet.

Ce sont précisément les connaissances que j'ai reçues à l'école Solution Architect qui m'ont permis de restaurer la confiance des clients sur le projet décrit ci-dessus, de résoudre de nombreux problèmes de test et de terminer avec succès la livraison de toutes les fonctionnalités presque à temps, ainsi que d'établir des processus et de signer des contrats pour les travaux futurs.

Conclusion

L'industrie informatique se développe, de nouvelles tâches apparaissent (défis si vous voulez), et dans le cas des tests, la position TSA mise en évidence est devenue urgente. Naturellement, tout dépend du projet, mais dans les projets où un CST est nécessaire, vous devez vous engager dans le travail au tout début, cela évitera des problèmes à l'avenir et aidera au développement du projet.