What a pleasure it's been to work with the testers at WorkForce Software! And this post on how they brought exploratory testing to the heart of development is inspirational. An excellent read from Edward, a software tester at WorkForce software, and full of insight. Thank you, Edward! – Simon Tomes, Co-Founder of TestBuddy
Exploratory testing is a type of testing that has gained much traction in recent years. Before taking on my current position I can’t say I’d ever had much exposure to this testing methodology. Since joining WorkForce Software I’ve used exploratory testing on a near daily basis in my role as a software tester.
We currently utilise an agile methodology to software development. We have a number of tight-knit development teams, who all commit to completing work stories within a fortnightly sprint. Our teams complete all their feature and regression testing in-sprint and release code to our production environment at the end of this period.
Exploratory testing forms the basis of our current testing effort yet it wasn’t always like this. Previously the bulk of testing work comprised of stepped tests.
What is exploratory testing?
Exploratory testing provides a structured approach to searching an area of software to discover useful information. Traditionally, testers have used ‘stepped’ tests which require completion of one action after another to test any given functionality. This method requires extensive documentation, is highly inflexible and doesn’t allow a tester to go “off script”.
Stepped tests (noun): A testing approach to instruct testers to follow a set of actions whereby the result of each action is checked prior to moving onto the next action. Synonyms: test scripts, test cases, scripted testing, checks.
An exploratory test however, will define an area of functionality to search within as well as testing areas to focus on. It offers a structured approach to searching for potential issues whilst allowing the flexibility to enable testers to follow any insights about the software during a test session.
Challenges we faced as a department
WorkForce Software’s transition to exploratory testing was implemented as a response to significant challenges faced by the department. One problem was the lack of a standardised test approach. Testers would often conduct unstructured explorations outside of planned tests in order to view potential areas of concern. Because of the unplanned nature of these investigations they inevitably missed areas of functionality.
"A large amount of time was spent writing up test plans and documentation."
Testing couldn’t start until test plans were finalised and consequently feedback to teams regarding feature quality was delayed. Tests had to be re-written each time a new feature was implemented, adding to this issue. There was a strong appetite for a new way of working.
What we use exploratory testing for
As a department and a business, we use exploratory testing for different purposes.
- To test our features. We don’t require lengthy written documentation and this means we can now prepare and execute all our feature testing within sprint. Using this method also allows us to complete regression in-sprint too. This allows us to avoid the creation of large, brittle test plans requiring extensive review in favour of more lightweight documentation.
- We use exploratory test charters to leave a record of what’s been tested and testing results. This is useful for a number of stakeholders, including product owners, development teams and the testing discipline.
How we implement exploratory testing in our framework
At WorkForce Software, we use exploratory testing to complete much of our feature and regression testing within bi-weekly sprint cycles. During a sprint, exploratory test charters are created within our test management tool, then these are copied into a TestBuddy session and timeboxed, ready for execution. Timeboxing is important since it reminds testers to maintain focus on intended areas of functionality, preventing us from veering too far off track. It also enables effective scheduling of testing activities.
When the time comes for execution, we’ll document our results as we go, attaching screenshots of findings for further evidence. We also use the icons functionality, which allows users to record questions, ideas, bugs and praise. My personal favourites are the questions icon, as well as the praise, which enables a tester to point out when they observe good quality work, something we often forgot to do before implementing this test approach.
Once we are happy with the documented test session, we download a PDF document to attach to our test charter within our test management tool.
Benefits we've seen from exploratory testing
The benefits we’ve seen since implementing exploratory testing include:
- Less time spent creating test documentation
- Fewer issues found during final sanity tests before product release
- More extensive testing of our services, identifying bugs that wouldn’t have been found otherwise
These benefits required a culture shift over time and buy-in from stakeholders throughout the company, yet it's certainly been worth the time and effort.
The transition to any new testing methodology has its challenges and it doesn’t happen overnight. Yet if your organisation faces some of the challenges we’ve previously faced at WorkForce Software I encourage you to consider adopting exploratory testing into your organisation's testing repertoire.