All too often, programmers are distracted right in the middle of focused activity by questions via Skype. Sometimes a simple reply is enough, but on other occasions the issue is a bug that has appeared in a project and needs correcting. We start clarifying details, create a task in the bug tracker, and agree on a deadline for a solution. Then, on returning to the interrupted activity, we realise that forty minutes has passed. The manager will then ask: “Jake, didn't you estimate this task at seven hours? Why have you been working on it for two days?”
Dear client! If a fault with the project arises and you want to report on it quickly in the chat, remember the following.
 |
If you fail to state the essence of the problem clearly and succinctly, it will take additional time to clarify the details – this is time that you will have to pay for. Besides, you might be distracting not just one but several workers from their current tasks. | ||
 |
There may be a false sense of urgency. For instance, the developer may try to reproduce the stated defect without waiting for answers to requests for clarification, attempting to fix it straight away; this is good if the problem is critical, and bad if the problem is a minor one (when there are other more important tasks to deal with); it's even worse if the client didn't intend for it to be fixed in the first place. | ||
 |
The reverse situation is possible: a problem discussed via Skype may never go any further. Many employees quite reasonably consider that a solution to an issue starts with creating a task in the bug tracker. Skype is only a communication tool where a current project can be discussed quickly. A bug tracker logs tasks, comments and decisions taken. An analysis of conflicts is also conducted via the bug tracker. In other words, if you are going to write something like “it wouldn't hurt to do this or that…” via Skype, then please don't complain when “this” or “that” hasn't been implemented a week later. | ||
|
If you don't create a task in bug tracker, we can do it ourselves, but you should then make sure that everything you have specified was written down correctly. |
What should you do?
Time passes, the project isn't ready and your budget isn't elastic. There are two options.
The first – our employee (a tester, a support team specialist or a project manager) will reproduce the defect, evaluate its severity, enter the information about it into the bug tracker, summon the programmers and set an approximate deadline. Such schemes can be successfully implemented if the project budget allows for the participation of an additional specialist.
The second – you can enter the task yourself. If you want the problem to be solved quickly it should be clearly understandable. Here we need to elaborate.
The title
So, you have encountered a defect that you need to report. The first thing you should do when creating a task is writing such a title that immediately explains what has happened. The title should answer three questions.
“What?” – What has actually happened?
“Where?” – In what part of the interface has the problem been observed?
“When?” – What circumstances have caused the problem to appear?
Here are examples of titles which do not answer any of the abovementioned questions.
- “Again, nothing is working” – it is unclear what exactly isn't working.
- “Strange button” – no comment necessary.
- “Username and password” – please avoid these kinds of titles.
Examples of titles which answer only part of the question.
- “Page layout falls off” – it is clear that the site has layout problems, but not what the exact problem is
- “Different text formatting” – this demands additional questions as it's unclear what is meant.
- “Dashboard graphics failure” – there's something wrong with the Dashboard screen, but it's unclear what the failure refers to. There will be additional questions.
- “Some messages in the user account are not displayed” – this title isn't bad, but it lacks information on what kind of messages are not displayed and under what circumstances. Clarification requires time and the problem needs to be reported as quickly as possible.
- “I can't switch instantly from the ‘My cameras’ tab to the ‘Guest access’ tab” – here we could do with some details: under what circumstance does it happen? The developer might not be able to reproduce the problem.
- “Error on sending Issue” – not bad.
- “The cinema settings option disappeared from the client side” – this is a situation where answering the question of “When?” is unnecessary.
Examples of good titles which answer the questions “What?”, “Where?”, and “When?”.
- “Not all PUSH messages are displayed in the user account” – it is immediately clear where to begin the fix.
- “IE8 constantly complains on ad submission form, beginning with the first step” – the only thing that is unclear here is what is meant by “complains”, but having opened the ad submission form in IE8, we will see everything ourselves.
- “In the filter panel the price doesn't ‘initialise’ when filtering by price” – in this case you can open the section of the code dealing with the price filter and check what's wrong with it
- “While viewing a recording the turning unit buttons are still available” – there is no need to turn your camera while watching a video recording. This means we forgot to delete the turning buttons – we'll correct it shortly.
- “A limit on the number of ads from an individual can be exceeded by editing the direct link in the address bar” – quite clear; we will add a redirect.
Description
In most cases, if the title is written correctly a description might not be needed at all. On the other hand, a properly filled in “Description” field can compensate for the title's drawbacks and even point at a solution. There have been cases when a problem with a detailed description was corrected within ten minutes, and cases where it took several hours without one. In situations of the first type, the developer understood immediately which line of the code needed to be corrected. In the second, he had to debug the code for half a day before understanding the cause of the problem
What needs to be mentioned in the task description.
 |
Details | Details that help recreate the problem and lead the developer to the possible cause of the error. For example, it will help if you provide a step-by-step description of what you do and how it leads to the problem. By following your steps, a developer will reproduce this error in debugging mode and thus will be able to start correcting it. | ||
 |
Actual outcome | Write what exactly is happening. | ||
 |
Expected outcome | Write what should happen. By skipping this point you force the programmer to look for answers in the requirements, which will take time. If specific requirements aren't documented, state your own view – the developer will have to ask you in any case and will be waiting for a response which will again postpone the solution of the problem. He might also correct it as he sees best fit, but his view may be different from yours. | ||
 |
A screenshot | In some cases this is worth a thousand words, especially if the problem is connected to the interface or design. |
Priority
When creating a task you can define the severity level, acting as the head of the project (which, in fact, you are). The severity levels are as follows.
- Blocker – has to be fixed immediately – nothing else will work until the defect is eliminated.
- Critical – the problem will be corrected promptly by top specialists.
- Major – the default severity level setting. Most project tasks have this priority level.
- Minor – the question doesn't require immediate attention; it will be dealt with after most other tasks are resolved.
- Trivial – tasks of this kind will be dealt with last of all.
These are the main things one should know about creating defect reports in bug trackers, and most often it is enough for efficient cooperation with developers. If something really important comes up, a message can always be sent via Skype: “Guys, I've created an urgent bug task. Here's the link – when can you fix it?”.
2002–2024