Récapitulatif du webinaire: la qualité est-elle le goulot d'étranglement

La bataille pour la qualité dans un cycle de livraison moderne a rendu difficile pour les testeurs de prouver leur valeur. Le stratège de la modernisation et conférencier Jim Holmes a relevé certains des plus grands défis des tests, en les transformant en tactiques qui améliorent la collaboration d'équipe et garantissent le succès du produit.
La qualité compte. Personne n'oserait en discuter. La qualité est et sera toujours une priorité absolue pour toute entreprise et par tout, je veux dire vraiment, tout. La qualité est tout aussi importante pour les entreprises développant des logiciels internes que pour les entreprises fournissant des produits aux utilisateurs finaux. Mais comment l'histoire de la qualité s'applique-t-elle aux niveaux économique et organisationnel, dans le contexte du paradigme numérique en plein essor?
En tant que personne extrêmement passionnée par les tests, Jim a aidé à clarifier les choses concernant le rôle des tests et la valeur que les testeurs apportent dans l'amélioration de la qualité des versions et des produits finaux. Il a expliqué pourquoi les testeurs et les développeurs devraient être proactifs et intervenir à deux pieds lorsqu'il s'agit de comprendre les exigences de l'entreprise et de contribuer aux objectifs et, en fin de compte, de faire un meilleur travail.
Vous pouvez regarder l'enregistrement du webinaire pour prendre connaissance de toutes les informations utiles que Jim a partagées pendant le webinaire.
Same, Same but Different
Beaucoup de choses changent en comment la qualité est comprise dans l'environnement actuel. Nous vivons des temps extraordinaires, poussant les organisations à lutter avec leurs budgets et à lutter contre la pression économique. Dans le même temps, la demande d'expériences numériques exceptionnelles pousse les équipes de livraison à leurs limites.
Le premier endroit à regarder selon Jim est sa propre perspective. Changer de vitesse et commencer à regarder différemment la façon dont votre équipe / organisation expédie les logiciels est probablement la stratégie qui vous mènera le plus loin pour essayer de mieux faire les choses et aider votre organisation à ne plus considérer la qualité comme le goulot d'étranglement.
DX Economies
Nul doute que les expériences numériques (DX) sont un mot à la mode. Pourtant, il y a beaucoup à apprendre des gens DX. Les bonnes personnes DX ont un objectif complètement différent sur la façon de permettre et de permettre à l'utilisateur de faire un meilleur travail. Ils commencent à impliquer les utilisateurs tôt dans le cycle de développement logiciel pour les impliquer avec les résultats et comment ces résultats auront un impact sur leur succès personnel avec le produit ou l'application. De cette manière, l'utilisateur final devient copropriétaire du résultat, ce qui garantit un engagement beaucoup plus fort sur les aspects importants de l'expérience utilisateur numérique.
Les testeurs sont souvent perçus comme des mandataires d'utilisateurs. Devenir un meilleur proxy utilisateur dépend cependant de la capacité des testeurs à répondre aux besoins de livraison de logiciels. Pour s'améliorer à ce niveau, Jim recommande de commencer par acquérir une compréhension très approfondie de ce que vos utilisateurs finaux essaient d'accomplir et des problèmes qu'ils doivent résoudre. Cela augmenterait automatiquement la valeur de votre travail.
En tant que contributeur à votre organisation, vous avez un impact direct sur la façon dont elle peut surmonter tout défi lié à la qualité.
Collaboration à tous les niveaux
La compréhension traditionnelle de la fonction de test implique souvent d'avoir une unité de test distincte plutôt que d'incorporer des testeurs sur des projets mixtes. équipes. Ce qui compte pour l'entreprise, c'est le succès des produits et dans tous les cas, tout est question de collaboration. Le succès passe par des flux de travail ininterrompus qui dépendent de fonctions d'équipe intégrées. C'est la seule approche qui favorise un environnement collaboratif et l'appropriation de ce à quoi devrait ressembler la qualité. Maintenant que le travail à distance et les gens sont parfois à des kilomètres l'un de l'autre, la collaboration est plus importante que jamais.
Que reste-t-il inchangé?
L'idée que les testeurs peuvent tout tester et automatiser 100% des cas de test peut souvent être une attente perçue – mais c'est rarement la réalité. Bien qu'une des questions les plus entendues soit toujours «Combien de temps avez-vous besoin de tester?», Cela ne répond pas nécessairement aux attentes réelles des parties prenantes. Mais cela met en effet beaucoup de pression sur les testeurs et parfois sur des équipes de livraison entières.
«La communication est la clé», soutient Jim, et il explique que les testeurs doivent comprendre quelles sont les tâches les plus importantes pour garantir le bon fonctionnement des fonctionnalités critiques. «Les équipes surchargées et surchargées ne fournissent pas une bonne valeur.» S'accorder sur ce qui est important et se concentrer sur cela aidera à éviter les cas extrêmes de faible valeur, à réduire le gaspillage dans le processus, à offrir une visibilité sur le risque par rapport à la valeur et surtout , cela permettra aux testeurs de s'assurer qu'ils ne contribuent pas aux goulots d'étranglement en se concentrant sur les tâches de faible valeur.
La duplication des efforts est un autre gaspillage important que les équipes doivent constamment travailler à réduire. Nous voyons souvent cela dans les efforts de qualité où les testeurs sont dans des équipes distinctes des développeurs et des analystes commerciaux. Outre les retards inutiles dans les transferts causés par une mauvaise communication et collaboration, des équipes de test distinctes dupliquent le travail de test déjà effectué par les développeurs.
Par exemple, des équipes de test distinctes ne savent pas quels tests unitaires ou API les développeurs ont pu créer au cours de leur travail. Cependant, il se peut que ceux-ci couvrent déjà des fonctionnalités qui n'ont pas besoin d'être vérifiées par un autre ensemble de tests de bout en bout créés au niveau de l'interface utilisateur.
La pyramide des tests est un bon modèle pour illustrer cela. Se concentrer uniquement sur le test unitaire, qui est parfois l'approche typique du développeur, prend en compte les risques pour les objectifs de l'entreprise, car les tests unitaires ont une faible valeur en eux-mêmes. Si votre produit dépend de transactions commerciales effectuées via l'interface utilisateur, vous devriez plutôt vous concentrer sur les tests visuels les tests exploratoires, les tests de bout en bout et les approches qui valident l'interaction de votre utilisateurs avec votre interface utilisateur. Encore une fois, une combinaison de compétences d'équipe et de fonctions d'équipe intégrées est la clé.
Les testeurs sont les courtiers en information du cycle de livraison moderne
«Les testeurs n'assurent pas la qualité» car ils ne recherchent pas de budgets, ne fixent pas de délais et n'allouent pas de personnes, de ressources, et infrastructure. C’est entre les mains des parties prenantes. Et pourtant, cela ne signifie pas que les testeurs (et les développeurs) ne devraient pas être co-responsables de la qualité. En fait, les pratiques de test modernes ne limitent pas la fonction de test à un rôle particulier de l'équipe. Les chefs de projet, les analystes commerciaux et les développeurs sont tout aussi importants en tant que contributeurs à la qualité.
L’essentiel ici est de mieux comprendre comment les parties prenantes pensent et de les impliquer tout au long du processus. À long terme, cela aidera à changer la perception selon laquelle la qualité et les tests sont un centre de coûts fixes. «Les testeurs devraient être considérés comme des courtiers en information plutôt que comme des gardiens de porte» . Ils devraient être chargés de fournir des informations essentielles aux parties prenantes afin de prendre des décisions plus éclairées.
Un participant au webinaire travaillant en tant que chef de projet logiciel a posé une question très pertinente liée à la gestion des attentes.
«L'équipe de test doit-elle utiliser une liste de bogues pour informer la partie prenante qui décide d'expédier ou non?»
Une partie du travail d'un testeur est d'être toujours prêt et prêt à discuter des bogues. Cependant, le conseil de Jim est de commencer par vous mettre à la place du décideur et de vous poser la question «De quelles informations aurais-je besoin pour prendre la décision.»
Les parties prenantes sont généralement des personnes au niveau de l'entreprise qui pourraient facilement être déroutées par une liste de bogues contenant de nombreux détails techniques dont ils ne comprennent pas la signification. La décision "Dois-je libérer ceci ou pas?" dépend plutôt du bon fonctionnement des principales fonctionnalités et de la présence de problèmes critiques qui mettent le succès en péril. Se concentrer sur des résumés de plus haut niveau favorise un environnement de compréhension mutuelle que toute partie prenante apprécierait.
Passer du test manuel au test automatisé?
Au cours de la session en direct, Jim a lancé un total de trois questions de sondage sur la qualité de la livraison d'applications avec plus de 200 répondants chacun. Étonnamment ou non, les tests manuels ont été évoqués comme l'un des défis auxquels les gens sont toujours confrontés, les ressources internes étant épuisées et n'impliquant pas de tests suffisamment tôt dans le processus de livraison.
Près de la moitié de tous les participants sont aux prises avec des bogues atteignant la production et des inefficacités causées par la priorité du temps sur la qualité, tandis que moins de la moitié prétendaient déjà implémenter l'automatisation des tests.
La transition des tests manuels aux tests automatisés est difficile. Au lieu de réfléchir à la façon de remplacer l'un par l'autre, Jim conseille de poursuivre la mentalité de "Comment mélanger les tests manuels et automatisés pour obtenir les meilleurs résultats?" Les organisations qui réussissent parviennent à les intégrer dans un processus de test robuste soutenu par les outils qui fonctionnent le mieux pour l'équipe.
Les tests automatisés nécessitent de nouvelles compétences dans lesquelles les organisations doivent investir. Cet investissement en vaut la peine, car l'automatisation permet de confirmer les comportements et de couvrir des scénarios à grande échelle. Il est également crucial pour être rapide à publier des logiciels de haute qualité, et c'est un élément essentiel d'un pipeline d'intégration continue / livraison continue (CI / CD) qui fonctionne bien.
Si l'organisation est prête à accepter que la vitesse de livraison ralentisse pendant que l'équipe acquiert des compétences et de l'expérience, les chances sont plutôt en faveur d'une mise en œuvre réussie et d'un moral d'équipe sain. C'est encore beaucoup mieux que d'accepter les «déchets» comme d'habitude. Les organisations peuvent réaliser de grands gains dans leur activité en ciblant de manière agressive une «livraison de logiciels allégée».
Dernières réflexions
«N'évitez pas d'avoir des conversations difficiles avec le client ou la partie prenante.» La communication est un aspect critique du succès de la livraison de logiciels et donc du succès de votre organisation. Communiquer la bonne information au bon moment en fonction de vos connaissances et de votre expérience vous aidera à devenir un conseiller de confiance qui aidera à éloigner les clients et les parties prenantes d'erreurs coûteuses. Quelle meilleure façon de prouver votre valeur à l'ensemble du cycle de livraison? Impliquer la fonction de test suffisamment tôt dans la livraison du logiciel et faire passer les tests dans la définition de «terminé» sera le résultat naturel de vos efforts pour faire un meilleur travail en tant que testeur, développeur, analyste commercial ou chef de projet.
Jim a également écrit un livre blanc expliquant pourquoi et comment intégrer l'automatisation de l'interface utilisateur dans CI / CD . Il vous aidera à comprendre les avantages de l'intégration continue et comment les accélérer en définissant des critères de qualité appropriés pendant le développement et la livraison de logiciels.
Source link