Is Manual Testing Primitive?

Traditionally software was tested manually. Somebody wrote detailed test cases and then went through the steps in a tedious job of clicking on the objects on the screen. Sometimes one person wrote the tests and another executed them. They tested multiple scenarios in different browsers and across various operating systems, collected screenshots, marked test cases as "passed" or "failed" and went home. At the end of the day they often had no clue what they just tested.

I recently read an article "Do We Really Need Manual Testing?" by Prashant Kumar about the importance of manual testing. In the comments I was asked to give my opinion on one sentence in which the author called manual testing "the most primitive form of testing".

So, is manual testing primitive? And if so, is it bad?

Primitive manual testing

Here's the thing. Any human activity can be done in a primitive way or become an art. It's the same with testing. There's definitely a very primitive tradition of having shared testing resources (often unskilled and cheap) who can go through the motions of executing test steps without understanding the application they are testing. This kind of manual testing rely exclusively on the process and hand-off documents. The primitive manual testers can take a business requirement or design document and mindlessly translate it into test cases. Will these test cases have value? Yes, some value, certainly. Will they improve the application and make it flexible, robust, secure and user-friendly? I doubt it.

Primitive manual testing can exist in Agile environment if the cross-functional team sticks to the old-fashioned mini-waterfall and uses QA as cheap labor. The testers in this case do as they are told by QA manager or developers but wouldn't venture outside the documented test steps, don't own the application, don't understand the business workflow, don't have user perspective and don't know how the software is hosted and operated.

Sometimes great talent is reduced to the primitive manual testing due to the lack of automation. They have to spend so much time clicking on objects and links, testing cross-browser, cross-operating system and version environments, they simply don't have time to do anything else.

Advanced manual testing

The way to advance manual testing is two-fold. First the testers must be a part of the development team that owns the product. Second, they should automate all tedious well-documented tasks in which both input and outcome are clear and straightforward.

To own the application, the Quality professionals have to excel in all areas of expertise:

• Business domain: understand how product makes money, how it helps customers to simplify or automate their workflows. Know the users, who they are and what they do, how they use the system, what permissions they have, what their pain points are.
• Operational domain: how is the system is installed or hosted, what performance expectations would the user have, what is the typical load on the system?
• Technical domain: understand the technology stack used to create the software. What are the bottlenecks, risks, dependencies, areas impacted by each change?

The advanced manual testers are explorers who know (or learn) answers to two most important questions of Quality:

1. What is the system supposed to do?
2. What does it actually do?

These two simple questions are the heart of any testing, manual or automated. Once the testers have intimate knowledge of their application, they can automate all repetitive tasks and continue using their intellect in areas that require human creativity: usability testing and exploratory testing.

Extreme manual testing

All engineers like building things. Testers like breaking things.

Extreme testing is the ultimate opportunity for the tester to push the system to its limit, find ways to get it to crash, run out of memory, throw an exception, fail on a timeout or deadlock. It can be done manually or through automated load, performance or stress testing.

"Monkey test" can be a lot of fun and bring some unexpected discoveries.

Ad-hoc testing is an unscripted functional testing in which the tester acts as a user (experienced or not) going through a combination of standard as well as weird undocumented workflows the real users can get themselves into.

Another way to test the application is security testing, in which the tester is trying to "break" into the system, penetrate the network or obtain access to sensitive or protected data.

The advanced and extreme manual testing is not primitive. Not at all! It's a creative process that requires a lot of deep knowledge of the application, business and technology, curiosity, innovation, ability to think outside the box. Far from being primitive, this is the true artisanship or even art of finding flaws and improving the software to make it awesome.

What level of manual testing is your organization doing? Primitive, advanced or extreme? I hope this article helps to create goals for your manual and automated tests.

Happy testing!

Please like and share with your network! Comment, share your thoughts and send me your questions, follow me on LinkedIn and Twitter to read my articles on practical Agile.