The question that serves as the title of this article has persecuted me in different representations since I started working in this sector a few years ago.
It is often said that the rope breaks on the weaker side, and figuratively this is how many companies see QA processes; when it should be the opposite. QA processes are as important as the project in which they are applied, it's that simple. If your testing processes are deficient, then that same deficiency will be noticed in the result for users.
The most recent case of these deficiencies, which affects me relatively closely, was noted on February 16, 2020. An entire country was preparing to select its regional authorities through an “Automated” voting system that right at the beginning of the voting it turned out to be useless.
The Reason
The data was inconsistent and in some cases too heavy to be downloaded or managed by the system.
The Excuse
The government institution in charge of managing the elections and developing the software used, pointed out that the responsible department omitted the testing processes and that those carried out were minimal.
In this situation it is always easy to find a culprit, and in this case the blame fell on those responsible for managing that the tests were carried out, however, I understand that the analysis of this scenario must go beyond the failed result of that February 16.
It is an error of the companies to think that the testing or quality process only starts at the moment that the first deliverables are sent to the testing environment, but the opposite; the process of monitoring the quality of a system must start with the very conception of the project and the creation of its requirements. From my perspective, that was the real problem that led that institution to release a system with severe deficiencies. After the conception of what you want to build is defined, then you should start creating all possible use cases around this idea, and once you have confirmed that you have everything you need to start, then a deeper analysis should begin in the detected use cases and delimit and standardize its data inputs and outputs.
With the simple fact of having followed this planning and development rules, everything could have been different:
- Requirements analysis, definition of standards and rules.
- Flow of the platform and delimitation of the input and output data.
- Implementation of pre-production test environment.
- Minimum quality tests for this type of systems (Functional, Regression, Load, Performance, Stress and Security).
In this particular scenario, the person representing the project or the person in charge of directing it is usually blamed, but from my perspective any member of the team could have raised the alarm in the first stages of the development cycle. In a hypothetical case that the people in charge did not heed the warnings, or that the team members simply did not feel confident enough that they could express disagreement by understanding that the work was being done wrong, so the team had problems far before the system.
I would like to point out that the idea of this article does not try to show any political relationship in favor or against, but I hope that through this experience others teams will take 5 minutes to think about whether the direction in which their projects move is the correct and prevent situations like this from happening again. A team with good communication almost always has half of the battle won and they only need to stay motivated to meet their goals.
Let me know in the comments if you have had similar experiences where somebody have tried to cut the time or quality of the tests and what has been the response of your teams to this situation.
Top comments (0)