À mesure que l’adoption de l’automatisation de la qualité de contenu (QA) se développe au sein d’une organisation, un nouvel problème apparaît qui n’a rien à voir avec l’écriture de tests. Une équipe de plateforme met en place l’automatisation des tests, puis une autre équipe veut rejoindre, puis encore une dizaine d’autres. Bientôt, des centaines de cas de tests appartiennent à différents produits et équipes, et tout le monde peut voir les tests des autres. Personne ne peut répondre à une question simple : la couverture de tests de cette application est-elle saine en ce moment ? L’écriture des tests ne constitue plus le goulot d’étranglement. Organiser les tests et contrôler qui peut les toucher constitue le travail.
Une deuxième question liée suit immédiatement : qui possède cette application et ses tests, et qui est responsable lorsque la couverture tombe ? Sans un propriétaire clair, les problèmes de santé n’ont personne sur qui compter.
Dans le premier post, nous avons présenté QA Studio, une solution de référence créée avec Amazon Nova Act. Les équipes l’utilisent pour définir des tests en langage naturel et les exécuter via une navigation visuelle alimentée par l’IA. Dans le deuxième post, nous avons ajouté des suites de tests et une CLI pour les tests de régression en batch dans les pipelines de intégration continue et de livraison continue (CI/CD). Dans cet article, nous abordons deux fonctionnalités qui permettent à QA Studio de s’étendre au sein d’une organisation. La première, applications, organise les tests et fournit des indicateurs de santé. La seconde, gestion des utilisateurs basée sur l’équipe, contrôle qui peut voir et modifier quoi.
Organiser les tests avec des applications
Une application dans QA Studio représente le système à tester : un site web, une application web, un front end de service. C’est le conteneur qui fournit une collection d’tests, un habitat et un propriétaire. Les cas d’utilisation (les tests individuels de la Part 1) et les ensembles de tests (les collections de régression de la Part 2) appartiennent à une application, et ils héritent de sa propriété. Au lieu d’une liste unique de tous les tests dans la déploiement, chaque équipe travaille au sein des applications qu’elle possède.
Créer une application nécessite un nom, une URL de base et un ensemble d’environnements optionnels tels que le développement, le staging et la production. Depuis la page de l’application, les équipes créent de nouveaux cas d’utilisation directement dans le contexte actuel, ajoutent ceux existants et les regroupent en salles de test. C’est également là que QA Studio rapporte l’état des tests qu’il exécute.
Figure 1 : La page de détail de l’application, montrant le taux de succès, les exécutions et les échecs, avec les onglets des cas d’utilisation et des ensembles de tests
Comprendre la santé de l'application à l'aide de métriques
Les tests produisent des résultats. Comprendre ces résultats au fil du temps indique à l’équipe si le cycle de vie de développement d’une application est sain, et non seulement si une build est prête pour la sortie. QA Studio enregistre le résultat de chaque exécution sous forme de métriques personnalisées Amazon CloudWatch, classées par application et par environnement. Ces métriques sont transformées en une vue de santé sur la page de l’application.
Le haut de la page répond à la question immédiate avec trois chiffres : le taux de succès pour la fenêtre sélectionnée, le nombre total d'exécutions, et le nombre de échecs actuel. Parallèlement, QA Studio calcule un score de santé de 0 à 100. Le score commence par le taux de succès et soustrait une pénalité pour les tests irréguliers. De cette manière, une application dont les tests réussissent mais alternent entre succès et échec ne donne pas une image parfaitement idéale. Une équipe qui examine un portefeuille d'applications peut distinguer les applications stables des applications nécessitant une attention, sans avoir à ouvrir chaque résultat.
La boîte de métriques se déplace du snapshot actuel vers les tendances. Les équipes choisissent une fenêtre de 7 jours avec une granularité horaire, ou une fenêtre de 30 jours avec une granularité quotidienne. QA Studio affiche les exécutions, les succès, les échecs et la durée moyenne pour cette période. Comme les métriques sous-jacentes comprennent une dimension d’environnement, les équipes filtrent la vue vers un seul environnement. Par exemple, elles peuvent comparer le comportement du environnement de test avec celui de production pour le même ensemble de tests.
Deux perspectives ciblent les tests qui consomment le plus de temps pour les équipes. La perspective des tests instables classe les cas d’utilisation en fonction de la fréquence à laquelle ils passent de réussite à échec au cours des sept derniers jours. Cela met en évidence les échecs intermittents qui minent la confiance dans un ensemble de tests avant qu’ils ne deviennent des erreurs en production. La perspective des échecs récents liste les dernières exécutions échouées pour une triage rapide. Chacun d’eux est lié aux journaux de trajectoire et aux enregistrements de session du Amazon Nova Act décrits dans la Part 1. De cette manière, passer de « ce test échoue » à « voici exactement ce que l’agent a vu » nécessite un simple clic.
Figure 2 : La boîte de métriques : taux de succès, nombre d’exécutions et durée moyenne sur la fenêtre sélectionnée, avec le graphique quotidien des succès et échecs, les points d’échec majeurs et le classement des cas d’utilisation instables
Contrôler l'accès avec Teams et rôles
Les métriques indiquent à l’équipe comment fonctionnent ses applications. La gestion des utilisateurs basée sur l’équipe détermine d’abord quelles applications appartiennent à chaque équipe. QA Studio organise l’accès en fonction des équipes, et une application appartient exactement à une seule équipe. Les membres de cette équipe travaillent avec ses applications. Tout le reste ne les voit pas.
Chaque membre de l’équipe occupe l’un des cinq rôles, et chaque rôle confère les droits correspondant à ceux qui le suivent.
- Administrateur : Accès à tous les équipes, applications et utilisateurs au niveau de l’ensemble du studio, y compris la création d’équipes et l’attribution d’applications. L’administrateur est un rôle au niveau de l’ensemble du studio, et non une attribution par équipe.
- Chef d’équipe : Gère les membres de son équipe et crée des applications pour l’équipe.
- Éditeur : Crée et modifie les cas d’utilisation et les ensembles de tests dans les applications du groupe.
- Executor : Exécute les cas d'utilisation et les suites, mais ne les modifie pas.
- Voyeur : Accès uniquement pour lecture aux applications et résultats de l’équipe.
Comme les rôles sont cumulatifs, un Chef d’équipe possède tout ce que possède un Éditeur, et ainsi de suite jusqu’au Voirable. L’accès à un cas d’utilisation ou à un ensemble de tests dépend de l’application qui le contient. Si un membre peut travailler avec l’application, il peut également travailler avec ses tests, en fonction de son rôle. Cela permet de gérer les permissions au niveau de l’application, plutôt que sur des milliers de tests individuels.
Un administrateur voit tout le studio. La page Utilisateurs liste chaque compte avec son équipe et son rôle en un seul endroit. Un administrateur peut déterminer qui occupe le poste de Chef d’équipe dans quelle équipe, et qui dispose des droits d’administrateur à l’échelle du studio. Dans la déploiement de référence présenté ici, quatre utilisateurs appartiennent à deux équipes : deux chefs d’équipe, un visiteur et un administrateur à l’échelle du studio. La page Équipes présente les mêmes données par équipe, montrant le nombre de membres et le nombre d’applications pour chaque équipe côte à côte. Un administrateur peut voir quelles équipes se développent avant d’ouvrir l’une d’entre elles.
Figure 3 : La page des utilisateurs à l’échelle de tout le studio : chaque compte avec son équipe et son rôle, filtrables par équipe et par rôle
Les mêmes données de membre, regroupées par équipe, apparaissent sur la page Teams.
Figure 4 : La page Teams : chaque équipe avec ses membres et le nombre d’applications
En passant des équipes aux applications, la liste des applications à l’échelle du studio montre chaque application dans toutes les équipes.
Figure 5 : La liste des applications au sein du studio : chaque application avec son URL de base, l’équipe qui la gère, le nombre de cas d’utilisation et l’état de dernière exécution
Partage des applications entre les équipes
Les équipes travaillent rarement en isolation complète. Une équipe de plateforme peut posséder une application dont une équipe de fonctionnalités a besoin pour la tester, sans donner les droits de modification. QA Studio permet cela grâce à un accès partagé : l’équipe propriétaire donne à une autre équipe l’accès à l’application au niveau vue, exécution ou complet.
L’accès partagé suit une règle de plafond. Les permissions effectives d’un utilisateur sur une application partagée sont inférieures à la valeur de son propre rôle et au niveau d’autorisation accordé. Un visiteur qui reçoit un accès complet à une application partagée reste uniquement en mode visualisation, car son rôle constitue le plafond. De cette manière, l’équipe propriétaire peut partager largement sans accorder plus que ce que le rôle du destinataire permet.
Quelle équipe de direction voit
Un chef de projet travaille au sein d’un seul groupe plutôt que dans tout le studio. L’ouverture de « My Team » présente quatre onglets qui couvrent tout ce que le chef de projet contrôle : Membres, Applications, Cas d’utilisation et Accès partagé. L’onglet « Membres » liste les personnes présentes dans le groupe. Le chef de projet peut modifier le rôle de n’importe quel membre en direct ou en ajouter un nouveau, afin que la gestion des accès quotidiennes reste entre les mains de la personne la plus proche du travail. Dans le groupe AWS montré ici, le chef de projet gère deux membres : un chef de projet et un visiteur.
Figure 6 : La feuille Membres du chef d’équipe, avec l’attribution des rôles pour chaque membre en ligne
La tablature « Applications » montre uniquement les applications que l’équipe possède, chacune avec le nombre de cas de test et l’heure de dernière exécution. Cela permet au responsable de se concentrer sur sa propre application plutôt que sur l’ensemble du stock de l’établissement. La tablature « Shared Access » est où la partage entre équipes devient concrète. Ici, l’équipe AWS a accordé à l’équipe AMZN l’accès à une application, et le responsable peut accorder, révoquer ou modifier le niveau de cet accès. Comme le financement était de niveau de visualisation, l’éditeur d’équipe AMZN voit toujours l’application partagée en lecture seule : la règle de plafond de la section précédente est appliquée en pratique.
Figure 7 : La tablature Applications du chef d’équipe, ciblée sur les applications propres à l’équipe
La même tabulation de l’onglet Accès partagé du chef de équipe indique aux autres équipes à quelles applications de l’équipe elles peuvent accéder, et au niveau de cette accès.
Figure 8 : La tabulation « Accès partagé » du chef d’équipe, montrant une subvention au niveau de la vue pour une autre équipe
Comment cela fonctionne
QA Studio crée un contrôle d’accès basé sur l’équipe et des indicateurs sur la même base sans serveur décrite dans les articles précédents, en ajoutant quelques services AWS à la mix :
- Amazon Cognito: Chaque équipe est associée à un ensemble de groupes Cognito, un pour chaque rôle. Un AWS Lambda autorisateur transforme les groupes du appelant en scopes API et en contexte d’équipe à chaque requête.
- Amazon DynamoDB: Les équipes, les membreships, la propriété des applications et les bourses de partage entre équipes sont stockés dans le design de table unique existant.
- Amazon CloudWatch : Chaque exécution génère des métriques personnalisées dans le nom de domaine QAStudio/Executions, selon l’application et l’environnement. La API de métriques les récupère pour créer une vue de santé et des graphiques de tendance.
- AWS Lambda et Amazon API Gateway : Le backend impose l'accès à deux niveaux : le champ de compétence accordé par le rôle du appelant, et un contrôle des ressources qui vérifie que l'équipe du appelant est propriétaire ou a été partagée avec l'application.
Comme l’accès dépend de l’appartenance au groupe Cognito, le flux de identifiants clients OAuth issu de la Partie 2 s’applique également à ce modèle. Une pipeline CI s’authentifie en tant qu’identité machine avec les droits nécessaires, et rien d’autre.
Commencer
Les applications, les métriques et le contrôle d’accès basé sur les équipes font partie de la solution de référence de QA Studio, que vous déployez dans votre propre compte AWS avec le AWS Cloud Development Kit (AWS CDK). Tous les données de test, les résultats et les métriques restent dans les limites de votre compte. Après le déploiement, un administrateur crée des équipes, attribue des membres et des rôles, et assigne des applications aux équipes. Les métriques de santé de chaque équipe commencent à se remplir lorsque leurs tests sont exécutés.
Pour les instructions de déploiement et les détails de configuration, veuillez consulter le répertoire GitHub du QA Studio ainsi que sa documentation.
Conclusion
Dans cet article, nous avons montré comment QA Studio scale l’automatisation de la qualité de service à partir de tests individuels jusqu’à une organisation entière. Les applications offrent à chaque équipe un espace pour leurs cas d’utilisation et leurs ensembles de tests. Elles indiquent l’état de santé des équipes via le taux de réussite, les graphiques de tendance, un score de santé ajusté pour les échecs, ainsi que une triage des échecs basé sur les métriques Amazon CloudWatch. La gestion des utilisateurs par équipe, soutenue par Amazon Cognito, permet à chaque équipe de fonctionner dans les applications qui leur appartiennent, avec un partage inter-équipes limité par une règle de plafond claire.
Ces capacités s’appuient sur l’écriture de tests en langage naturel de la Partie 1 et sur l’intégration de suites et de CI/CD de la Partie 2. Ensemble, elles permettent à l’automatisation des tests QA à se développer dans de nombreuses équipes sans perdre la visibilité ou le contrôle. Pour l’essayer dans votre propre environnement, déployez la solution de référence du repository GitHub de QA Studio, créez votre première équipe et application, et exécutez quelques cas d’utilisation pour observer les indicateurs s’affiner. Pour en savoir plus sur l’agent qui se cache derrière tout cela, consultez la page produit Amazon Nova Act.