Tags

Is Manual Testing running out of gas?

I often hear statements that manual testing is running out of gas and very soon the industry will not need manual testers and that manual testing is primitive.

 

I beg to differ.

 

In my opinion, there are 3 different versions of manual testing

 

Primitive manual testing

 

Someone wrote detailed test cases and someone else did the tedious and boring task of executing the test cases by clicking on links and buttons all over the screen. They would run test cases on different browsers and operating systems. They collected screen shots of all flows and marked the test cases as “pass” or “fail”. But they have no real clue as to what they really tested

 

The primitive tradition of sharing test cases and having someone else (often unskilled and cheap) mindlessly execute the test cases without a clue on what the application should really do. Will these tests have value? Yes, most definitely. Will they improve the application and make it flexible, robust, secure and user-friendly? I very much doubt it.

 

Primitive testing can exist in an Agile model if the team decides to stick to the old fashioned mini waterfall and use QA as cheap labour. The testers in these environments do as the developers and QA manager says, but won’t venture out any further than the specified documentation or own the application. Primitive testers don’t understand the business workflow (the business need), they do not have the user perspective and they don’t know how the software is hosted and operated etc.

 

Sometimes (unfortunately) 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

 

n Advanced anual testing, the QA team is expected to be involved with the development team and that owns the product from start to finish. They automate all well-documented tasks in which both input and outcome are clear and straightforward.

 

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

 

  • Business domain: understand how the product makes money, how it helps customers to simplify or automate their workflows. They should 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 learn or know the answer to the two most important questions of Quality:

 

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

These questions are the heart of testing, let it be manual or automated. Once the testers have this knowledge of their application, they can automate all repetitive tasks and continue using their intellect in areas that require human creativity such as usability testing and exploratory testing.

 

Extreme manual testing

As all engineers like building things, Extreme Manual Testers like to break things. They would push the system to its limits. Find ways to crash it, create an exception, run out of memory, fail on timeout or a deadlock. In other words, they will run Monkey Tests.

 

The Tester will also run Ad-hoc testing. They poke around and run some undocumented flows that an inexperienced user may get them self’s into and observe how the system will respond.

 

Another test that Extreme Testers may run is security tests. The Tester will try to “break” into the system, penetrate the network or obtain access to sensitive or protected data.

 

Conclusion

 

Advanced and Extreme manual testing is definitely not primitive. Not at all! It’s a creative process that requires a lot of in-depth knowledge of the application, the business and technology, curiosity, innovation, and most importantly the 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 absolutely awesome.

 

Yusra Marikkar

Yusra has over 07 years of experience in Software Quality Assurance. She has worked in different domains and different technologies.

2 Comments
  • Posted at 7:58 pm, November 1, 2017

    Your segmentation into three levels of testing is familiar and actually depicts the evolution of testing since 2000 I think. An organization that is in the Primitive level today will have a lot to work with to be able to cope with the hight speed of developing software for the Cloud.

    The Advanced level with some automation wil allow the tester to explore and learn more about the application, but to reach this level the tester must not be a bottleneck. Hence you have an organization where everybody helps out testing, i.e for each release. Like an Agile organization.

    On the Extreme level you have so much automation that you trust that all basic functionality will work and the testers can concentrate on monitoring the application in test- and production environments and use time on extreme testing techniques as you describe.

    In the real world with legacy code etc I guess an organization would be using all three techniques – hence manual testers will still be around for some time to come 🙂

  • Posted at 6:28 am, November 7, 2017

    Yes JP. Agreed 🙂
    I believe a mix of Advanced and Extreme are the most needed techniques now to add quality to the product/process when resources are scarce.

Post a Comment

Comment
Name
Email
Website