We will implement a set of reports for TP 2.x. Additional statistics will be provided to users of the system. It is not bad to know about bugs count distribution, user stories dynamics and so on. Everybody knows that the analysis of project execution is an important part of the development cycle. So we will help with providing the data and information supposed to be analyzed. The draft of the bugs count distribution report is provided below

Trail Ridge Consulting published Management Tooling Survey results. It is quite interesting survey that shows how companies use APM tools and indicates some future trends like bug tracking integration, test cases management integration, IDE integration. The main trend for TargetProcess is that "APM tooling adoption will continue to rise" :)

Also quite many people that use APM have problems with user interface and too many features. Hope we will manage to resolve both these problems. TP has customizable UI and it is possible to hide most unused areas, thus having very simple UI.

It is not a secret, at least for target process team ;-), that the workflow of assignable entities (user story, bug and etc.) can be customized in TP 2.0. In other words the lifecycle of user story or bug can be changed in order to match the process used in your company. Let’s see how the possible workflow of the user story can be applied to TP 2.0. Here is the original workflow below:

As you see the following actors can be found in the workflow above:

• Manager
• Customer
• Developer
• QA Person (Verifier)

The state of the user story staring from opening till closing is the following:

• Opened
• Approved
• Implemented
• Verified
• Closed

Let’s reproduce this workflow in the TP 2.0. The following workflow is provided in TP 2.0 by default:

There is only one actor for user stories - Developer(s). The opened user story is assigned to developer and he makes it done after implementation. In our original workflow we have four actors. We need to add Customer and Manager (Verifier is provided for bugs so we don’t need to add it to TP 2.0). The screen of the managing actors looks like the screenshot below after adding required actors:

Now we need to add the required states for the user story. Let’s do it using Admin -> Workflows -> Manage States for User Story entity.

The final screen of the user story workflow is the following:

The User Story Add/Edit Form looks like the form below after applying changes for the workflow above:

As you see the required actor can be assigned and the required effort for every actor can be provided right from the US adding page. Looks like TP 2.0 workflow can be changed in order to meet the different processes. We do our best to make the workflow agile…

Test Cases Management will be included into TP 2.1. There are several significant changes in comparing with TP 1.7.

Test Case

Add/Edit Test Case Page is improved. The possibility of attaching files (images, docs and etc.) is provided as well as possibility of adding custom fields to test cases. The custom field can be added through Admin Area as well as for User Stories, Iterations and other general entities.

And Test Case Form .

Test Plan

The test plan is a container of test cases. The custom fields and attachments are available for the test plan entity as well. The test case can be included into several test plans using Assign Test Cases Page.

Test Plan Run

The test cases in test plan should be run for iteration, release or build by QA person. The test plan run (Tests run) is designed for this purpose.

The QA person can be assigned to test plan run and it will appear in his ToDo.

The list of test plan runs for every test plan can be found in test plans list.

I want to highlight that the workflow of the test plan run can be changed. Test Cases Runner

The Test Plan Run can be executed using Tests Runner. Here is the screenshot. Test Runner shows all test cases for current run, it is possible to navigate by test cases and mark them as passed or failed. Moreover, TC Runner remembers last checked test case and it is possible to continue run tomorrow.

The UI elements of the Test Cases Management are under development now. The business logic of this practice is almost completed.

Almost any web application requires batch actions like delete all selected items, move them or something else. TargetProcess is not an exception and we've implemented batch actions in TP 2.1. However, we've tried to not burden UI with one additional column and introduced "Batch Mode" for lists.

So in usual mode there is just one additional link "Turn On Batch Mode" on UI. When user clicks on it, check box column appear as well as batch actions menu (which contains Delete and Copy actions for now).

Batch processing results are clear as well:

If you have ideas about other helpful batch actions (except Delete and Copy), please, add your comments!

Finally we are going to add Subversion integration in TP 2.2. We think that it will slightly improves productivity of developers and make Code Review practice more pleasurable.

Developers usually do several steps to fix a bug (even very small)

1. Open a bug from TP dashboard to view it’s details
2. Fix the bug
3. Commit (check in) code into repository with a proper comment (for example, bug name and ID)
4. Add spent time record into TP (not necessary, but improves statistics)
5. Change bug state to fixed (usually with the same comment as was submitted to repository)

We think it is possible to remove step 4 and 5 by making some integrations with common Source Control systems. The main idea behind is that Developer can add additional information such a bug ID when committing files. It may looks like "Fixed bug #243. Added boundaries check to prevent exception. Time: 4h". TP will parse this log message, extract from it Bug ID, close the bug and create associated time record if necessary. So developer will not need to do the same thing in TP.

Another advantage of Subversion integration is that it will be possible to check all modified files for particular bug or user story as well as differences between revisions. Why is that required? For example, experienced developer may check how junior developer fixed the bug (if there is no pair programming practice in team).

Time Tracking Practice was included into TP 2.0 in order to give the possibility of tracking the actual progress of the development. In other words PM can see the status of the User Story, Task or Iteration at any time of the development cycle and as a result some actions can be performed to prevent the possible iteration or release shift.

The time tracking makes the life of PM easy. But it is not the same thing for developers. For example I spent 8 hours yesterday on implementing two different user stories. I need to keep in mind that I spent 3 hours on implementing User Story #1 and 4 hours on implementing User Story #2. Also I spent 1 hour on our daily meeting. It is not very convenient to post the time tracking form three times and then verify the time list in order to know that the summary of spent time is correct and equal to 8 hours.

It is more comfortable to have all mine activities on one list with the possibility of providing the time statistics. Please find the time table concept below.

It is supposed to make TP 2.x Time Tracking Practice more powerful and useful with the Time Table Feature.

On Friday we’ve started Test Cases module development. It will have some nice new features that where requested by many people. First of all, there will be test cases library – general test cases storage. It will be possible to copy test cases from library to project and vise versa. Usefulness of test cases library is obvious. For example, almost all web applications have login form and authentication mechanism. Test cases for such functionality are almost the same, so it is natural to create them once and use for all relevant projects.

The second highly requested feature is ability to assign the same test case to several test plans. It was not possible in TP 1.7, but will be added into TP 2.1. The reason is that often you need to have two test plans for one feature: one is smoke test plan and second full test plan for example. So you have to assign the same test case to both test plans.

Some additions will be made to enable time tracking for test plans execution and we’ll likely improve Test Runner to make it more usable. Other features will be almost the same as in TP 1.7 since people really liked how test cases module works.