July 10th, 2017 by Adam Sandman
We are busy bees this summer, and one of the most exciting new features of SpiraTest (and SpiraTeam of course) is the fact that we're adding support in SpiraTest for exploratory/session-based testing. This article outlines how this new functionality will work and explains what will be possible in SpiraTest, and what additional features will be in SpiraTeam (hint integration with Task Management!)
As we mentioned before, the new exploratory testing mode will let you write and execute test cases at the same time, with the ability to create tasks for developers (if you are using SpiraTeam) to create/change functionality where the tester finds unexpected behavior.
Write and Execute at the Same Time
SpiraTest was designed to streamline and optimize the testing process, especially where you have complex test cases and strong auditability requirements (e.g. in industries such as healthcare and finance). As a result, we designed it to not allow editing of test cases during execution, so that the results would be stand up to independent verification. In particular, when you have a large team of junior developers, it is important to be able to assign a set of tests and ensure that they are executed in their original form.
However when you start looking at more fluid testing approaches in agile development, especially with a smaller testing team that doesn't need the structure of formal test cases and has a robust set of automated checks to handle a lot of the basic smoke testing, what you need is a way to explore and document the failings in the system whilst the requirements are evolving so that you can communicate to the development team and still have a way to retest after the fact.
To address these unmet needs and still provide the rich reporting and requirements traceability, we have added a new type of test case to SpiraTest called (originally enough) Exploratory Test, and when you execute a test case in this mode, you have a whole new execution interface:
In this interface, you can add steps, drag and drop to reorder them, clone them, delete them and enter/update the Description, Expected Result, and Actual Result. This gives you an alternate way of running tests that is suited to exploratory and session based testing:
The great news is that once the requirements become more solidified, they can be switched back to a different test case type (e.g. regression test) and then executed in the traditional way, and even automated using Rapise.
Create Tasks for Developers (SpiraTeam only)
For those customers using SpiraTeam, there will be an additional benefit. 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.
This feature is currently under development, so if you have questions, ideas or feedback, please write them in the Comments box below: