In this case, the programmer can only guess and seek out this quote. Well, if itssource and receiver in the project are only one, but there can be much more of them. Solving the problem by "selection" is a waste of time. It's good if the programmer guesses by some miracle and still finds it, but he can spend a lot of time pulling the door handles lock.
It happens that the bundle creates tickets after the planning session and they have only one name - this is not a problem, you can fill in the ticket with content later, but you must do this before the ticket is in operation.
It is much worse when the ticket closes, and the content has not been described. Before closing the ticket, you need to check whether its description matches the current state of things. If the ticket was closed and not described - no problem, the closed ticket can also be edited and filled with content.
In the description of any ticket, it is essential to indicate the source of the requirements. It may be:
- the requirement of the original contract (estimate, statement of work) - then you need to specify the item of requirements (and the document, and where to get it, if it is not clear where it is)
- the client's request expressed during a call or in correspondence - in this case, the client's words must be copied to the ticket
- the requirement of the project manager or team leader - you must explicitly write about it "* First name Last name * said that the version number should be only one number."
- by the recommendation of a third-party expert or colleague - you need to write about it explicitly, for example: "First name Last name <email address or nickname> says that Docker containers should contain no more than one service, so Dockers have it .."
- recommending an article on the Internet - be sure to provide a link (URL) to the item (for example: Make the version number according to * link *).
It is convenient to quote the words of the client (or a third-party expert) in the form of comments on the ticket, to which you can link from the ticket body. If all the requirements of the ticket can be understood from the text, then it makes sense to insert the entire section of the chat or letter into the body of the ticket. It must be clear from which chat or letter the requirement was taken when it was written.
The requirement for making links to the client becomes especially essential when the client asks for changes to an already agreed upon or developed software function.
Now, using an example of a ticket of the "Defect" type, let's look at the basic rules in compiling and describing a ticket.
The description of the defect is most often called a bug report. This is a specific but ordinary type of ticket. It must be indicated in it:
- play steps
- observed behavior
- expected behavior
- instance (software version, environment) in which the defect was detected
- test script
To write a good bug report, you need to prepare. If you find any mistake, don't run headlong into the bug tracker to start a ticket with the cries "nothing works!". To start, reproduce the error again. Reproduced - well, if not - it means that you did not take into account something and you need to try to reproduce it again.