Software Testing – Automation or manual testing, that is the question.

In this recent posting, the question of when to automate and when to stick to manual got another airing. It prompted the usual flurry of comments and it’s great to see the passion out there. So here’s my view. Feel free to throw rocks at it – but I’d prefer it if you just use the comments box…!

In my view, test automation should be non-disruptive and it works best when it supplements and extends manual test to eliminate the mundane, repetitive parts of the manual test process.  But it’s always important to keep in mind that software testing is about ensuring functionality in the way that human beings use it. What that means is that until automation can anticipate every aspect of human behavior, the initial test implementation will still be, to some extent, manual.

Capture and … automate

Once the initial test procedures are captured, though, automation can eliminate the redundant test tasks that don’t change. That’s why Borlandintroduced keyword-driven testing (KDT). This enables test procedures to be implemented once and then assigned to a keyword, or for a keyword to be defined and the test procedures scripted for that keyword, so that it can be reused to automate repetitive features.

Test implementation can be a combination of captured keystrokes, mouse clicks, gestures etc. that are converted into script along with some manual scripting when required to complete the test procedures.  Once implemented as keywords, the test procedures can then be connected together to create complicated, multi-faceted test scripts much more easily than writing those test scripts from scratch.

Automate to collaborate

Keyword-driven testing can also facilitate role-based testing and greater test collaboration by enabling non-technical business stakeholders to participate in software testing without having to understanding the test script details. Business users can interact with keywords such as “Click Select Button” or “Select Shopping Cart” without having to understand the underlying test script that implements those operations.

As object-oriented programming accomplished for software development, keyword-driven testing enables reusable test procedures to be captured and implemented in a way that boosts test automation considerably.

It enables manual test implementation to be reduced as much as possible with automation while still recognizing that the manual variations needed for realistic software tests.  It also enables greater software test participation by all key stakeholders, including non/less-technical operations and business personnel.

So in summary, I’m joining the narrative – automate when you can but don’t treat it as a silver bullet. But that’s my view. What’s yours…? And don’t forget Load Testing.