Many testers treat manual and automated testing like they are oil and water – they don’t mix. However, in practice, I have noticed that many successful long-term projects use a mixture of exploratory testing and automation to provide the best possible coverage for any scenario. For example, exploratory testing is needed to fully explore the depth and breadth of a feature, and to create test cases so that they can be automated for regression. Careful automation of regression allows testers to free up their time to perform meaningful manual tests.
Get TestRail FREE for 30 days!
Manual Testers and SDET’s: Stagnation by Separation
If we propose that manual and automated processes go together, then just how does that look? There are testers who happily work doing only manual or only automated testing, yet this kind of separation of knowledge only keeps testers stagnated because their toolset is necessarily limited by their experience.
Manual and exploratory testers who never look at or touch code don’t understand the inner workings of the product on which they work. This means that they may find bugs, even great bugs, but they will have a harder time thinking of further test ideas that might expose deeper issues or identify a root cause.
Meanwhile, the SDET’s who never do anything other than write automation scripts can lose sight of how the feature for which they are writing automate fits into the whole. What is the function? How does the automation provide value? What is the priority of the feature? For the SDET who doesn’t interact with the product with a user mindset, these broad but important considerations may be lost.
Becoming One: Expanding the Testing Toolbox with Manual and Automated Strategies
In today’s climate of “more automation, more machines, less humans”, it’s easy to get carried away by a CTO who might not understand the value, let alone necessity, of exploratory testing. Many cash-strapped teams see developing automated regression as the best value for their testing dollar.
On the flipside, it can be hard to convince manual testers to open their toolbox and spend time outside of their comfort zone learning to write some automated scripts to aid them in repetitive tasks. Both manual and automated testers can benefit from some understanding of the work that happens on “the other side”.
Gaining Automation Skill
If a tester is doing solely manual work, they should begin to learn about how the automated tests run, what kinds of things are already tested in unit and automated tests, and how frequently automation is run. This allows the manual tester to help design regression cases that will be useful to the product, and to save their valuable test effort for areas that are not testable with automation.
To build skills in automation, testers should look within their organization for some of the following:
- Access to unit and automated test code
- Paired testing time with a developer who is writing unit tests for a feature that she will be testing manually later
- Paired testing time with the SDET writing the automated regression (if any) for the feature
- A walk-through of the test running and reporting systems used by the organization
- Other ways that automation are being applied to testing (load testing scripts, accessibility testing tools, security scans, continuous integration and deployment)
Gaining Exploratory Skill
The SDET who only writes automation should spend time performing exploratory testing, in order to keep familiar with how users are interacting with the product, and to better understand the parts of the product that can be easily tested with automation. There are some meaningful ways that an SDET can use exploratory testing skill in their practice:
- Paired testing time with manual tester to observe an exploratory testing session
- Paired testing time with a manual tester to observe manual regression
- Attend sprint-planning or three-amigos meetings to learn about acceptance criteria for a feature
- Learn how manual/exploratory testing efforts are recorded and reported
- Learn about the kinds of testing that must be conducted manually (some security tests, penetration tests, accessibility UX testing, some load testing)
The continuing debate over whether or not manual testing has value in a world of increasing automation is as tired as the idea that only skilled manual testers can bring value to a project. The truth is that computers do repetitive tasks like regression better and with more accuracy than humans, while humans bring the nuance and analytical skills necessary to determine how to push a feature to a breaking point in ways that cannot be predicted or programmed.
Employing a strict automation strategy is guaranteed to miss major bugs, because a computer cannot find what it is not told to look for. Meanwhile, employing a strictly manual strategy is a recipe for burning out testers on boring, repetitive work that does not utilize the broad capabilities of problem solving and investigation available in the human mind.
The best testing strategies will employ both manual testing and automation approaches that focus on the goals that testing is trying to accomplish for the product.
This is a guest posting by Jess Ingrassellino. Jess is a software engineer in New York. She has perused interests in music, writing, teaching, technology, art and philosophy. She is the founder of TeachCode.org
Test Automation – Anywhere, Anytime
- How Leading Teams Integrate Test Automation with TestRail Test Management
- TestRail Confluence Test Management Integration
- Consider “Reasonable” UI Test Automation
- TestRail Highlight: Test Management Project History and Test Case Versioning