Exploratory Testing | ALM Features | SpiraTeam

Exploratory Testing

SpiraTeam includes a dedicated exploratory testing mode where you can create and edit your tests on the fly during testing. It also includes tools for tracking follow-up activities between the developers and testers.

What is Exploratory Testing?

Exploratory testing is a useful approach, used in software testing that is about exploring - finding out about the software, what it does, what it doesn’t do, what works and what doesn’t work. The tester is required to make decisions about what to test next and where to spend a specified amount of time. Exploratory testing is most useful when there are unclear requirements (e.g. early in an agile sprint) or where you want to find the unknown issues that have not been uncovered by more formal testing methods.

The planning involves the creation of a test charter, a short declaration of the scope of a short (1 to 2 hour) time-boxed test effort, the objectives and possible approaches to be used.

Creating and Executing in Parallel

One of the key features of exploratory testing is that the test design and test execution activities are performed in parallel typically without formally documenting the test conditions, test cases or test scripts.

SpiraTeam lets you create an empty test case with the special type ‘exploratory’ and then during execution, you are free to edit, delete and add test steps at the same time as execution.

The drag-and drop editing lets you reorder the test case actions “on the fly” while entering the actual result and other notes and observations that you found during testing. Test logging is undertaken as test execution is performed, documenting the key aspects of what is tested, any defects found and any thoughts about possible further testing.

Recording Findings and Assigning Tasks

When a traditional test case fails, you normally want to log a defect/bug, linked to the test result. This makes sense for scripted tests because a failure means that the system does not work as designed, which is clearly an issue. However, in the early stages of a new agile Sprint, the requirements may still be evolving and therefore it may not be apparent what "working as designed" even means. So instead of logging a bug, the new exploratory mode will let you log a project Task instead, linked to the original requirement.

That allows the developers to manage their workload and communicate back to the tester when they are completed developing that unclear feature and the tester can try testing it again.

Questions? email or call us at +1 (202) 558-6885