3. Reporting Feedback

Reporting your feedback is a 2 step process:

3.1 Step 1) Recording your testing notes in a Google Doc

Testers should record their detailed "Testing notes" in a Google doc in the global OFN drive (it's in edit mode so you should have access) so that we have all testing notes in the same place. Please duplicate the Testing Notes template and rename your new version with the PR number and description.

The testing template is designed to be broken down into all the user cases which were tested, and the tester should describe what they tested and what the result was. The more detail the better.

If the test passed colour the box green. Describe what worked, and perhaps put a screenshot if you think it's a good record.

If it failed colour the box red. Give a description of what didn't work. Include as much detail as you can such as what kind of user was involved and what actions led up to the error occurring. This helps the developer when they try to replicate the problem. Are there some situations where the error occurs, and others where it doesn't? If the errors is hard to replicate include this in the notes.

If you’re unsure, colour the box orange. Describe your uncertainty, and flag this uncertainty in your comment on the github issue (see 3.2 below). An example of an uncertainty is 'I don't know what the desired functionality is', 'did the developer intend for this?'.

Screenshots. A picture says 1000 words, so use screenshots to show features that are working, and more importantly not working. You can capture what's on your screen with the Prt Scr button on your keyboard, or an app like ksnip. If it's possible to show a bug in action, get a screenshot and illustrate it. Even better if you can capture a GIF or moving image showing the bug – Loom is a good plugin for this.

3.2 Step 2) Comment on the PR

Once you have tested all the cases you could think of related to the PR and you've created a testing notes doc, report your conclusions by commenting on the PR in Github.

(a) If it's all good, just say something like 'no issue found' and give a high five to the awesome developer who did a good work. You can also list the things that were working in quick dot points.

(b) If you spot anything that's not working as you would expect, or is broken, tell the developers by listing the major outstanding issues that should be addressed in shortform. If the developer needs more detail they will go to the google doc, but they may not need to.

Lastly, include the link to your google doc in the comment, so the developer can see the record of your detailed test notes.