A question that rages within a tester’s mind often is whether her creative and exploratory skills alone are enough for manual testing (or ‘Sapience testing’ as James Bach calls it, giving the profession some respectability) or should she venture into the ‘technical’ side as well, supposedly the domain of the developer.

A smart tester will likely deduce quickly that to test better, this delineation between manual testing (viz. non-tool based, user personification with little/no knowledge of what lies behind the screen) and ‘technical’ testing (viz. manual testing enhanced with tools, technical systemic knowledge) does not matter.

So why is ‘being technical’ for the software tester such a big deal? Why are there so many related questions on testing forums? What’s the advice for a newbie tester or even for a confused one?

At the outset it must be understood that some take the step into software testing because they find development or coding difficult to get to grips with. On the basis of their curiosity, analytical thinking, meticulousness, persistence they could critique applications, survived and scaled. They could explore a domain and find defects without needing to worry about how the screen was programmed, what happens to the data, how’s it stored and so on…

However, many testers start down the road because they love the craft of exploration, to make a difference and to improve the ‘creation’. Maybe they used tools or looked ‘behind the curtain’ to some extent or not at all. Maybe they did a quick check into the database to check if the password is viewable, a quick record-replay script to setup the static data for the application and so on.

It could be assumed by some that both these types likely worked well with Waterfall-based projects where developers and testers worked in silos enough to leave each to their tasks and their comfort zones.

Since its advent Agile has induced a shift for software testers into becoming more ‘technical’ due to the expectation of a cross-functional team, need for collaboration and continuous delivery requiring usage of automation and tools.

So the choice of a methodology and the shift to Agile is undoubtedly a driver but that’s not to say that a tester need not be technical if it’s non-Agile.

If a smart tester wants to make a difference and make the creation better, would it stop at manual testing? As a thinking tester, would it not be incumbent upon her to think deeper to make her craft better? ‘Better’ in this case could mean delivering results faster, more intuition driven rather than donkey work, reducing duplication of effort, or simply finding ways to do stuff that a human cannot (i.e. a machine can be programmed to do instead with relative ease).

For example, the usage of Jmeter allows a tester to hit a server with hundreds of transactions where even a coordinated army of people will fail.

Why wouldn’t a tester use a tool to read web content to help simulate, empathise and raise issues on behalf of a blind-user.

If the same tests have to be repeated across different operating systems, browsers, devices why should the tester act dumb, indulge in drudgery even if in the most conscientious manner. When the tester can command a tool to do this all, then why not? Indeed she will need to cultivate a programming sense and learn to develop scripts in a language which can automatically exercise an application like a human. A mountain for some to climb but for many mountaineering is an enjoyable pastime.

It’s become a reality today that the software tester has to competently co-exist with a much larger team comprising developers, business analysts, architects and so on. The required collaboration leads to ‘interactional expertise’ which is significant not just for the team but for the tester as well. In the context of the topic thus the tester stands to gain understanding of development nuances – be it cache-handling when executing tests, memory management when performance testing, development patterns when scripting tests etc. when she works alongside with the developer. The extent of interactional expertise will depend on how ambitious and learning oriented the tester is. The technical gain for the tester coupled with her exploring-cum-analytical mindset, fastidious outlook, and penchant for perfection should help deliver greater good on the testing front, helping meet the user’s expectations for optimal application behaviour.

Yes, we well may still have a tester who will doggedly remain non-technical by choice, agile or not. It is argued by some that being non-technical prevents development bias and will help the tester impersonate better a non tech-savvy user. The conclusion somewhat easily derived is that being with such a disposition, she will test more effectively. The argument is weak and can lead to results bordering on disastrous if one sticks with such dogmas.

Imagine if the non-technical tester is called upon to test a SaaS based application? Or singularly tasked to reduce the test cycles by a third without compromising on tests? What might be the options if such challenges confront her?

One may be effective as a non-technical tester, but it will be so much hard work likely facing the risk of being ostracized or driven to obsolescence in a very dynamic world. Like most things in life, it’s all about being smart and learning to strike a balance.

So perhaps being an accomplished software tester is a bit like when riding a bicycle; it is best if one keeps alert of one’s surroundings, avoids sharp objects and keeps peddling onwards.