Tester sans ressource d'assurance qualité

Est-il possible de tester suffisamment les applications logicielles avec uniquement les développeurs et les BA et aucune ressource d'assurance qualité?

Il y a deux écoles de pensées ici:

La première est la croyance que tous les bogues sont liés au code et que si vous avez un pourcentage très élevé de couverture de test pour votre code, vous ne devriez essentiellement pas avoir de bogues. En tant que testeurs, nous savons tous que ce n'est pas vrai!


L'autre conviction est que vous effectuez des tests unitaires suffisants et que vous effectuez également des tests d'intégration, de système et d'acceptation des utilisateurs pour vous assurer que l'application est adaptée à l'objectif. Bien que cela semble une bonne idée, ce n'est pas pratique car les développeurs doivent continuer à coder de nouvelles fonctionnalités!

Ces deux croyances sont extrêmes.


Tester votre propre code peut être efficace, car en tant que développeur, vous savez quelle partie de votre code est complexe et plus susceptible d'être boguée, vous vous concentrez donc sur ce domaine. De plus, sachant qu'il n'y a plus de contrôle qualité, vous êtes obligé d'écrire du code de qualité, comme le dit un développeur

Dans mon premier emploi, je n’avais pas de contrôle qualité. C'était à moi de m'assurer que mon propre code était suffisamment de qualité avant de le publier, et cet aspect m'a suffisamment terrifié pour que j'apprenne à écrire du code de qualité (ce qui signifie essentiellement que vous testez votre propre code à fond, faites votre propre contrôle qualité).

Les tests des développeurs sont-ils suffisants?

Je pense que c'est une bonne décision d'encourager les développeurs de logiciels à s'approprier la qualité de leur propre code, mais lorsque vous testez votre propre code, vous risquez plus que de manquer une classe entière de bogues.

Vous pouvez être très efficace pour attraper les types de bogues auxquels vous pouvez penser, mais ce sont toujours les bogues les plus faciles à attraper en premier lieu. Les tests que vous écrivez pour vous-même ne permettront jamais de détecter les erreurs dans vos hypothèses sur ce que le code doit faire, les types d'entrées qu'il doit gérer, etc. Attraper ce genre de bogues conceptuels nécessite vraiment des tests contradictoires de la part de quelqu'un qui n'est pas ne partons pas du même ensemble d'hypothèses.


Travailler en tant que testeur d'automatisation signifiait que je devais me concentrer sur les tests et le codage à la fois, et j'ai souvent eu du mal! Lorsque je codais les tests, je voulais juste m'assurer que le code s'exécute et réussir le test, je n'étais pas trop dérangé par le test réel car mon objectif principal était le codage. Bientôt, j'ai réalisé que j'automatisais des tests inutiles qui n'apportaient aucune valeur.

Un autre point important à noter est que les tests unitaires ne détectent que les erreurs de programmation dans le code, les tests unitaires ne détectent pas les échecs dans l'application, ce qui signifie que si vous avez une couverture de code à 100%, cela ne signifie pas une application sans bogue.

S'il est toujours nécessaire de tester votre propre code via des tests unitaires avant qu'il ne soit transmis, il est également important d'avoir ce deuxième regard sur celui-ci d'un point de vue comportemental. Souvent, nous sommes trop proches du code pour vraiment le battre correctement et le soumettre à des cas extrêmes vraiment étranges, et les bons responsables du contrôle qualité sont assez habiles à le faire. Les tests au niveau du système par un autre groupe d'utilisateurs tels que les testeurs peuvent souvent révéler des bogues très intéressants.

De plus, il ne s’agit pas uniquement de tests fonctionnels. Nous devons nous soucier des tests de performance, des tests de sécurité, des tests d'utilisabilité, etc., ce qui est nécessaire si nous voulons publier un logiciel de haute qualité.


Pourquoi avons-nous encore besoin d'AQ?

Les testeurs sont parfois considérés comme un goulot d'étranglement pour l'ensemble du pipeline de livraison. Ne serait-il pas tellement mieux si tout était automatisé sans intervention manuelle et sans testeurs soulevant des bogues pour arrêter la publication?

Une partie du problème lorsque les testeurs sont considérés comme des goulots d'étranglement est dû au manque d'appropriation de la qualité parmi les développeurs. Si tout le monde sentait vraiment qu'il était responsable de la qualité du produit (pas seulement du code), alors les développeurs et les testeurs travaillent dans le même but.

Les testeurs peuvent s'associer avec les développeurs pour rédiger de meilleurs tests unitaires et les développeurs peuvent aider les testeurs à écrire des contrôles automatisés et également éduquer les testeurs sur l'architecture de l'application afin qu'ils puissent concevoir de bons tests pour trouver les zones les plus susceptibles de se casser pendant les tests du système.

Dans un monde idéal, les testeurs ne doivent trouver aucun défaut, ou du moins des défauts insignifiants. Lorsqu'il y a une «équipe de QA» dont le travail est de trouver des défauts, il est tentant pour les développeurs de se fier uniquement aux testeurs pour trouver tous les défauts tandis que les développeurs se concentrent sur le développement et le codage.


Bien que la décision de Yahoo d'éliminer le service d'assurance qualité et de test encourage les développeurs à s'approprier la qualité du produit, elle n'est toujours pas suffisante pour garantir un produit robuste. Cela dit, même avec une équipe de testeurs, vous ne pouvez toujours pas garantir un logiciel sans bogue, mais ce qui est important, c'est de s'assurer que le logiciel est examiné de différents points de vue et de différents points de vue et c'est là que le réel avantage d'avoir une bonne fonction d'assurance qualité (par opposition à l'équipe d'assurance qualité) vient.

Les testeurs peuvent s'assurer que les développeurs suivent les meilleures pratiques d'assurance qualité et aident à concevoir des tests techniques et commerciaux pour aider à identifier les bogues les plus critiques avant de publier le logiciel.