Start with risk and behavior
I approach testing by asking what could harm customers, the business, or the team's ability to learn. I turn important behaviors into examples that product, design, engineering, and quality can understand together. This is more useful than treating a test count as proof of quality.
I would prioritize by impact, likelihood, change risk, and the cost of discovering a problem late.
Use several kinds of feedback
I would automate stable, repeatable checks where the speed and consistency are valuable. I would use exploratory testing for surprising interactions, edge cases, accessibility concerns, and questions the script did not anticipate. I would also test operational readiness, observability, permissions, and rollback when those risks matter.
Testing should begin before code is complete. Clarifying examples during discovery can prevent ambiguity from becoming rework.
Learn after release
I would define what we will monitor, who responds to a problem, and how we will capture learning. A release that passed its checks can still fail to create value or can behave differently in real conditions.
Make the operating agreement visible
I would turn the practice into a lightweight agreement: who owns the next decision, what evidence is needed, which risk is being watched, and when the team will review what it learned. That makes the work easier to coordinate without pretending the process is the outcome.
I would invite the people doing the work to challenge the setup. Their experience can expose a hidden dependency or a safer way to improve the system before a small issue becomes a delivery surprise.
My bottom line
I treat testing as a shared product-quality practice, not a final gate owned by one group. The Product HQ technical product manager certification can strengthen this delivery foundation. I also share practical lessons in the Product HQ newsletter.