The following guide provides a basic TyBugs workflow for an external tester, either as a member of the general public or as a participant in a private testing group.

My Tasks

Upon successful login to your TyBugs account, the “My Tasks” list will open automatically. This list shows all current tasks that require your attention. On your first login, this list will generally be blank. As you being to work with the system, the list will grow to include any tasks that you have entered but not yet dispatched for processing, and also any tasks which have been sent to you for further processing.

The rule of thumb is that if a task is listed in your “My Tasks” list, it requires some action on your part.

If you wish to filter your tasks, or view tasks not assigned to you, a popup menu button is available at the top left of the task list. Click here for a detailed discussion of filters.

The task list view can be customised by dragging or right-clicking on the column headers.

Bug Reporting

To report a bug, right click on any task window and select “New Task” from the contextual menu. A new, empty task is created and its task details window is opened for editing. You should fill out the task fields as follows:

“Summary” – Provide a short description of the problem that you encountered. This should be sufficient for another user to understand what the task is referring to.

“Details” – Provide the full details of the task. For bug reports, be sure to indicate the full and exact steps that must be taken in order to reproduce the issue. Do not assume that the person reading the report is using the same configuration as you or makes the same assumptions about how to achieve a particular step- explicitly detail anything that may be relevant.

“Comment” – Leave this field blank when making your initial report.

“Branches” – Add the branch in which this task is required. For requests, indicate where you wish the request to be considered. For bugs, indicate the product/version in which the bug was found. It is possible to add multiple branches if required. It is generally required that at least one branch is specified.

“Assigned To” – Once you’ve entered all the necessary details, use the ‘Assign’ button to assign the task to <nobody>. This causes the task to be available for processing by the project administrators. Until this step is taken, the task will remain on your “my tasks” list even if you close the task’s edit window.

“Attachments” – If necessary, attach any necessary files in this tab. This is typically used to attach screenshots or small crash reports. Please do not attach large or unnecessary files.

Editing Existing Tasks

You don’t need to assign a task for processing immediately. All new tasks are created in your own task list (ie. assigned to you) and while it’s assigned to you, nobody else will work on it. Feel free to hold on to a task, closing and reopening the task’s edit window whenever desirable, until you have gathered all the necessary details are are ready to assign it on.

Task changes are saved back to TyBugs when the task’s edit window is closed or the lock icon is placed in the “locked” state. If you’re going to be editing a task over a long period, it’s best to save it occasionally by closing the edit window while it’s not in use. You can reopen the task for editing by right clicking on the task in a task list and selecting ‘Edit Task’.

You can view an existing task by double-clicking on the task in a task list. The task will initially be locked to prevent accidental edits, but if you want to make edits then you can set the lock icon to the “unlocked” state. While you are editing a task, all other users are prevented from editing the same task. For this reason, please avoid editing tasks unnecessarily.

Request for Additional Details

If the project personnel require additional information, they will typically reassign the task to you with an appropriate request in the comment field. The task will reappear on your “My Tasks” list until you take additional action.

Common requests include:

• Requests for additional detail, especially where you’ve used vague or misleading terminology in the “details” field, or where the description in your “details” field contradicts other fields in the task. Additional details should be entered in the “details” field, not the “comment” field.
• Requests for additional attachments.

Once you have fulfilled the request as best possible, please assign the task back to <nobody>. If you are unable to fulfil the request properly, feel free to add a comment explaining what you have or have not done. This explanation should go in the “comment” field.

Don’t feel that you have to fulfil such requests on the spot. It’s better to hang onto the task for a short time while you collect the appropriate information, rather than submitting partial information. Remember that you can repeatedly edit the task to update details until you assign the task back to <nobody>.

Verifying Tasks

If a task is passed back to you marked as ‘complete (not verified)’ then it is typically a request for you to confirm that the issue has been satisfactorily resolved. There are a few ways in which an issue may be completed, which will generally be reflected in the “comment” field:

• The project personnel believe that they have fixed the underlying issue and you should test to ensure that the issue no longer occurs. Please be sure to test in the branch(es) which are marked complete, and not in any branches which may still be open. If you concur that the problem is fixed, mark the tested branches as “verified”. Please do not change the status of any branches which you have not tested personally. If you still experience the problem in the supposedly-fixed branches, mark the tested branches as “incomplete”. Feel free to make subtle clarifications to the “details” field while testing, but do not substantially rewrite the task- if a new bug is apparent, enter it as a new task.
• The project personnel were unable to reproduce the issue that you reported. If you are able to reproduce the issue, improve your “details” to assist the project personnel in reproducing the issue and mark the tested branches as “incomplete”. Hold on to the task for as long as you need to track down the specific reproduction steps.
• The project personnel disagree with your task, and are informing you that the task will not be carried out. If you understand what’s being said and don’t have anything additional to add, mark your task as “verified”. If you believe that you have additional information which may change the decision, then please clarify your “details” and mark the task as “re-opened”. Don’t simply bounce a task back because you don’t like the response- this achieves nothing and generates work for the project personnel, and may lead to your account being removed from the testing program.

As always, once you’re finished with the task, assign the task to <nobody>.