En ce qui concerne les tests de logiciels, deux termes importants entrent en jeu. Ce sont « Plan de test » et « Stratégie de test ».
Bien que les deux soient des éléments essentiels du processus de QA, ces termes risquent souvent être mal interprétés et utilisés de manière interchangeable.
Alors, quelle est la différence entre un plan de test et une stratégie de test ? Quand devez-vous utiliser un plan et quand est-il préférable d’utiliser une stratégie ?
Le paysage concurrentiel actuel est en évolution rapide, caractérisé par l’arrivée de nouveaux acteurs dans des domaines d’activité établis, l’évolution des besoins des utilisateurs et l’introduction de nouvelles technologies à un rythme très rapide. La plupart des organisations ne peuvent suivre ce rythme et l’agilité organisationnelle est une capacité essentielle pour votre réussite.
Les leaders sont souvent désireux de comprendre l’impact de l’adoption de méthodes de travail agiles et, dans cet article, nous explorons 5 indicateurs clés qui aident les leaders à suivre l’amélioration des équipes et des produits dans l’ensemble de l’organisation. Ces métriques sont d’excellents indicateurs pour ouvrir la voie à l’innovation, à la résilience et à une croissance soutenue.
#1 – Fréquence de livraison (de sortie)
Une mesure de la fréquence à laquelle une organisation délivre des mises à jour de son ou ses produits est l’un des principaux indicateurs du développement de ses capacités d’agilité business. Les approches agiles telles que Scrum aident les organisations à livrer fréquemment de la valeur aux utilisateurs. Avant même qu’un produit ne soit construit, la valeur qu’il apporte à ses utilisateurs cibles est estimée et les organisations valident les hypothèses lorsque le produit est finalement mis à la disposition du client. Une organisation dont la fréquence de sortie est plus rapide recueille potentiellement plus fréquemment les commentaires de ses utilisateurs.
L’organisation doit s’efforcer d’augmenter la fréquence de mise sur le marché de ses produits au fil du temps. Une fréquence de sortie plus élevée améliore l’agilité de l’entreprise en permettant une innovation plus rapide, une réactivité aux besoins des clients et une adaptabilité aux changements du marché.
Il y a un certain nombre de facteurs que nous pourrions prendre en compte pour augmenter la fréquence de sortie de ses produits :
Tests fonctionnels et non fonctionnels automatisés.
Amélioration des capacités de management de produits, y compris la capture et l’analyse des commentaires des utilisateurs.
Créer des équipes inter-fonctionnelles dans le cadre des efforts de conception de l’organisation.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
#2 – Incidents par période
Les équipes produit sont responsables de la livraison de produits utilisables à leurs clients et les incidents, lorsqu’ils se produisent, nuisent à la convivialité de vos produits. Les incidents font référence aux temps d’arrêt du produit, aux pannes du produit et aux défauts non détectés du produit, entre autres. Les leaders doivent encourager et soutenir l’équipe produit afin de réduire le nombre d’incidents rencontrés par les utilisateurs par période. Les entreprises doivent investir dans des capacités techniques qui permettent de capturer automatiquement ce type de problèmes à partir des relevés d’incidents et, en outre, de fournir aux utilisateurs un moyen de signaler ces problèmes.
Les entreprises gagnent beaucoup de bonne volonté de la part de leurs clients si ces problèmes peuvent être détectés et corrigés avant qu’ils ne soient visibles par les utilisateurs. Pour s’assurer qu’un produit conserve sa valeur pour ses utilisateurs, le nombre d’incidents par période doit avoir tendance à diminuer au fil du temps.
Voici quelques facteurs qui pourraient contribuer à réduire le nombre d’incidents par période :
Capturez la dette technique en tant qu’éléments de premier ordre de l’arriéré de produit.
Augmentez les tests automatisés autour des fonctionnalités sujettes aux incidents.
Obtenez l’engagement de l’équipe produit à réduire la dette technique sur une période donnée.
Améliorez les capacités d’analyse des logs des utilisateurs pour repérer les problèmes potentiels.
La construction d’un produit est coûteuse et jusqu’à ce qu’un produit soit mis à la disposition de ses utilisateurs, le budget dépensé jusque-là pourrait être assimilé à un « stock d’invendus » comme dans le cas d’une entreprise traditionnelle.
Le délai d’exécution est le temps écoulé entre l’idée et le produit fonctionnel entre les mains du client.
Souvent, l’équipe produit trouve qu’il est plus facile de mesurer le temps de cycle, c’est-à-dire le temps écoulé entre le moment où une tâche est en cours et le produit entre les mains du client. Le temps de cycle peut être mesuré à la place du délai d’exécution, mais en fin de compte, l’équipe produit doit améliorer son système de management du backlog (l’arriéré de produit) pour calculer le délai d’exécution.
Il convient de souligner que l’effort visant à augmenter la fréquence de livraison devrait réduire le délai d’exécution. Cependant, la mesure et la visualisation du délai d’exécution apportent une valeur ajoutée à part entière.
Les facteurs qui améliorent les délais sont les suivants :
Réduire et, éventuellement, éliminer les temps d’attente dans le système.
Dans notre travail avec les clients, nous avons observé que les leaders n’accordent pas suffisamment d’attention à une mesure très importante : Le niveau de satisfaction des personnes qui font réellement le travail. Il semble que les leaders supposent au fil du temps que les employés qui ne montrent pas de signes visibles d’insatisfaction doivent certainement être heureux et notre travail a montré que ce n’est certainement pas le cas
Les employés qui ne sont pas satisfaits au travail et ont des niveaux de moral en baisse ne sont pas en mesure de fournir des produits de valeur que les utilisateurs adorent. Lors d’un récent engagement de transformation de l’organisation où nous avons remarqué que le moral des employés était en baisse, les leaders avaient demandé à l’équipe d’augmenter la fréquence des livraisons et de réduire le temps de cycle, mais les équipes ne pouvaient pas améliorer ces mesures sans l’adhésion des leaders à la prise de certaines décisions qui impliquaient d’investir dans l’automatisation et de restructurer les équipes. Les leaders ont également supposé qu’il était facile pour les équipes de s’améliorer. La seule façon d’obtenir l’engagement des leaders a été de mener une enquête sur la satisfaction des employés, qui a donné des résultats négatifs.
Nous avons pu cocréer un certain nombre d’initiatives avec les équipes produit, notamment :
Des méthodes de travail qui ont donné de l’autonomie et du sens aux équipes.
Le leader s’est engagé à financer des changements d’infrastructure afin de réduire la durée des cycles et d’augmenter la fréquence des livraisons.
Les employés engagés et heureux sont plus susceptibles d’accepter le changement, d’apporter des idées innovantes et de collaborer efficacement, alimentant ainsi l’agilité et le succès de votre organisation.
#5 – Satisfaction du client
Il faut beaucoup de travail pour créer des produits qui apportent continuellement de la valeur à leurs utilisateurs et les organisations capables de créer des produits de valeur peuvent s’attendre à ce que la satisfaction des clients s’améliore au fil du temps.
Les 4 indicateurs : Fréquence de livraison, Incidents par période, Délai d’exécution et Satisfaction des employés, contribuent tous à améliorer la satisfaction client.
Il existe un certain nombre de techniques qui ont été utilisées pour mesurer la satisfaction des clients, notamment le Net Promoter Score (NPS)et le taux d’attrition des clients.
L’équipe produit peut également envisager le déploiement de données de télémétrie qui fournissent des informations sur les comportements des utilisateurs au sein du produit.
Les mesures de satisfaction client fournissent des informations précieuses sur la façon dont le produit répond aux attentes des clients et va même plus loin. En écoutant activement vos clients et en adaptant vos produits, services et expériences en conséquence, votre équipe produit favorise la fidélité, établit des relations durables et garde une longueur d’avance sur un marché concurrentiel.
Sam Adesoga
Sam Adesoga
Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux :Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’UAT continuera-t-elle à être une pratique pertinente pour les équipes agiles et leurs parties prenantes qui cherchent à créer de meilleurs produits plus rapidement ?
Impact of User Acceptance Testing (UAT) phase on Organisation Agility par Sam Adesoga
Le test d’acceptation par l’utilisateur (User Acceptance Testing / UAT) est une pratique de développement de produits très populaire dans les méthodes traditionnelles de développement de produits. Ces méthodologies traditionnelles sont caractérisées par de longues phases de développement et de déploiement du produit dans un environnement UAT, suivies d’une longue période de test dans l’environnement UAT.
La question est de savoir si l’UAT continuera d’être une pratique pertinente pour les équipes agiles et leurs parties prenantes, en partant du principe que les organisations adoptent des méthodes de travail agiles pour être en mesure de créer de meilleurs produits plus rapidement. La phase d’UAT est une pratique qui est souvent mandatée par les cadres supérieurs au sein de l’organisation et parce que la phase d’UAT ne peut pas s’intégrer dans le Sprint (dans le cas des équipes Scrum), ces équipes contournent l’« obstacle » en modifiant la définition de Done pour leur produit afin d’exclure l’UAT. En d’autres termes, l’équipe Scrum a tendance à modifier son livrable de Sprint pour en faire un produit dont le développement est terminé mais qui n’a pas encore été testé par les utilisateurs et/ou les parties prenantes.
Pour le scénario décrit ci-dessus, quelle que soit la vitesse à laquelle l’équipe Scrum travaille pour amener ses éléments de travail à l’état de développement terminé, l’équipe Scrum crée effectivement un lot de travail qui n’est pas délivré en production avant un certain temps. La phase UAT peut durer de 4 semaines à 3 mois ; et nous pensons que la phase UAT ne rend pas service à tous les efforts visant à renforcer les capacités d’agilité de l’organisation.
Les approches agiles tels que Scrum aident les organisations et les équipes produit à gérer la complexité, et les implémentations de ces approches ne doivent pas introduire de complexité supplémentaire.
Voici quelques exemples de complexité supplémentaire introduite par une pratique distincte de l’UAT et question à se poser :
Comment les équipes corrigeront-elles les défauts détectés pendant la phase d’UAT ?
Cela affectera-t-il la capacité de l’équipe à se concentrer sur le travail de sprint ?
Les défauts seront-ils corrigés par une sous-équipe de développeurs ?
Comment les équipes fusionneront-elles l’incrément de la phase UAT et l’incrément des sprints ?
Chez Valuehut, nous aidons nos clients à intégrer toutes les formes de tests au sein du Sprint (y compris les tests d’acceptation par les utilisateurs) ; La promesse de Scrum est d’aider les équipes à fournir des produits utilisables et précieux à leurs utilisateurs le plus rapidement possible et en renforçant les capacités au sein de l’équipe pour effectuer des tests d’acceptation par les utilisateurs dans le cadre du Sprint. L’équipe a alors plus de chances de fournir un produit précieux et disponible à ses utilisateurs / parties prenantes dans chaque sprint.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Il existe 3 modèles et approches associées que nous avons suivis pour aider les équipes Scrum à éliminer la phase d’UAT de leur méthodologie de livraison de produits.
#1 – Environnements de test qui ne représentent pas l’environnement de production.
Les équipes Scrum qui n’ont pas accès à un environnement de test qui est une représentation de l’environnement de production disposent généralement d’un environnement UAT, qui est partagé par de nombreuses équipes. La non-représentativité peut faire référence à la taille et à la capacité de l’environnement ou à un environnement qui n’est pas configuré correctement avec toutes les applications en amont et en aval.
Pour résoudre ces problèmes, l’équipe doit argumenter en permanence pour avoir un environnement qui représente l’environnement de production. Rendre transparentes pour la direction les implications en termes de coûts qui pourraient être des opportunités perdues en raison de délais de livraison allongés.
#2 – Cas de test et scénarios utilisateurs inconnus.
Souvent, les utilisateurs professionnels qui sont censés exécuter le test d’acceptation utilisateur ont créé un ensemble de scénarios et de cas de test qui n’ont pas été partagés avec les développeurs.
Dans ce cas, l’équipe Scrum devrait plaider pour que ces scénarios utilisateur soient partagés avec l’équipe Scrum en s’associant aux utilisateurs professionnels et en utilisant le coût de la reprise pour répondre à ces scénarios.
#3 – Indisponibilité des données de test dans l’environnement de test.
Dans cette situation, l’entreprise n’est généralement pas confortable avec l’idée de charger des données de test représentatives dans les environnements de test pour un certain nombre de raisons, telles qu’un environnement de test inadapté ou un problème de confidentialité des données.
Les développeurs doivent s’efforcer d’anonymiser les données et de créer des jeux de test qui permettent à l’équipe Scrum d’accéder de manière cohérente à des données de test représentatives.
Élimination de phase d’UAT ?
Il convient de noter que l’élimination de la phase d’UAT prend du temps et nécessite que les équipes Produit s’associent aux leaders de l’entreprise sur une longue période de temps, en effectuant de petites expériences à chaque fois jusqu’à ce que la phase d’UAT soit rendue redondante. La seule façon de rendre la phase d’UAT redondante est de rassembler suffisamment de preuves empiriques qu’aucun défaut n’est trouvé dans cette phase d’UAT ; Cela permet d’établir la confiance avec les parties prenantes au fil du temps, et l’équipe Scrum doit fournir aux parties prenantes la preuve des tests exécutés dans chaque sprint.
La capacité d’agilité organisationnelle aide les organisations à être efficaces (en créant les bons produits, par exemple un produit que les clients aiment utiliser) et efficientes (en construisant les bons produits, par exemple en réduisant les délais de mise sur le marché) ; Par conséquent :
Les organisations qui veulent être compétitives dans un monde complexe doivent repenser des pratiques telles que la phase d’acceptation par les utilisateurs, qui ralentissent le temps total nécessaire pour mettre de nouveaux produits ou fonctionnalités entre les mains de leurs clients.
Sam Adesoga, Principal Coach and Lead Trainer
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.
partagez ce billet avec vos amis, collègues et relations professionnelles
Cet article passe en revue les principales différences entre la qualité interne et externe et insiste sur l’importance d’avoir une philosophie de qualité dans l’environnement Agile.
The importance of having a quality philosophy in the agile encironment
Pour comprendre le vrai sens de la qualité, vous devez faire la distinction entre qualité interne et externe :
La qualité externe fait référence à ce que le client voit lorsqu’il interagit avec le logiciel. Un exemple de mauvaise qualité externe est une interface utilisateur non intuitive qui nécessite une navigation complexe pour utiliser une fonction simple.
La qualité interne fait référence à tous les problèmes non visibles pour le client qui ont un impact sur la maintenabilité et la stabilité du système, tels que la conception du code et la couverture des tests.
Quel type de qualité est le plus important ?
Les deux sont importants, en supposant que l’équipe a le temps, les ressources et les connaissances nécessaires pour s’occuper des deux.
Mais que se passe-t-il lorsque vous devez livrer rapidement et que vous devez en choisir un ?
Il n’y a pas de réponse définitive, car chaque type présente des avantages et des inconvénients. D’expérience, un système de forte qualité interne peut être livré même avec une faible qualité externe (nous voyons cela tout le temps dans l’industrie du logiciel). Cependant, un système de faible qualité interne rendra presque impossible la construction d’une qualité externe élevée. Comment pouvez-vous construire un système qui repose sur des fondations défaillantes ?
Qu’est-ce qu’une philosophie de qualité et pourquoi en avez-vous besoin ?
Dans le cadre de tout projet de développement (Agile ou autre), l’organisation doit déterminer le niveau de qualité qu’elle s’attend à délivrer au marché et à ses clients. Le niveau de qualité doit être dérivé de la philosophie de qualité.
La philosophie de qualité est le niveau acceptable de tolérance du projet pour les écarts de qualité (par exemple, la dette technique, la faible couverture de code, etc.) et les problèmes rencontrés après la livraison des produits.
À chaque extrémité du spectre de la philosophie de la qualité, nous avons une tolérance élevée pour la mauvaise qualité et une faible tolérance pour la mauvaise qualité.
Tolérance élevée pour la mauvaise qualité
L’équipe est censée livrer les produits le plus tôt possible, quelle que soit la qualité des livrables.
Relisez ce billet
Cela inclut la fourniture d’éléments présentant des problèmes de qualité importants (par exemple, les tests ne passent pas, plusieurs bogues sont connus, etc.) et même sans tests terminés. C’est parce que la philosophie de qualité de l’organisation est de battre sur les délais la concurrence à tout prix et de combler les lacunes manquantes par la suite.
Faible tolérance pour la mauvaise qualité
Le livre de Phil B. Crosby
L’équipe est censée livrer des produits sans compromettre leur qualité, qui est censée être au plus haut niveau possible. Pour ce faire, les équipes de développement réduisent le nombre d’histoires utilisateur qu’elles peuvent fournir par version pour créer des infrastructures automatisées, en exécutant plus de tests et en passant une grande partie de leur temps à s’assurer que chaque fonctionnalité est produite avec la meilleure qualité possible.
Flux et vitesse
Comme vous pouvez le constater, la philosophie de qualité organisationnelle affecte considérablement le flux de travail et la vitesse de livraison. Par conséquent, elle doit être communiquée aux équipes d’ingénierie, car elle a un impact substantiel sur leur travail quotidien.
Notez que même si votre entreprise a une tolérance élevée pour la mauvaise qualité, cela ne signifie toujours pas que vous pouvez livrer des produits de mauvaise qualité à vos clients.
Cependant, cela permet à l’équipe de réduire la couverture des tests (d’un montant acceptable), de prendre plus de risques et d’investir moins dans la qualité « externe » car la qualité interne reste non négociable.
partagez ce billet avec vos amis, collègues et relations professionnelles
En ce qui concerne les tests de logiciels, deux termes importants entrent en jeu. Ce sont « Plan de test » et « Stratégie de test ». Bien que les deux soient des éléments essentiels du processus de Quality Assurance, ces termes risquent souvent être mal interprétés et utilisés de manière interchangeable.
Alors, quelle est la différence entre un plan de test et une stratégie de test ?
Le Sprint est l’un des concepts de base de Scrum. En fait, c’est l’un des cinq événements de Scrum (avec Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective).
Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé. Pour le comprendre, vous devez comprendre le but d’un sprint et pourquoi il est timeboxé (réalisé sur une période de temps limitée).
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Désormais, vos équipes ne veulent plus rester assises pour des réunions qui pourraient avoir été un simple courriel. Suivez ces recommandations pour éviter cette erreur.
En plus de compétences techniques reconnues (les tests d’acceptation, boîte blanche, boîte noire, les automatisations de test …), un testeur agile doit avoir de bonnes compétences interpersonnelles.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
L’inquiétude, le stress et l’anxiété ont des effets négatifs sur la productivité et l’efficacité, sans parler de la santé globale et la qualité des relations interpersonnelles. En tant que leader, vous êtes responsable de sauvegarder la santé mentale de vos employés.
Voici quelques domaines de base par lesquels vous pouvez commencer.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Les gens pensent souvent que l’assurance qualité et le contrôle qualité sont identiques.
De plus, ils utilisent souvent l’expression Quality Assurance (QA) pour désigner les tests, mais ce n’est pas exact. Ces expressions sont liées, et il est peut être très déroutant d’essayer de clairement différencier l’assurance qualité (QA), le contrôle de la qualité (QC) et les tests et d’identifier chacune de leurs activités.
Même les gens de ce domaine s’interrogent parfois sur leur intitulé de poste : « Suis-je un testeur de logiciels, un ingénieur QA ou un ingénieur QC ? »
Dans cet article, nous définirons chaque terme et la différence entre eux, et à la fin de celui-ci, vous pourrez aisément répondre à cette question.
Avant de définir ces termes, convenons de la définition de la qualité.
Au sens large, la qualité est la « manière d’être », bonne ou mauvaise, d’une chose ou d’une personne. Dans le langage courant, la qualité tend à désigner ce qui rend quelque chose supérieur à la moyenne.
Le QA , le QC et les tests sont liés dans un concept plus large appelé gestion de la qualité.
La gestion de la qualité comprend toutes les activités qui dirigent et contrôlent une organisation en matière de qualité. Entre autres activités, la gestion de la qualité comprend à la fois l’assurance de la qualité et le contrôle de la qualité ISTQB CFTL.
L’assurance qualité englobe toutes les activités de votre stratégie visant à garantir que les exigences de qualité que vous avez planifiées seront satisfaites au fur et à mesure de la fabrication du produit. Elle intervient à chaque étape du développement logiciel, de la création du cahier des charges à la sortie du produit. L’assurance qualité est la méthode orientée processus et se concentre sur la prévention des défauts.
Le contrôle de la qualité est la phase d’inspection de l’assurance qualité. Dans le processus de développement logiciel, le QC intervient généralement à la dernière étape. Cela commence une fois qu’un produit est déjà construit. Il s’agit d’une série de procédures de test utilisées pour vérifier qu’un produit est sûr et efficace après la production de masse. C’est une méthode orientée produit qui garantit que le résultat final est le résultat attendu ou que le produit final fonctionne comme prévu.
Les tests sont un sous-ensemble du QC. C’est l’activité de détection et de résolution des problèmes techniques dans le logiciel. C’est le processus d’examen du logiciel pour détecter d’éventuelles failles. L’idée de base consiste à exécuter le programme ou le logiciel et à observer le comportement ou le résultat. Il peut fournir un niveau de confiance quant à la convivialité, les performances, la sécurité et la compatibilité du produit.
Expression
Assurance qualité (QA)
Contrôle de la qualité (QC)
Test
Positionnement
Sous-ensemble de SDLC
Sous-ensemble de QA
Sous-ensemble de QC
Orientation
Processus
Produit
Produit
Qui ?
L’équipe projet
L’équipe de test
L’équipe de test
Quand ?
Tout au long du projet
Au stade du test
Au stade du test
Type de
Processus
Prévention
Vérification
Détection
Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées
Voici déjà le cinquième billet de Fidaa sur le domaine des tests.
(Re)Découvrez ses 4 premiers billets
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
En ce qui concerne les tests de logiciels, deux termes importants entrent en jeu. Ce sont « Plan de test » et « Stratégie de test ».
Bien que les deux soient des éléments essentiels du processus de QA, ces termes risquent souvent être mal interprétés et utilisés de manière interchangeable.
Alors, quelle est la différence entre un plan de test et une stratégie de test ? Quand devez-vous utiliser un plan et quand est-il préférable d’utiliser une stratégie ?
Plan de test
Un plan de test est un document formel dérivé des documents d’exigences.
Ce document décrit les différentes actions qui seront effectuées dans le processus de test.
Il définit l’approche, l’estimation, les attentes, les actifs et le calendrier des activités de test planifiées.
Il identifie la portée et l’objectif du processus de test logiciel, les différentes fonctionnalités qui doivent être testées, les techniques utilisées pour concevoir les tests et bien plus encore.
Fondamentalement, il enregistre l’ensemble du processus de planification des tests à effectuer sur le produit.
Stratégie de test
Une stratégie de test est un document de haut niveau décrivant la manière dont les tests seront effectués dans une organisation.
Elle contient un ensemble d’instructions, de lignes directrices ou de principes qui déterminent la conception du test et la manière dont le processus de test sera effectué.
Elle vise essentiellement à fournir une approche systématique du processus de test de logiciels afin d’assurer la qualité, la traçabilité, la fiabilité et une meilleure planification.
Les documents tels que les plans de test tirent leur contenu du document de stratégie de test.
Différence entre plan de test et stratégie de test
Une stratégie de test définit la norme générale pour les activités de test. Un plan de test, d’autre part, définit les détails spécifiques des responsabilités et du processus de QA.
partagez ce billet avec vos amis, collègues et relations professionnelles
Contrairement aux méthodes de gestion de projet traditionnelles, le rôle de testeur dans les projets Agiles dépasse être simplement un exécuteur. Il comprend des activités qui génèrent et fournissent des retours (feedback) non seulement sur l’état du test, la progression du test et la qualité du produit, mais également sur la qualité du processus en collaborant de façon rapprochée avec toute l’équipe et ses parties prenantes.
En plus de compétences techniques reconnues (les tests d’acceptation, boîte blanche, boîte noire, les automatisations de test …), un testeur agile doit avoir de bonnes compétences interpersonnelles.
CSP est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Ayez une attitude constructive et une approche communicative
Une grande partie des problèmes se résument à un manque de communication. En tant que testeur, impliqué du concept au produit final, il est important de communiquer de manière ouverte et honnête. Il est également important de considérer la façon dont nous disons les choses. Il est préférable de dire « Je ne pense pas que cela fonctionne comme il se doit, il manque la fonctionnalité X » au lieu de « Cela ne fonctionne pas ».
Une discussion en face à face est souvent plus efficace.
En outre, il est important de déterminer quand utiliser des outils digitaux pour communiquer ou quand une bonne conversation en face à face est nécessaire.
Coachez les autres membres de l’équipe sur les aspects pertinents du test .
En partageant les connaissances de test avec l’équipe, vous leur montrez que, non seulement vous êtes un apprenant passionné, mais vous voulez les aider à apprendre et à améliorer le travail de l’équipe.
L’objectif d’un testeur n’est pas de trouver plus de bugs mais de construire un produit de valeur et de qualité.
Collaborez avec les développeurs, le Product Owner et les stakeholders pour clarifier les exigences, spécialement en termes de testabilité, consistance et complétude.
Le travail d’équipe rend les choses meilleures. Pour les testeurs de logiciels, travailler seul peut devenir la situation par défaut même si vous faites partie d’une équipe. N’oubliez pas que vous n’êtes jamais seul sur un projet.
Les testeurs doivent être impliqués dans les sessions de Pré-planification et de user stories grooming (analyse détaillée des besoins des utilisateurs) en ajoutant de la valeur lors de la :
Définition des user stories et des critères d’acceptation
Participation aux analyses de risques et de qualité de projet
Création de tests d’acceptation pour les user stories
Participez pro-activement aux rétrospectives d’équipe, suggérez et implémentez des améliorations .
Soyez impliqué, proactif, coopératif et soyez le membre de l’équipe avec qui vous aimeriez travailler. Soyez un modèle de bon membre d’équipe et, espérons-le, les membres de votre équipe le reconnaîtront et travailleront ensemble, avec vous, pour développer des pratiques de travail d’équipe.
Les testeurs Agile doivent ajouter de la valeur à chaque étape de la livraison du logiciel dans un projet agile.
Reportez les défauts et travaillez avec l’équipe pour les résoudre.
Au sein d’une équipe Agile, chaque membre de l’équipe est responsable de la qualité du produit et joue un rôle dans l’exécution des tâches liées aux tests. Le retour d’information dès que possible vers l’équipe en cas de problème économise temps et budget.
partagez ce billet avec vos amis, collègues et relations professionnelles
Notez que même si votre entreprise a une tolérance élevée pour la mauvaise qualité, cela ne signifie toujours pas que vous pouvez 
DantotsuPM.com 