Tests modernes - L'évolution du rôle de l'assurance qualité

Le développement logiciel a évolué depuis l'époque de la cascade, de l'Agile et maintenant du DevOps. Naturellement, les tests en tant que discipline ont également connu quelques changements majeurs pour s'adapter aux nouvelles façons de travailler et de fournir des logiciels.

Cependant, il existe encore un énorme malentendu et une perception erronée du rôle des testeurs et de l'assurance qualité dans son ensemble.

Dans cet article, nous examinons comment les tests ont évolué, en particulier au cours de la dernière décennie, et ce que les professionnels de l'assurance qualité doivent faire pour garder une longueur d'avance.


Les tests ne peuvent que devenir plus intéressants!

Bien que les activités de test de logiciels aient changé pour s'adapter aux nouvelles méthodes de travail, je vois encore beaucoup de points de vue démodés sur les tests et le rôle d'un contrôle qualité.


Il est décourageant de voir qu'il y a encore beaucoup de gens dans l'industrie informatique qui considèrent les QA ou les testeurs comme le résultat final. Les testeurs sont souvent considérés comme de simples testeurs fonctionnels qui ne testent qu'une fois que les développeurs ont fini de travailler sur une fonctionnalité. L '«assurance qualité» est perçue comme le test, la recherche et le signalement des bogues et le feu vert pour la publication.

Ce qui est encore plus inquiétant, c'est que cette perception du rôle du contrôle qualité est primordiale parmi les testeurs et les professionnels du contrôle qualité eux-mêmes.



Test de logiciel traditionnel

Historiquement, en prenant la tête des phases finales d'un projet en cascade, les tests se situaient fermement à droite du cycle de vie du projet. Après la définition initiale des exigences, les testeurs prendraient le relais de l'équipe de développement à la fin de la phase de développement et exécutaient des scripts de test longs et détaillés, souvent manuellement, et généralement par le biais d'équipes et de groupes de PME cloisonnés.

Les cas de tests ont été méticuleusement planifiés à l'avance, les scripts ont été exécutés par des spécialistes, les défauts ont été détectés et signalés, et les cycles de test ont été exécutés et réexécutés jusqu'à ce que les niveaux de qualité prédéfinis soient atteints.


Plus particulièrement, il y avait toujours une séparation claire entre les développeurs et les testeurs, sans chevauchement de responsabilités ou d'activités. En effet, au cours de la phase distincte et circonscrite des tests, les activités étaient purement axées sur la validation fonctionnelle des logiciels dans le but principal de détecter et de signaler les défauts.



L'assurance qualité à l'ère de l'agilité

L'émergence de méthodologies et de méthodes de travail agiles a fusionné les activités de développement et de test à un point tel que le test des logiciels n'était plus une phase autonome. Au lieu de cela, les tests sont devenus une activité implicite pendant le codage et le développement de logiciels.

Dans certains cas, il serait difficile de voir la distinction entre un 'testeur' et un 'développeur' car chacun aurait la capacité d'entreprendre de manière transparente les activités de l'autre.

La «qualité» a cessé de devenir la seule responsabilité des testeurs et est devenue une responsabilité partagée de toutes les personnes impliquées dans le développement et la livraison du produit.


Parallèlement à cette évolution, les responsabilités de test ont été déplacées vers la gauche du développement, essentiellement la qualité de cuisson dès le départ.

L'accent est passé de la recherche de défauts dans les logiciels intégrés à la prévention des défauts dans le logiciel en premier lieu.

Avec un objectif commun de garantir non seulement que le produit ou la fonctionnalité était fonctionnel et répondait aux exigences, mais était également adapté à l'objectif et fournissait un niveau élevé de satisfaction des utilisateurs.

En rapport:


L'implication des testeurs dans le raffinement de l'histoire, les revues de code par les pairs, les tests unitaires et les pratiques telles que TDD, BDD et les tests continus, garantissait que les tests et la qualité étaient au premier plan et intégrés dans le développement.

Mais, alors qu'Agile a beaucoup contribué à combiner les activités et les pratiques de développement et de test, l'équipe des opérations était toujours cloisonnée. Les deux flux de travail (Dev & Ops) n'étaient souvent pas au courant des activités de chacun.

Si quelque chose n'allait pas dans la production, l'enquête prendrait beaucoup de temps. Les développeurs n'avaient pas d'informations sur les performances de leur application en production à long terme; il n'y avait ni transparence ni clarté de collaboration entre les deux équipes.



Bienvenue dans DevOps

DevOps fait référence à la collaboration des équipes de développement et d'exploitation à travers la création, la livraison, la maintenance et le support de logiciels. Il se réfère à une union continue de la ressource, des processus et du produit lui-même.


DevOps permet des méthodes d'intégration continue et de fourniture de valeur à l'utilisateur final.

Le mouvement DevOps a introduit une nouvelle perspective sur les tests et créé de nouvelles opportunités pour les testeurs eux-mêmes.

Dans cette nouvelle ère, les testeurs doivent être alignés sur le développement et les opérations.

