How to earn more money as a QA
These days a lot of people practicing Quality Assurance tend to be judges to developer’s mistakes. That is wrong! One project does not need more judges than it is supposed to have (the only judgement for the project has to be made by project stakeholders – that is why Continuous Integration was invented). The project needs a small, integrated group of professionals that could lead it to a successful release. This group we name a Team.
The QAs are a crucial part of this team. Not less than the developers are. This is because in software development in most cases we do not have formal methods to prove the correctness of the code produced by the developers.
It is very important that one software development team has brilliant QAs – not good – it is not enough – QAs have to be brilliant – even more than developers.
Why are QAs so important? The answer is – because QAs could amplify developer’s errors. Hence – the good QA is the QA that does not amplify developer’s errors. It is the opposite – a good QA will diminish developer’s errors. Please notice – It is not finding lots of bugs the main criteria for a good QA. This is because, usually developers themselves know in which cases the logic they developed is weak (except when they are juniors, not familiar with subject matter), so QAs have to investigate if the developer has made some mistakes while implementing the logic.
This could be achieved by following the entire logic path leading to results in a given use case. It is not enough to say “This functionality does not work… period”. Everyone could say that – no
need to be named a QA. A really good QA will say upon what conditions the given functionality is wrong, how it is wrong, on which step of the “user path” to this functionality things are going wrong. These questions differentiate a brilliant QA, from a good QA.
These are the questions that help developers minimize their errors. These are the questions that really lead to fixing bugs, improving code quality and achieving client satisfaction. Answering these questions helps the whole team to excel.
QAs have to articulate well the bugs found. This means that they have to understand the whole logic of the application and to be able to see connections between different parts of an app and to point the developers to eventual error spots. All this means that the QA has already done some thinking over the whole application and the specific bug found. This means that the QA has already traveled half of the path to fixing the bug. This diminishes time for fixing and increases the velocity of the whole team.
A Brilliant QA knows the context in which the bug happens. She/He can think in terms of this context. She/He can invent new test cases, based on the rules of the context, thus pushing the implemented algorithms close to their limits. A Brilliant QA has to push the application more than the average end user will.
Good articulation of the bugs found according to the context – that’s what makes a brilliant QA.
Photo by Thula Na on Unsplash
