TFS 2013: How to mark task as tested?

Question

We started using TFS 2013 as bug tracker some time ago (about 3 months). Before this we used TFS only as source control (bug tracking was performed in another software). For now we have developed some processes. We would greatly appreciate any comments, that would help us to understand, whether this processes are right, or not. So, here they are:

General info:

• We are developing one big product.
• Our team has 5 developers and 2 QA's.
• Often we release new versions each 1-2 months.
• We have 1-week sprints.

This is how we use TFS:

• We have one team project and a number of areas in it. Each area represents some part of the product.
• Our team project uses Scrum 2.2 template.
• In the team project we create a "big" iteration for each release (e.g. "Release 01.2014", "Release 03.2014"), which starts from the end of previous iteration and lasts 1-2 months.
• We use 2 standard work item types: Tasks and Bugs
• All bugs and tasks belong to the appropriate "big" iteration and area.
• We use tasks in 2 ways: as a standalone work item for any improvements and new features, and as the child of a bug when fixing a bug.
• To monitor current situation we created a bunch of queries for TWA. Some of them are shared (Such as "Bugs new","Bugs for testing", "Tasks in progress" and others), and some of them are created by each dev/QA (e.g. "My tasks in progress", "My bugs done" and others).

Here goes work process description for Bug:

-->QA (or dev) creates a bug (State: New)
-->QA (or dev) assigns this bug to some dev (State: Approved)
-->When dev starts to fix a bug, he does the following:
---->changes state of bug to Committed
---->creates child task and changes its state to InProgress
-->When dev commits some code, that should fix the bug, he bounds checkin to task (created on previous step)
-->QA understands, that bug is fixed and ready for testing, when bug is in Committed state and EACH child task is in Done state
-->QA tests fixing of bug:
---->if bug is not fixed he changes state of bug to Approved
---->if bug is fixed he changes state of bug to Done

This process looks not bad, and somehow works. But there is a problem with standalone tasks, which is created for improvements and new features.

And here goes process description for standalone Task:

-->QA (or dev) creates a task (State: ToDo)
-->QA (or dev) assigns this task to some dev (State: ToDo)
-->When dev starts working on this task, he changes its state to InProgress
-->When dev has finished working on task, he changes its state to Done
-->QA tests this task:
---->if new features work fine ?
---->if new features work with errors ?

Here is the main problem: how can QA mark Task as passed or not passed the tests? How we resolved it for now: QA's marks tested tasks with tag "Closed", if all is ok, and creates child bugs for task if there are some errors. But working with tags this way seems not to be good.

EDIT One more question: Which state of Bug/PBI is most suitable for state, when bug was assigned to developer, but he did not started working on this bug yet?

Any comments and suggestions will be greatly appreciated.

Answer 1

You are not using the Scrum template as intended.

The typical approach is to use Product Backlog Items to represent features, and child Tasks to represent the work necessary for PBI's or Bugs.

Teams will often have one (or more) tasks that represent the testing work that needs to be performed for each PBI/Bug. Then you can track if testing is done or not by looking at the status of the tasks.

Answer 2

Maybe more work/overhead than you're interested in investing, but have you looked in to using the "Test Case" workitem type? A couple fancy things about Test Cases:

• They can be attached to a Task to specify the task is "Tested by" that test case
• They can have results, making the definition of the test reusable across iterations
• There's a bunch of built-in reporting for showing what the current status of testing is (passed vs failed vs not run, etc)
• There's even UI for entering test results and managing test cases in the TFS web interface
• Tests don't have to be automated, but it's nice if they are. You'd get all the above benefits even if you're only using "Manual" tests

More info here: http://msdn.microsoft.com/en-us/library/dd380763.aspx