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 DevOps Value Stream Delivery for SAFe®
Sep 27, 2021

Digital.ai announces first end-to-end, AI-driven solution for the Scaled Agile Framework (SAFe)

Enterprise Agile Planning
The Digital.ai DevOps Value Stream Delivery for SAFe®, one of the only ...
Read More
Jul 27, 2021

Digital.ai Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning
Digital.ai, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
Contact Us