4. Implementation and testing phases (for all users)

The implementation and testing phases cover the biggest part of the project lifecycle and concern all users. Typical activities in the implementation and testing phases are reading specifications, implementing tasks, reporting bugs and fixing bugs.

4.1. Viewing specifications, tasks and bugs

Before starting any tasks all project members should have a grasp of what the project is about. This information is gained by attending to meetings and by reading the specifications of the project, stored in Sirid. The specifications are available, quite presumably, on the project Specifications page.

There are various different ways of navigating to places of interest. One generally easy way is to use the quick menu on top of the page; simply select the project and page of interest and press Go. Another typical way is to go via the Projects menu.

From normal user's point of view the system consists of two types of tasks and bugs: Those that you're responsible for and those you're not. The tasks and bugs you are responsible for can be seen on My tasks and My bugs pages. Other tasks and bugs can be seen on the appropriate project's Tasks and Bugs page. More detailed information of any entry can be seen by clicking on its title.

4.2. Implementing tasks and fixing bugs

When a task is being implemented or a bug is being fixed its status is usually changed multiple times from one state to another. The status of a task can be changed via the View task page and the status of a bug respectively from the View bug page. Typical phases of a task implementation could be like this:

1. Mary starts implementing a task created by Jack. Mary changes the status of the task to "In implementation" and possibly writes some comment.
2. Mary finishes the task and in her opinion it seems to work as required. She changes the status to "In testing", specifies the amount of time used for the implementation, and writes some comment about what she has done regarding the feature. She also sets Jack as the head responsible of the task and chooses that an email notification of the status change should be sent to the responsible persons.
3. Jack gets a notification that the task is now in testing and that he's head responsible for it. He tests how the system works and notices that something does not work as he had intended. He changes the task status back to "In implementation" and writes a comment in which he explains what part of the task was not correct. He also changes Mary back to the head responsible and chooses to send an email notification to the responsible persons.
4. Mary gets a notification that the task is back in implementation phase and reads Jack's comments regarding what was done wrong or wasn't done at all. She fixes the parts issued by Jack and does the same as in step 2.
5. Jack gets again a notification that the task is in testing. He checks how the system works and sees that everything works fine this time. He then just changes the status to Done which causes the task to be omitted from the My tasks list of any responsible persons and there is no need to do anything further regarding the task, unless it is re-opened later on.

Same kind of process goes for bugs. Of course, depending on the project and the operation mode of your company, the process needs not be this formal and some steps can be left out.

4.3. Reporting bugs

When you find a bug in a project you have "Report bugs"-access right to, you can press the "Report new bug"-link to report the bug. You should, however, first verify that the bug has not already been reported. You can do this by either reading through the (titles of the) bugs in the project or by using the search functionality to search for bugs that might address the same bug you're about to report.

It is important to fill all fields with care for the responsible person to be able to understand how exactly the bug comes up. The title is naturally essential - it should immediately give a grasp of the bug while being concise enough. The description and how-to-repeat fields are none the less important. Fixing a bug is usually dramatically easier when the responsible person can reproduce it. If there is no simple way of reproducing the bug the description should be elaborative enough for the responsible person to make an educated guess of what could cause the problem.

Regarding the responsible persons, the same rule applies as with tasks: There should be only one head responsible because often "shared responsibility is the same as no responsibility at all." If you do not know who should fix the problem, you should first try to determine that by the job descriptions of the staff members and if you are still uncertain choose the project leader or equivalent who can then "forward" the bug to the correct person. For more information regarding responsible roles, see chapter 1.3, Responsible roles.

After you have reported the bug you can add attachments to it via the View bug page (providing you have the "Add attachments"-access right to the project). The attachments for bugs are usually log files and screenshots but the format of the attachments is not limited in any way.

4.4. Timesheet

The timesheet is a place where you can centrally record your efforts and see what you have done in the past. On company level the timesheet functionality can be used to assist in billing the customers and calculating the salaries of employees.

By clicking a date in the calendar, you can see your efforts on that day. Pressing the Add time link will add an entry to the selected day, thus allowing you to add entries also to the past when necessary. In addition to adding task and bug related time (change task status and change bug status), you can add project related time. Project related time should be used when your work is not related to any task or bug in the project.

The time tracking functionality enables you to search your time usage in the past. Normal users can only track their own efforts while administrators and accountants can also search the time usage of other users.