Exploratory testing in an Agile environment – Part 3 of 3

This post was written by Noy Bar from the Customer Success team.

 

In the first part of this three-part weekly series on exploratory testing in an Agile environment, we discussed what exploratory testing is, where it came from, and its characteristics.  The second part examined some of the practical aspects of exploratory testing, and this final part discusses when exploratory testing should be used.

 

When to use exploratory testing

James Bach, in his paper Exploratory Testing Explained, advised that exploratory testing and freestyle exploratory testing should be considered in the following situations:

  • When rapid feedback is required on a system, area of functionality, a feature, or an area which might be risky
  • When there’s a need to quickly get up to speed on new software
  • When you want to move beyond the scripts that have already been used for testing
  • When looking for the most significant bug in the shortest time possible
  • When scenario-based tests have already been executed but another opinion on the quality of the software is sought
  • When there’s a need to check out a specific bug
  • When there’s a need to determine if scripted tests are required in a specific area, by investigating risk in that area
  • When the end-user’s perspective is needed

Bach adds some other situations which are more relevant to exploratory testing (as opposed to freestyle exploratory testing):

  • When improvising on scripted tests
  • When understanding unclear test steps
  • During product analysis and test planning
  • When improving existing tests
  • When writing new test scripts
  • During regression testing of old bugs
  • When checking the user manual

 

Exploratory testing in Agile projects

Accelerated demand for both native and mobile software, coupled with frequent software updates and enhancements (as part of the Continuous Delivery model), has generated a need for faster development and deployment.   The software industry needs to react faster to accommodate new and changing enhancements, without compromising on efficiency.  Consequently, Agile development methodologies have become popular in organizations looking to lower their development time and support faster deployment to the field.

 

Agile methodologies provide, among other things, an answer to some of the requirements and demands that are not satisfied, or only partially satisfied, by the traditional Waterfall model.  But while Agile encourages accelerated development, its dynamic, ad hoc, iterative and fast characteristics make it tougher to set up a focused testing process.

 

The Agile model presents a significant challenge: deliver a high quality product early in the development stage, to allow early validation with the field while keeping both the flexibility to adapt to new requirements and demands, and its iterative character.

 

This diagram shows the Agile development process:

AgileModel.png

 

Agile, although essentially a project management methodology, mainly appeals to development teams.  The rest of the organization needs to adapt to the Agile model’s guidelines and limitations. This of course includes the QA department.

 

The move from the traditional Waterfall model to Agile introduces the following changes that affect the QA department:

  • The QA and development teams are working much closer together.  In some cases, QA is actually part of the development team
  • Cooperation and feedback between development and QA are key elements
  • QA have less time to test and present status and progress reports, but they must test and report more frequently in order to match the development schedule
  • Testers are expected to test the main path and critical paths of the software as it will be used by the end-user
  • Roles are becoming blurred, and stakeholders who used to work in a silo mode are now required to work with people in different roles as part of the same team

In an Agile environment, user stories (ie. software requirements written in terms of the user’s expectations from the software) are developed according to the priority that is assigned based on business and field considerations.

 

Once the development team has pulled the highest priority user story from the product or release backlog, the QA team faces new challenges which it didn’t need to deal with when using other development methods:

  • Testing must be performed as early as possible to lower the risk of late fixes that are more expensive
  • Test must be performed as frequently as possible to increase the chances of early detection
  • Testing must be optimized in order to perform the minimum tests required to achieve maximum coverage.

Some Agile teams use Test Driven Development (TDD). This is where the developer first writes a test, and only then writes the code that will cause the test scenario to pass.  Once the test has passed successfully, the developer will write another scenario which might include the previous scenario, and repeat the process.

 

TDD is a popular development methodology which raises the developer’s awareness of the need for reliable and high quality code. Nevertheless, TDD doesn’t cater for more complex scenarios where the tests approach the typical usage patterns that are carried out by end-users.

 

From the point of view of QA, every change in the system must be tested, whether it is an addition, improvement or defect fix. To lower the risk of late defect detection and the expense incurred by fixing them, these tests must be performed as close as possible to the point where the change is introduced.  In addition to those tests, QA still needs to perform more generic system tests to make sure the system as a complete unit still works as expected and that nothing was unintentionally broken during the last sprint.

 

One reason why exploratory testing is so efficient in Agile projects is that there is no need to invest time in authoring, preparing and approving test cases before the test session begins. As a result, the test process is much faster and more flexible, which is in line with Agile methodologies.  It also cuts down on unnecessary documentation – ‘working software over comprehensive documentation’ is the second value on the Agile manifesto.

 

In addition, the feedback on the software quality is so fast when using exploratory testing that it allows changing the strategy and focus by QA as required by development.

 

Exploratory testing with HP Sprinter

HP Sprinter is an easy-to-use solution for manual software testing, which provides extensive support for exploratory testing.  Here are some of the exploratory testing features that Sprinter provides:

  • Maximizes real estate for the application under test, and allows the tester to concentrate on the testing
  • Captures everything needed in order to report a defect, without having to go into HP Application Lifecycle Management or HP Quality Center
  • Defects don’t need to be entered into the system immediately.  As defects are encountered, Sprinter makes a note, saves all of the information required to report the defect, and allows the tester to to continue testing.  When the test is finished, all of the defects can then be entered into the system
  • Records and logs the tester’s actions as the exploratory test is executed.  Sprinter provides an extensive toolkit for capturing and annotating screenshots, as well as a screen recorder for capturing movies
  • Generates a formal manual test script based on the exploratory test, in order to ensure that the test can be repeated

 You might also want to check out this post, "6 steps to write test cases using exploratory testing methods” which describes exploratory testing with Sprinter in more detail.

 

 

 

Thanks for following this series of posts on exploratory testing in an Agile environment.  Leave us a comment in the box below to let us know how Sprinter helps you perform exploratory testing in your organization.

 

Thanks to Noy for providing the posts in this series!

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.