La mission de test ne se limite plus au produit mais aussi au test de l'infrastructure où le produit est finalement exécuté.

L'intégration continue (CI) et la livraison continue (CD) sont devenues la norme de facto dans le développement et la livraison de logiciels, et par conséquent, une grande partie des efforts de test est maintenant consacrée à assurer le pipeline, les environnements et l'infrastructure CI / CD.

C'est la colonne vertébrale qui prend en charge à la fois le développement et la livraison.

Si les tests de ceux-ci sont négligés, cela pourrait entraîner des environnements irréguliers, beaucoup d'efforts gaspillés pour enquêter sur des problèmes d'infrastructure répétés et, en fin de compte, un risque élevé pour le développement et une livraison rapide.



Tests modernes - Développement axé sur la qualité

Bien que beaucoup ait été fait pour intégrer la qualité à chaque étape du développement et, par conséquent, que les tests aient une portée beaucoup plus large, je pense toujours que les responsables de la qualité passent la plupart de leur temps à rechercher des problèmes fonctionnels et à se concentrer sur la vérification des logiciels.

La plupart des AQ ne réalisent pas l’importance de leur rôle et l’impact qu’ils peuvent avoir sur le développement et la livraison.

Malgré les changements considérables dans les pratiques de développement au cours des dix dernières années, j'estime que les testeurs ont toujours une vision démodée de leur rôle et restent donc ancrés dans l'ancienne ère des tests.

Le test en tant que profession et le rôle de testeur sont sous le feu des critiques depuis un certain temps avec l'essor des «tests automatisés». Et en effet, de nombreux professionnels de l'industrie croient encore que le rôle d'un testeur est simplement de tester l'application que les développeurs construisent, qui peuvent toutes être automatisées.

Si les développeurs sont mieux adaptés et plus avertis pour écrire le code nécessaire aux tests automatisés, quel besoin y a-t-il d'un testeur dans l'équipe?

Il est temps que nous changions cette perception. Nous devons reconnaître la différence de valeur et de compétences entre «tests» et «assurance qualité» car, lorsque les tests sont la vérification fonctionnelle et la validation des logiciels, l'assurance qualité n'est pas une activité unique. L'assurance qualité est une série de processus, y compris les tests, et les meilleures pratiques pour garantir qu'un produit de qualité est livré aux utilisateurs.

Nous devons viser un développement axé sur la qualité et considérer la profession d'AQ comme la fonction centrale et essentielle du développement et de la livraison de logiciels, d'où Test moderne .

L'assurance qualité est désormais un élément clé du développement du début à la fin, tout au long du processus. Et, bien que le langage courant dit que tout le monde dans une équipe de livraison est responsable de la livraison d'un produit de qualité, je crois fermement qu'il est de la responsabilité d'un AQ de s'assurer que les pratiques de qualité sont respectées par l'équipe.



Qui est le QA moderne

Là où la profession de test était souvent considérée comme une voie d'accès au développement, à la gestion de projet ou à d'autres disciplines - généralement plus lucratives -, le nouveau QA est un rôle hautement qualifié qui exige une connaissance holistique des pratiques de développement.

Cela nécessite une large compréhension des défis des pratiques de codage, une appréciation des méthodes et des environnements de déploiement ainsi que des normes, méthodes et défis de performance et de sécurité.

Il s'agit d'un rôle en forme de T avec la ressource capable non seulement d'appliquer sa profonde expertise et son expérience pour s'acquitter de sa mission principale, mais également d'appliquer une connaissance contextuelle plus large à travers l'architecture et le développement.

Assis au centre de tout projet, le QA moderne doit avoir une bonne compréhension de l'architecture, des performances, de la sécurité et des offres cloud, être techniquement solide et avoir soif d'apprendre de nouvelles technologies pour rester dans le jeu.

Noter:Un autre domaine qui devient rapidement très populaire et essentiel pour les tests de qualité des données, les tests de mégadonnées, de lacs de données et d'entrepôts de données.

Le moment est venu de changer la perception du rôle d'AQ et ce que font les testeurs. Cela doit commencer par les testeurs eux-mêmes. Le point de départ est de se soucier profondément de la qualité.

Les testeurs ne sont pas là uniquement pour effectuer des tests fonctionnels et signaler des bogues. Le rôle d'AQ est bien plus important que cela. Nous sommes mis sur un projet pour garantir des pratiques de qualité .

Lorsque nous testons en profondeur une application, nous devons avoir une connaissance intime de l'ensemble du fonctionnement du système et pas seulement regarder l'application comme une boîte noire.

Afin d'avoir cette connaissance intime, nous devons apprendre continuellement et suivre les nouvelles technologies et méthodes de travail. Plus important encore, les AQ doivent être adaptables.

Lorsque les AQ comprennent leur objectif sur un projet et commencent à croire que leur rôle est la pièce maîtresse du développement et de la livraison de logiciels, lorsque nous adoptons les principes de test modernes, ce n'est qu'alors que nous pouvons changer la perception des autres.