I really like testing plans and generally follow a simple framework based on principles I’ve learned from others and insights I’ve heard from folks here at Taro.

I find that a testing plan should enable other engineers, even those with less context about your PR, to validate that it works as expected. This doesn’t necessarily mean you’re okay with an approval from someone without context. Regardless this is the principle:

**If you can create a testing plan that lets a new team member with a fresh codebase validate your changes, it builds huge confidence for folks who are knowledgeable about the problem / feature.**\
\
So with that in mind, there’s no one-size-fits-all solution. However, following the principle mentioned above will guide you toward something like this:\
\
\-----\
**Testing Plan**

**Automated**

1. Ensure docker is running
2. Run `bash e2e.sh ...` whatever your e2e, integration, or high value unit tests are
3. Make reference to the tests in the diff

*Insert screen shots of passing -&gt; also point to passing in the CICD pipeline*

**Manual**

1. Ensure docker is running
2. `$ bash startup.sh test`
3. Navigate to `localhost:3000/xxxx`
4. Do X Y Z
5. "Expect this thing to look like this"
6. Attempt edge case: Insert "some edge case" and expect "plan product requirement outcome"

*Include screen recording of manual steps or screenshots*\
*\-----*

Hopefully this helps!

Senior Software Engineer @FocusConsulting

Iverson Diles

**"I have seen jobs like QA engineer, Dev ops disappear which was prevalent at least five years ago. End to End shipment is done to production is done by the Individual. Even the performance testing and scaling of service is done in push of the button."**\
\
What stack are we talking about? A default Next.js app on Vercel? What about applications that interface with on-premises government services? There’s plenty that still needs to be done (and the deployment process isn’t AI – it’s solutions built for specific use cases, wrapped around a core cloud provider).\
\
E2E testing can be done by recording actions from the browser (no code writing needed except for config, setup, teardown). That isn't AI, that's another solution.\
\
The issue is that everyone is classifying everything as AI when it’s really just good old innovation and problem-solving.