Exploratory Testing in Agile

In computer hardware and software development, testing is used at key checkpoints in the overall process to determine whether objectives are being met.

There are many different types and methods of testing.

So, where does exploratory testing in agile fall?

Many wonder if exploratory testing is important. As a Quality Analyst (QA), I would like to assert that, yes, it is an essential part of testing. Many people are confused by exploratory testing and agree with one or more of the following statements:

• Adhoc Testing: Something done without a plan.
• Experience Based: Only those with good experience in testing can perform exploratory testing.
• No Product Knowledge: When you don’t know the product enough, you do exploratory testing.
• No Specs: When there are no requirement documents, exploratory testing is useful.
• At the End of All Testing: When there is time left after doing all types of testing, exploratory testing is done

Exploratory testing is a formal approach of testing that involves simultaneous learning, test schematizing, and test execution. The testers explore the application and learn about its functionalities by discovery and learning methods. They then use exploratory test charters to direct, record, and track the exploratory test session’s observations. It is a hands-on procedure in which testers perform minimum planning and maximum test exploration.

Here, the tester is at the center. There is a continuous process that he/she undergoes. The activities like learning, planning, executing and recording happen simultaneously. If we separate these activities, then it becomes a scripted testing.

So, if you have a feature to be tested, here are two approaches:

Approach 1 – Scripted testing:

• Understand the feature using requirements documents/user stories/ wireframe etc.
• Write detailed test cases and acceptance criteria.
• Start testing by executing the cases in order until you complete all the cases. Mark the ones as pass or fail.
• File bugs for the ones that failed.
• Write a test case for the failed ones.
• Reverify and retest the build with fixes and release.

Approach 2 – Exploratory Testing in Agile

• Understand the requirements document/wireframe/user story.
• Consider it as one of the references, and search for more references. Understand the use-case of the feature, talk to the stakeholders, interact with the product.
• Create a lightweight document of test ideas, feature maps or product coverage outlines.
• Come up with more questions to understand the context better.
• Interact with the product, note new test ideas, file bugs, and issues, update product coverage outlines and it is a loop.
• If some ideas don’t make sense, discard and replace them with meaningful ideas related to the risk and project context

In Approach 1, the script dictates what you do. You will execute all the cases in order, even if you know that you are not learning anything about the product. This is an example of the Scripted Approach to testing.

In Approach 2, the tester decides what to do. There is continuous learning and the learning highly influences the next test from the previous test. This is an example of an exploratory approach to testing.

Before starting exploratory testing, one must keep in mind the following things:

• Product Quality Assessment.
• Keeping track of issues raised during this type of test.
• Write test cases by observations gathered by going through an application.
• Execution of test cases.

If there’s a testing type that offers full, genuine freedom to the tester, it’s exploratory testing. Without any documentation or preliminary planning, the QA engineer tests the software to verify its overall quality. The trick is in the tester’s skills, experience and ability to invent test cases and find bugs “on the go.” In my next blog, I will cover how Scrum & Exploratory testing go hand-in-hand!

Author: Nandini Rao | [email protected]