New Proposal for Reproduction and Patch Testing Reports

[SirLouen]

It's time to get hands on the review of the new Reports

Here I'm going to propose two alternatives, for Reproduction and Patch Testing.

== Reproduction Report

=== Environment
- WordPress: 
- PHP: 
- Server: 
- Database: 
- Browser: 
- OS: 
- Theme: 
- MU Plugins: 
- Plugins:

=== Steps taken
1.
2.
x. 🐞 Bug occurs / ❌ Bug is not occurring

=== Expected behavior
- Explain what behaviour you were expecting from the ticket information

=== Additional Notes
- Any additional details worth mentioning.

=== Screenshots/Screencast with results
- Screenshot showcasing the problem or the bug not ocurring.

=== Support Content
- Here you can add any support content useful for testing
For example:
1. Blueprint JSON
2. Website Playground URL with parameters
3. Snippets of code
4. Additional Screenshots
5. etc...

== Patch Testing Report

Patch Tested: Link to the diff patch or GitHub Pull Request

=== Environment
- WordPress: 
- PHP: 
- Server: 
- Database: 
- Browser: 
- OS: 
- Theme: 
- MU Plugins: 
- Plugins:

=== Steps taken
1.
2.
x. ✅ Patch is solving the problem / ❌ Patch is failing

=== Expected result
- Explain what results you were expecting from this patch.

=== Additional Notes
- Any additional details worth mentioning.

=== Screenshots/Screencast with results
- Screenshot/Screencast before
- Screenshot/Screencast after

=== Support Content
- Here you can add any support content useful for testing
For example:
1. Blueprint JSON
2. Website Playground URL with parameters
3. Snippets of code
4. Additional Screenshots
5. etc...

Related tickets:

• In Key Test Report Features, define "expected" and "actual" test results #2: Changes in the Test Reports handbook page

[huzaifaalmesbah]

I like the current structure, but I’d suggest a small wording tweak for clarity and consistency.

Instead of listing the result as a numbered step:

x. ✅ Patch is solving the problem / ❌ Patch is failing
x. 🐞 Bug occurs / ❌ Bug is not occurring

Would it make sense to present it more explicitly as a result, for example:

**Result:** ✅ Patch is solving the problem / ❌ Patch is failing
**Result:** 🐞 Bug occurs / ❌ Bug is not occurring

Using Result: makes it immediately clear that this is the final outcome of the test, not another action step, which could improve readability and reduce ambiguity for testers and reviewers.

[SirLouen]

Using Result: makes it immediately clear that this is the final outcome of the test, not another action step, which could improve readability and reduce ambiguity for testers and reviewers.

This version feels more like a variant to the "Actual result" version, which could lead of bringing the "Actual section" back.

For me its more natural to see the result as the last step, especially when there is a bug present. It's like when you get to that final step, you happen to see the final result either for good or for bad.

In fact judging your instructions I dont think that is the right way to add them so we need to polish this a bit.

You don't need to specify the "with the patch and without the patch" thing. You just add the instructions to get there for each of the different reports.

For example

Reproduction Test Report Example

Step Taken

1. Go to Appearance > Widgets
2. Add Text, Custom HTML and RSS widgets to the sidebar
3. Resize the browser to a small width (for example 400px)
4. 🐞 Bug ocurrs: Widgets overflow outside the viewport

---

Patch Testing Report Example

Step Taken

1. Go to Appearance > Widgets
2. Add Text, Custom HTML and RSS widgets to the sidebar
3. Resize the browser to a small width (for example 400px)
4. ✅ Patch is solving the problem: Widgets stay inside the viewport without overflowing

I've been trying both for a while, and after a big number of tests I settled with the "final step" option, as it felt more natural, at least for me.

I would like to hear others opinions.

[Successfulsebunya]

Adding it as a step is more reasonable to me because it actually is a pat of the process.

[ozgursar]

I also agree that adding it as the last step feels natural and easy to write for me.

Apart from that, I must admit that I usually struggle writing the Expected result section when writing the Patch Testing Report. It feels like I need to summarize what the ticket / bug is about and how the patch solves it, which in my opinion, should actually posted by the person who submits the patch.

Similarly, writing the Expected behavior for the Bug Reproduction Report feels tedious. In my opinion, this should be a part of the Testing Info provided by the Reporter.