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.

▲

weinzierl 8 hours ago | parent | next [-]

"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 8 hours ago \| parent [-]
		Challenge. 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.

▲

mixmastamyk 9 hours ago | parent | prev [-]

Rubber-ducky in human form.