3 ms·
I agree with everything you're saying here. The only thing I would add is Before I hand a ticket off to QA, I write up 1. What I understood the requirements t
by RHSeeger 9mo ago
I agree with everything you're saying here. The only thing I would add is
Before I hand a ticket off to QA, I write up
1. What I understood the requirements to be,
2. What I implemented,
3. How to interact with it (where it is in the tool, etc), and
4. What _other_ areas of the code, besides the obvious, are touched; so they can regression test any areas that they feel are important
Doing that writeup makes sure I understand everything about my implementation and that I didn't miss anything. I find it extremely valuable both for QA and myself.
- mixmastamyk 9mo agoRubber-ducky in human form.
- weinzierl 9mo ago"What I understood the requirements to be" That is a way to get your changed approved quickly, so it is good for you. It is terrible for a project that values quality. A tremendous value of a QA team is that they interpret the requirements independently and if in the end they approve you can be pretty confident you implemented something that conforms to the commonly understood meaning of requirements and not your developer biased view.
- RHSeeger 9mo agoChallenge. I use it as a way to double check, "Did the way I understood the ticket/requirement match the way that QA did?". They're testing what the ticket says is required. But part of that is testing that I understood the ticket correctly.