You can validate the accuracy of your release note by creating a checklist and reviewing each item on the list until you know these by heart:
Files affected
Have you entered the files for its related product? For example, some DLLs may affect one version but not another. Make sure these are not entered by accident.
Next, have you used the correct case, for example, mixed case or lower case? This is important both for the reader and technical validation. Remember to also include Exe, XSD, and SQL files if these have been affected.
Multiple Issues
If there were several inter-linked issues in the same bug, identify each one separately and highlight to the reader the root cause of each issue, as well as any new enhancements.
Bullet v Number lists.
Use bullet lists to itemize parts of a list, for example, the following fruit were in the kitchen:
- Apples
- Oranges
- Pears
Use numbered lists to state the sequence in which a procedure must be performed, for example, to start the car:
- Enter the key.
- Turn on the ignition.
- Put in in first.
Technical review
Has the release note been reviewed by a member of QA, Dev or a business analyst?
You don’t need to do this if you are 100% sure you understand the area, but if in doubt, ask for clarification.
Style and Format review
Does the release note adhere our writing guidelines? You can check this by comparing your text with previous release notes. In particular, look for phrasing, formatting, and structure.
Section heading
Enter the bugs under their respective heading in the release notes.
One way to determine this is to identify WHERE the issue occurred.
Of course, sometimes you will need to configure something in one window and then use this setting in another.
From the user’s point of view, the issue occurred in the second window, even if the root cause was elsewhere.
Summary
Allow time to test your release notes before they are published. Configuration managers, testers, and client are relying on this information, especially if parameter settings have been changed.