Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Sep 04, 2012 — Enterprise Agile Planning expert

Agile Approach to Problems Found While Testing “In Sprint” Stories (Part 1 of 2)

Enterprise Agile Planning

 

Agile Testing Hotshot ElevatorPicture this, hotshot… You are working on a team that has recently made the transition to agile development. You are a traditional tester. A developer just let you know that you can start testing the story that the two of you are working on during the sprint. You start working through your test cases, and “BAM!” you found a problem; what do you do?

Ok, well if you stick to a traditional development approach, you would create a defect in a bug tracking system, spend some time documenting the replication steps, create and attach screen shots to the bug, add test data to the bug, and then either notify the interested parties or just let the bug tracking system do that for you. At this time, it’s usually up to a development lead, project manager or business analyst to review the bug and determine if it is really a bug. If it is, they would assign it to a (or the) developer to fix and you (as the tester) may create a new test case to verify the bug is fixed, as well as re-execute the original test scenario.

Now you’re saying, “Matt, what’s wrong with this?” And I will say, “Nothing, if you don’t care about finishing the story or delaying delivery or incurring technical debt or just putting out crappy product.” Maybe that’s going too far, but what this approach does is a number of things:

  1. It instantly puts up a barrier between the Developer and the Tester of a story. If not by introducing the intermediary process, but by simply calling it a “bug.”
  2. It promotes throwing bugs surrounding a story back into the backlog, thus requiring the team to find some way to associate the two (creating administrivia) and requiring the intermediary step for someone to evaluate the bug and decide when it needs to be fixed.
  3. The latter part of #2 is the biggest problem. If we find a problem with a story being implemented and then make a decision about fixing it, then we are doing two things — letting the process possibly delay just getting it done AND we are setting ourselves up for delays and debt.
  4. Finally, the approach may introduce waste surrounding the documentation of the issue.

Check out Part 2 of this discussion, where I’ll cover how the process of software testing looks different in an agile development environment – and what this change can do for you.

 

The post Agile Approach to Problems Found While Testing “In Sprint” Stories (Part 1 of 2) appeared first on VersionOne Blog.

 

More from the Blog

View more
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Jan 27, 2021

Improve visibility, reduce costs, and take back control of your scaled out container and cloud deployments with the latest releases of Digital.ai Agility and DevOps solutions

Enterprise Agile Planning
We’re thrilled to announce the latest releases of our Digital.ai Agili ...
Read More
Contact Us