The True Purpose of Testing

After 20 years in the QA/Testing field, I’ve seen a plethora of trends come around.

All seemingly trying to placate senior execs. Testing is still shockingly seen as a cost that rarely bears any value unless it can be done cheaply and quickly – so the obvious path to take is we automate or offshore? I'm going to leave the offshore part alone - as i could spend days writing about this and what's wrong with this practice. You ask any in house QA manager/director if they are truly happy with their offshore activity, you might find 1 out of 10 who says yes. And that 1 person would still rather have a team in house, with the BA's, with the developers, working as a unit rather the place you throw things over the fence to.......see I almost started going in depth.

Moving on.....

When Automation first became relevant in QA, tools like Mercury Winrunner and QTP were developed and used as a time saving tool for manual testers. To be able to easily repeat actions that needed to be done before valid scenarios could be tested.

But we are now in a position where automated testing tools are seen as a replacement for actual testing.

The problem is the perception of testing.

Testing is looking at the system under development, understanding what the need is, what is being filled, and what the customer/client actually wants.

A lot of people will see testing as “checking the code works” – and this is the biggest problem in IT.

Personally, when I test a new feature or change, I’m looking at the requirements, how the user will interact with the system, behaviors that just don’t flow or make sense. How the developer wrote the code, what his expectations are, what he says it should do are valid points, but should not impact how a tester performs their job.

Tools can check code flow, API level testing, SoapUI etc. They can “validate” the code. Does this API send the correct message to this endpoint, is the format valid, do any exceptions occur……

But does the UI flow, will a customer understand the screens, the system, the experience - needs someone with eyes, someone who understands the human side.....a manual tester ("OMG, he said manual tester")

I’ve first-hand experience in seeing the ramp up of automation lead to the decline in quality. Making all manual testers redundant and focusing on people who can write code…..

A balance is needed. Automated tests for code level tests and key regression (hopefully all built in to the build mechanism) paired with manual testing to confirm requirements are met.

It is a fine line, and one that very few companies walk. Made more difficult by shiny new tools and highly technical people saying you’re doing it wrong.