Process
Most testers start by clicking. I start by asking questions.
You always know what I am doing and what you get
A change in the middle of a sprint gets an honest answer, not a silent yes
When it is not ready, I say “not ready”
1
Understand
I read your requirements and designs, and ask what nobody has asked yet.
You get
A short test plan and a list of open questions
2
Design
I write a test for every requirement, including what users are not supposed to try.
You get
Test cases that stay with you
3
Test
Smoke test first, then functional and exploratory testing on real devices, on staging and live.
You get
Bug reports with steps, video and the expected result
4
Report
I write down what is safe, what is risky and what is still untested.
You get
A clear go or no-go for the release
5
Retest
Each fix gets a sanity check, then a regression run over the areas around it.
You get
A written sign-off
When plans change
A change lands mid-sprint. I don't just say yes.
After the mid-sprint demo, new ideas arrive. That is normal. What matters is what happens to them next.
What I will not do
Say yes without checking what it breaks
Test only the basics and call it done
Stay silent and let the sprint slip
A change request arrives
First, I check three things
What else it touchesIts edge casesThe time left in the sprint
If it is small
It is tested this sprint.
I write its test cases and run them alongside the planned work.
If it is big or risky
I tell you the same day.
It needs its own time, so it moves to the next sprint with a proper plan.
You hear about a risk the day it appears, not on release day.
What my report tells you
Four answers, not a list of clicks.
Safe to releaseTested and working
RiskyWorks, but something worries me
BlockedBroken. Do not release this
Not tested yetSo you know what I did not cover
