How to write a good and to the point test plan?

A very simple one that I follow is to create a list with following columns

• Behavior: what code/product functionality does this row test. Focus on testing behaviors, rather than underlying implementation details.
• Setup: what are the preconditions before we can execute the behavior. Create a new account, join a certain experiment, etc.
• Steps: These are the core steps to execute the behavior. Click button X, type in Z, etc.
• Expectations: At the end of the steps, what do we expect to happen. User visible behaviors, such as screens do something, receiving an email etc. As well as system behaviors (if relevant): database gets updated, certain data guarantees etc.
• Type of test: You might be executing these manually or in an automated manner.
• Result: Pass/Fail
• Artifacts: Screenshots, evidence, etc.

Typically QA team executes these, but sometimes developers do too. It serves as a great mechanism of ensuring your code changes are working well.

Lalit's answer is great, but I feel like explicitly documenting all of those in a test plan is overkill, at least for relatively small and simple pull requests.

The main thing (at least for me and engineers at Meta/Robinhood) is artifacts. In particular, try attaching a video if you can.

Here's my overall process for making a killer test plan:

1. Figure out all the cases your code should account for
2. Go through all those cases in your test plan artifacts

If the artifacts are good (again, video is amazing for test plans), it will be clear what the steps are and you don't need to write it all out.

If you find the video to be too long (>1 minute), you can split it up into separate videos with a small description on each one. A classic example for front-end engineers is going through the flow once in dark mode and once in light mode as separate videos.

Here's another great discussion to check out: "What can I do to quickly build my reputation as a junior engineer?"