Using VersionOne to Track Testing

OK, so now that we get the agile approach to capturing engineering challenges (Read part 1 and part 2 for a refresher), it’s important to see how this is done in VersionOne.  This is a pretty easy thing; let’s take a look.

First, remember the scenario we are talking about … as someone who is validating a story, you encounter something that just doesn’t look right.

Step 1 – Update the status of the Acceptance Test that I’m working on. This is an easy thing in VersionOne, on the Testboard, simply drag-n-drop the Test card to the right Status column.

Testboard Status Change

Step 2 – I may choose to capture a screenshot and some notes surrounding the scenario I was testing. To do this, I’m going to leverage one of the screen capture utilities available such as Awesome Screenshot plug-in for Chrome or Snagit. These utilities allow me to capture what is in my clipboard and upload it into a story in VersionOne.

I’m also going to add a Conversation to the original story.

Step 3 – Instead of logging a bug, I’m going to talk to the developer(s) responsible for assembling the story. If the developer was not available to talk, then I’m going to flag that story on the Story and/or Task board to show that as of right now, that story will not be able to be finished by the end of the sprint. The easiest way to do this is to Block the story with an Issue of type Engineering Challenge. To do this, from one of the boards select the drop-down action menu on the Story and select Block > With New Issue. Add the issue details and be sure to select the right Type.

Adding a Blocking Issue

Step 4 – Once I talk to the developer(s), we’ll make the determination if we just need to add another task or if it is something the developer can resolve as part of the current tasks. Here I’m showing how to add a new task to the existing story.

New Defect Task

We may bring the Product Owner into the picture and discuss if this is a missed requirement; thus, maybe it’s a new story, or it is a defect that really does need to go in the backlog. In either case, I would be creating a new item in the backlog.

Step 5 – After we’ve established what we are going to do about the engineering challenge, the team can decide together whether to remove the blocking issue now that we have a plan or wait to remove it once the failed Acceptance Test has been passed. To remove the Blocking Issue, simply click on the exclamation point icon on the board, and then click on the Remove button next to the correct Issue.

There are a couple alternatives to the above items:

On Steps 1 and 2, you could move the Status of the Acceptance Test to “Re-run” and create a new Acceptance Test that describes the failed scenario. This is a good practice to remind the team that a specific scenario failed and needs to be re-tested. It also is a good way to document the failed scenario.

With Step 3, you can choose to use the same Issue for all Engineering Challenges. I like to use the same Blocking Issue for each Team. This allows the team as well as the ScrumMaster and the Product Owner to easily keep track of the solution and/or code challenges the team is having.

This entry was posted in Developer, Product Owner, QA Tester, Sprint Planning & Tracking, Test Management. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>