How to write Task in Issue Tracker

At our team we try to follow these practices while writing a new task. A separate post will detail how to comment on them and provide status updates when programming.

Bad example :
Issue1
Summary : ATM Withdrawing

Description:
1. User will see card slot blinking
2. User will feed his card into ATM slot
3. Machine will suck in the card
4. Machine will check whether card is a valid bank card or just something else (like a cardboard, or a tempered card)
5. blah blah blah blah blah…
6. blah blah..

Good example :
Issue1
Summary: Blink the card slot when ATM is ready for a new customer

Issue2
Summary: Suck the card into machine when card is fed into card slot

Issue3, Issue4, Issue5…IssueN
Summary: Likewise we write separate issue for each function that ATM machine is to perform, than tying everything into single issue

It must be readable by a tester — especially someone who is supposedly not a programmer on the project, but a user of the project. Hence it CANNOT contain buzzwords of programming (like Multi threading, race condition, etc).

How section must describe technical steps of accomplishing the task. HOW may mention :

It is not necessary to write a HOW, unless you ‘arrived’ upon how by ‘thinking’ about it. If it was a simple piece of code (like reading XML, and writing it back in some JSON) — no need to write a HOW. But if before writing the code you had to think (like reading XML which is 1TB large, and saving it in millions of JSON files rather)

WHEN in a task must mention the event when the task must be done by machine. A user (other developer user, or end user) might perform a trigger. This trigger will provoke the system to exhibit the task. This trigger or event must be described in WHEN. For example :

If user of task is a developer, consider highlighting the portion of flowchart/diagram when the task must be performed.

Remember ‘Task’ is something which programmers can work upon. Epics or higher level tasks cannot be worked upon. They can be vague and have sometimes open ended scope. But especially inside HOW section of a ‘Task’ or in Title of a task, avoid using ‘vague’ words. Some examples of vague sentences are :

The words in bold above are ‘vague’. They do not mention any test criteria. Likewise avoid using words like ‘old, new, latest’ anywhere when writing issues or even when programming. Nothing is more confusing than having 4 files namely :

Reporting progress while programming..

Related posts:

China presents a huge opportunity for international alcohol businesses, but selling to China is a long, rigorous process, from following import regulations and submitting the required documentation…

Tally has options to scan barcodes and fetch information. Barcodes help keep data accurate while making its entry faster. Barcodes, therefore, avoid manual errors that help in faster billing, stock…

The last thing we want is reminders of gloom and doom on every damn news channel, feeding our fright. Let’s release our inhibitions. Prance round your home in the manner of a whirling dervish, warble…