Human Testing is a craft that is more than executing a bunch of tests, performing clicks and actions. A tester has a unique understanding of the system and ways to critique it. Over time, the tester develops a deeper comprehension of the application and its intricacies, integrations, weak points, and history. This makes them the best judge to find out the failure points of the system and comment on its health.
The Product Risk Knowledge Gap is the difference between what we know about the product and what we need to know. The purpose of testing is to close or at least reduce this gap.
While automated checks can help in determining problems in what we know (and have scripted as checks), it may not help as much in the risk areas of what we do not know about the product. That requires exploration, creativity, intuition and domain knowledge. This is the human aspect of testing.
The creative and human aspects of testing lie with the tester, which I have experienced as well as written about a few years back as a hands-on tester myself here – https://testwithnishi.com/2014/12/31/automation-test-suites-are-not-god/
Automated scripts have some built-in steps in the form of test data that we pre-define and verifications that we add. These steps are helpful for areas of the application that we need to check, double-check or re-check a number of times, and because these types of checks can be made explicit, they can be automated. Since the same steps will be performed the same way over and over again, it is better called “checking” rather than “testing.”
The skill of test automation has garnered much interest in the testing industry, so much so that it is now considered an in-demand skill without which a tester may become irrelevant. Many testers are scared of the fact that not being able to write code or test scripts would render them useless to their teams. But this is actually not the case. Testers are not defined by their tools, just like developers are not defined by their programming languages or IDEs.
While being able to write and understand code or create automated scripts are useful skills for a tester, we must look at the differences in the mindset of a coder vs. someone who does not code.
They think differently and perceive the same software in a different way. Non-coders have a user-centric mindset and usually a higher level of empathy for the users. So, while we do value being able to read, understand and analyze code, the human aspect of testing cannot be negated.
Creating a balance of human testing plus automated checks is the best way to get ROI on our test automation efforts. Here’s how we can make an effort to strike that balance:
- Understanding what needs to be automated instead of running behind a coverage percentage or numbers.
- Automating only what is really needed and using human testing for exploration.
- Making conscious decisions rather than struggling with technical debt.
I wrote about the Partnership of Testing & Checking in my latest article for TestRail website. Read the complete article at https://blog.gurock.com/partnership-testing-checking/