Skip to main content
Enterprise Agile Planning icon with arrows

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
Digital.ai Government Cloud
Apr 12, 2022

Digital.ai Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Digital.ai Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us