Why you might need some QA
Yoan Blanc — Tue, 30 Mar 2010 — Quality Assurance, Quality, Test
In the various projects I’ve been involved in something continues to amaze me, the lack of quality focus from the start. A common reflex seems to rush into doing what has to be achieved and rely only on asking about the status. It works or might work for small projects, small tasks with very few interactions or dependencies but it doesn’t scale.
A Quality Assurance role is more than acting as a tester, far more, but let’s start with what a tester can bring you.
Including a tester in a task can shift from a dialog between the one who’s asking something and the one who gonna do it to a three members discussion forcing everyone to be more precise in what he does or asks and documents more. Is documentation something that lacks on your project? Testing starts at the same time than doing by planning what’s gonna be tested and what are needed in order to test everything. As a developer it always helps to know what you need to deliver in order to cover all the interesting use cases.
QA can help fighting entropy. The fact that you cannot maintain order without creating disorder and that things degrade over time. Nowadays many tools are available to program testing, to run them automatically, to find out what’s tested and what’s not, and many more.
As a developer you might be already writing unit tests, functional tests, integration tests, practicing TDD/BDD, maybe ping-pong development or other kind of XP techniques and it’s awesome. Although I still see the need of someone with a focus on that part as you have your focus on delivering what you’ve been asked to.
Assurance is about preventing problem to happen by acting upstream. They are simple tools against firefighting, like code reviews, using linters but mostly communication is a great help. Having a dedicated QA role helps using those tools and ease communication as well.
What sounds really important to me is the separation of roles, delivering something on time vs delivering something that works as expected. The person who’s asking it wants both and I often found myself not being able to wear the two hats. Like a writers has difficulties to find his own spelling mistakes.
Role plays are fun and I don’t think that wearing the QA hat is degrading or boring.
Au travers des différents postes, projets auxquels j’ai participé, un point continue de m’étonner. Le manque d’attention porté sur la qualité du produit fini. De manière générale, ça ressemble à voici ce qu’il y a à faire, fais-le. La description pouvant être relativement floue et le résultat attendu presque laissé libre à celui qui doit le réaliser. Si de petits projets peuvent fonctionner ainsi car la communication est aisée, les problèmes sautent aux yeux dès qu’une équipe gagne en taille.
Le rôle d’assurance qualité est très vaste et ne doit pas être réduit au terme testeur. Même si un simple rôle de testeur peut apporter énormément déjà.
Le test intervient simultanément avec la réalisation, de manière légère préparant ce qui devra être testé et s’assurant qu’il obtiendra tous les éléments nécessaires aux tests. D’autre part, ça ouvre la discussion entre la personne définition la tâche à accomplir et celle qui la réalisera. De deux à trois personnes, il devient indispensable d’être plus précis et certainement de se reposer sur de l’écrit. En tant que développeur j’ai trouvé intéressant d’avoir une personne venant me demander des éléments testable, devoir préparer ceci aide lors de la réalisation.
Dans un rôle de validation, de tests, il est, à l’heure actuelle, indispensable de mettre en place un certain nombre d’outils permettant de rejouer ces validations dans le futur. C’est une tâche demandant un investissement certain et des compétences adéquates. Même en tant que développeur si vous vous reposer déjà sur du développement piloté par les tests ou simplement des tests unitaires vous verrez comme une grande aide d’avoir une personne concentrée sur la qualité plutôt que les échéances.
Il est souvent dommageable de voir une telle attention portée sur un délai de livraison, voulant absolument tout y mettre. Peu souvent il m’a été donné de voir la mentalité disant : « je préfère en faire un peu moins mais ça doit être du solide »hrom. Un rôle dédié à ce point de qualité peut amener ça, s’il est bien entendu soutenu et pas combattu dans des discussions dites politiques.
L’idée d’assurance soutend que le gros du travail doit être fait en amont, prévenir un problème coûte bien moins que de l’identifier et le corriger. La tendance est à voir cette personne là intervenir à la fin, quand il est souvent trop tard hélas. Être présent dès le début, et pouvoir aux travers de code reviews, de tests spécifiques, d’analyse du code améliorer de manière continue le produit fini est faisable et ne me semble pas avoir un coût énorme. C’est un parti à prendre et une ouverture d’esprit à avoir.
Séparer les rôles en fonction des objectifs est vital. C’est difficile d’être juge et parti. D’autre part, je considère une position de testeur, ou d’assureur (voilà qui fait sérieux) comme n’étant pas du tout péjorative, c’est même un élément intéressant à réaliser quand il s’agit de mettre en place des outils.
