©Truefit. All rights reserved.
©Truefit. All rights reserved.
When building or enhancing software, there is never enough time to accomplish everything that needs to be done. You may not always have the time or resources to dedicate to regression testing. Choosing this path can cripple your project with technical debt, creating a spiral of increasing cost.
At Truefit, we work in a fast-paced, agile environment where QA Analysts work alongside the developers inside of the sprints. There is no handoff. It is a constant flow of communication and collaboration. We write test scenarios for each story. These test scenarios are followed and must pass in order for the story to be considered complete. Regression testing the entire applications is also completed several times throughout a typical project.
It can be easy to fall into the trap of only testing each story as it was implemented, therefore missing bugs that were created in other areas of the application. It isn’t always clear to QA that the development team may have added code in other areas of the application and if that code had impacts on other areas.
While most development teams, ours included, utilize various forms of automated testing to reduce the risk of integration and regression issues, these tests aren’t always foolproof. At Truefit, our QA team is responsible for providing an additional layer of testing on the product in order to ensure the highest quality.
Often, QA teams rely on full-scale regression testing to solve this issue; however, regression testing is typically expensive, slow, and is often not done until later in the project. As a result, regression testing isn’t performed often enough and the risk of finding large numbers of bugs late in the project is significantly higher.
We wanted to find a way to more thoroughly test the application during the sprint without being bogged down by full-scale regression tests all the time. So we implemented the use of exploratory testing as a form of mini regression testing throughout the sprint.
Exploratory testing is exploring the software, learning how it works, finding out what makes sense and what doesn’t make sense, what works and what is broken, etc.
When our team is performing exploratory testing during the sprint, we already know how the software works. We decided to expand this “exploring” and look at the software in a new way. When a developer adds a new feature to the application, the QA Analyst needs to start to think “What does this affect?” and then start exploring around those possible affected areas. We also think about the software from different users’ perspectives. For example, how would an admin use the software versus how would an employee use the software?
Some key places where exploratory testing can be helpful are:
Typically, when working with a complex, time-sensitive, and budget-constrained project, QA Analysts are not as concerned with testing outside specific scenarios. Remember, this kind of testing up front will save in bug debt paid by the remainder of the project. It does not replace the need for full regression tests, but it does allow for new sprint work to be tested while we are reviewing the effect of this new work on older code.
Getting started with exploratory testing as mini regression testing is easy. During your next sprint, look for stories that may affect the system in areas beyond the user story that you are testing and begin to explore the areas of the system that you think may be impacted. There’s a good chance you’ll find issues in the system that would have otherwise gone unnoticed.
