Étiquette : Test

L’importance d’avoir une philosophie qualité dans l’environnement Agile

Le par mopertodans agile, experience sharingLaisser un commentaire

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

https://www.agilequalitymadeeasy.com/post/the-importance-of-having-a-quality-philosophy-in-the-agile-environment-david-tzemach par David Tzemach

Les différences entre qualité interne et externe

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.

TOP 3 d’avril 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de l’été pour partager sur les billets les plus lus depuis le début de l’année, mois après mois.

#1 – Quelle est la différence entre un plan de test et une stratégie de test ? Quand utiliser l’un ou l’autre ? par Fidaa Berrjeb

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 ?

#2 – Avec Scrum, quand un sprint est-il terminé ?

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

#3 – Que vous en soyez conscients ou pas, votre leadership est contagieux !

Voici quelques-unes des façons dont les leaders peuvent s’assurer que la contagiosité de leur leadership ne propage que de bonnes qualités.

Comment ceci s’applique-t-il à votre management de PMO et Portefeuille de Projets (PPM) ?

TOP 3 de février 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de l’été pour partager sur les billets les plus lus depuis le début de l’année, mois après mois.

1 – #5 exemples fréquents de réunions qui auraient pu être évitées par un simple courriel…

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.

#2 – Le rôle et les compétences d’un testeur dans une équipe agile par Fidaa Berrjeb

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.

#3 – Gestion des écarts dans le management de projets

La gestion des variances par rapport à la base de référence de votre projet est une bonne pratique de management de projet.

Voici quelques conseils pour déterminer les écarts acceptables dans la triple contrainte (portée, temps et coût) de votre projet.

 

TOP 3 de janvier 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de l’été pour partager sur les billets les plus lus depuis le début de l’année, mois après mois.

#1 – Comment épater votre Comité de pilotage projet (le « copil » ou Steering Committee) ?

Suivez ces quelques astuces et vous prendrez un bon départ avec votre copil et avec les décideurs les plus seniors sur le projet.

#2 – Voici ce que les leaders devraient faire pour améliorer la santé mentale de leurs équipes

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.

#3 – « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile » par Fidaa Berrjeb.

Dans ce billet, Fidaa explique les 4 valeurs du manifeste agile ainsi que chaque valeur du manifeste de test.

Etes-vous un ingénieur QA, ingénieur QC ou testeur de logiciel ? pa Fidaa Berrjeb

Le par mopertodans experience sharingLaisser un commentaire

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

D’après wikipédia :

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.
  1. « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »
  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
  3. Le rôle et les compétences d’un testeur dans une équipe agile
  4. Quelle est la différence entre un plan de test et une stratégie de test ?

 

Quelle est la différence entre un plan de test et une stratégie de test ? Quand utiliser l’un ou l’autre ? par Fidaa Berrjeb

Le par mopertodans best practices2 commentaires

Voici déjà le quatrième billet de Fidaa pour vous aider à mieux différencier stratégie et plan de test et quand les utiliser.

Redécouvrez les 3 premiers billets Fidaa Berrjeb :
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
  1. « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »
  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
  3. Le rôle et les compétences d’un testeur dans une équipe agile

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.

Le rôle et les compétences d’un testeur dans une équipe agile par Fidaa Berrjeb

Le par mopertodans agile, best practices, experience sharingLaisser un commentaire

Voici le troisième billet de Fidaa pour préciser le rôle du testeur dans les projets Agiles.

Les 2 premiers billets Fidaa Berrjeb que vous souhaiterez peut-être relire :
  1. Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.

    « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »

  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?

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.