Reflections of a QA
Have you ever reflected about your role in your company? How could you do better? Why does your position have a certain work dynamic? In this article we aim to reflect about the role of the Quality Assurance Analyst, question certain aspects and make a self-criticism about it. The Quality Assurance Analyst should be as the referee in soccer, the more unnoticed he goes and the less they talk about him at the end of the match, the better he did his work. In many cases, parallelisms with this sport can be found in this role. Sometimes, referees are frustrated soccer players that did not achieve professionalism, whether for not being as talented as required or for not persevering enough. Equally, the QA is, in some particular cases, a frustrated Developer that for not persisting enough, some life difficulty, or simply for taking an easier path, preferred to settle for pointing out and highlighting other’s mistakes. This generates a presumptuous ego, the need to be seen by industry colleagues, to feel important, as an essential link in the chain. QAs wish to believe this to feel well with themselves.
Actually, this is not true. Any careful and meticulous Developer could perfectly replace the QA’s role as well as other more tangential positions as Project Managers or Business Analysts. Our job in the IT area is one of those that needs less previous requirements to be acceptably done. Indeed, this is how they sell Testing courses in many institutes and academies: “Anybody can be Tester”. This inflated ego attempts against QAs; and as well as in life, believing we are separated from the rest leads us to take actions and have attitudes that, in the long term or in the short term, damage the team and thus, ourselves.
Matías Angio’s experience, and what makes him reflect and write about it, is based on team work in which physical space is shared, working for a project which is not in production yet. Work methodologies used are based on Agile Methodology, some of them use continuous development practice and others are based on traditional release processes. Beyond differences, the central idea applies to everything.
The first and most important aspect QAs should keep in mind is attitude. Having a positive attitude towards the team and the client is imperative. We are what we emit, and how our mood impacts others is more than verified. Even though it is true that it is hard to stay positive when things do not work out, it is on us to try and reverse this negative situation, we should propose that challenge to ourselves. Moreover we ought to accept criticism and improvement recommendations we receive, directly or indirectly, from our coworkers or superiors. Only when we accept them, without value judgments or taking it personal, will we be able to talk with others openly and suggest improvements in an honest way, so as to avoid offending anyone and being misinterpreted as arrogance or meddling in someone else’s work. We ought to try to avoid being the finger that constantly indicates what is wrong, without getting involved, and try to improve things from the inside, with small actions that help others.
We need to be proactive. Our job should not start when we receive a task to test. There are many things we can do before and during the time we are testing: create test cases, analyze requirements, test other functionalities, think and look for improvements on workflows of products in development, raise and impose doubts on the team such as “What if…?”, among others. Our idle time, as it happens with some math function limits, should tend to zero. Time is important, and it is a discussed issue since human civilization’s origins. It is said that time is money and that money perceived for work is paid with time of life. Other visions, spiritual as well as scientific, propose that time itself does not exist beyond our own minds. The point is, sometimes we enjoy whiling away time. On many occasions, we hold a task back, or give it back to a Developer to solve details which we could have perfectly communicated orally. Matías Angio explains he has not calculated how much time is lost in all that process yet, but he senses it is a lot.
As written at the beginning, the more unnoticed QAs go, the better. The fact that we report bugs again and again does not make us better testers. If we detect that something is going to fail or could look bad from early stages, communicating it beforehand is the optimum path; instead of waiting for it to be developed to find and point out the mistake. Prevention is better than cure.