Articles.

Thoughts from KMC

The life and times of testing

Manyano Gwele 01 Jun 2019 • 3 min read

SHARE THIS ARTICLE:
The life and times of testing

I’ve found it quite interesting how much the quality assurance/tester mindset has evolved over the years. From being known as non-technical people who just sit and click away all day, to being individuals who can hold a conversation with developers in the team.

This shift has definitely not been an easy one for quality assurance professionals who had the “I do not write code, code is for developers” mindset. We have seen major improvements in bug reporting - it was common for a tester to say “this is not working” and to throw it back to the developer to go figure it out. Now we live in a world where the conversation has become “this is not working because of A, B and C”. The level of detail included in the bug report better aids the developer to finding solutions quicker. This is because now they do not have to start debugging just to figure out what is breaking. Their time is better utilized in solving the issue.

This paradigm shift means there is a growing need for more technically inclined quality assurance professionals, who should be able to write automation tests that will keep up with the continuous change in software requirements. This then leaves little or no room for a traditional manual tester who has been acclimatized to only doing UAT testing once the product has been developed and is now ready to be shipped to production. The demands of repeated manual testing of the application due to the frequency of production releases, makes it impossible for the tester to do thorough testing. This then means more bugs will creep into production, which will become more expensive to fix once they are in a production environment.

In today’s world, quality assurance testers are an integral part of the development team and play a key role in the journey towards building the final product. Gone are they days where developers and testers used to work in isolation, which then resulted in what I call an “over the wall” syndrome. What this simply means is that developers would build a product without any input or constant check-ins with the testing team and then once done building, they will then hand it over to the testing team who will also still work in their own silos when testing the application. The Agile methodology has addressed most of the shortcomings that would end up prolonging the product from getting to production. What Agile simply advocates is for co-location and collaboration during the inception and development lifecycle of the product. This approach assures that the team is always in sync with what is being built, and yes, it also addresses the “over the wall” syndrome.

Now with all of this being said, one would then question if is there still a need of a manual tester if we can just automate? The answer is yes, we still do need a manual tester, but a manual tester who is also technical and can write test automation. No amount of automation testing would ever replace the human element when it comes to interacting with software. But in the same breath we need to keep up with the current demands of the evolution of how we build and ship software to production. Test automation is a vital skill set for a quality assurance professional to have in their arsenal. This will aid in going through regression testing faster and also getting faster feedback if anything has changed. This, in turn, allows testers’ time to be freed up so that they can focus on other aspects of improving the project.

Manyano Gwele