So, after several years of work in QA related positions, some months ago I decided to make a side step on my career and move to a development position. In part, this change was due to personal interests (at the end, I’m a quite curious guy in everything related to techie stuff and QA positions were not fulfilling my needs anymore), but also because I realized that everything that involved the work done on a QA positions made more sense as a set of skills and tasks that a team should perform and possess than a list of tasks that should be done by a specific department.
Previously, on QA teams...
Let’s say that the specific idea of a QA team in origin was to “assure the Quality of the delivered product”.
On a generic way, Quality can be defined as the possession of properties on an object that are able to fulfill or overpass the expectations. Basically, that the product that we’re building works on the way that was originally designed (does what is expected to do and performs properly).
Therefore, the QA team should be responsible of the processes and tools to be able to assure that the product built fulfills its expectations.
This is the theory, but,...
Let's say it: in practice, the QA team tasks usually are limited to test, manually, at the end of the development cycle, the features that are going to be delivered, to assure that anything else was broken as a side effect and report any failure.
So, we end with a lot of developers writing features and not so many testers testing them out. The testing could be more or less planned, could be done at different ways, but at the end, it is perceived the same way: Clear separation between the two sides. Dev team is the owner of the development tasks, QA of the QA related tasks, aka testing.
This is where conflicts could start to appear:
QA team, or the QA Engineer present on the squad on Agile oriented environments, that should be responsible of the processes to assure that everything worked properly, is seen as the one that just tests stuff. Quality assurance becomes just testing.
And, Inconvenient Truth incoming: Development requires specific technical knowledge while usually to testing is more a question of soft skills, often undervalued. Usually, QA Engineers are people that do not even come from a technical background.
This could be seen as: developers are working on hard, interesting stuff and QA are, well, breaking it and taking notes on the failures.
So, the thing ends into undermining and undervaluing the QA tester labour.
Thinking on it a bit deeper
Quality should be not even a goal, but a mindset. Is not something limited to a serie of tasks that should be performed, but a way to perform on your daily basis. And, of course, should not be a single team member responsibility but a whole team involvement.
Switch the mindset of “I should develop this feature” to “I should make this feature work properly”. Turn off the mindset of “QA will find bugs if there are” to “Lets find a way to know if this is working as expected”.
Let’s be clear ( another inconvenient truth incoming): Testing is more a question of attitude than of aptitude.
And, as a QA Engineer, switch your mindset too. Explain your way of thinking, your way of work. Learn new things. Teach your team about tools that you use, spread your knowledge. Your work should not be only based on testing, demonstrate that it is like that. Get involved on other tasks away from testing, propose processes modifications, propose ways of automate testing, anything that could lead to help the team to, cof cof, assure the quality on what you’re doing. You’re in a field that requires constant adaptation, it works that way for you too.
Top comments (0)