Throughout my career as a QA engineer, I’ve used the following informal question as a basic sanity check: Does my gut tell me that everyone involved is on the same page? Do the developers, the QA engineers, the technical writers all have a common understanding of what they’re developing? Most of my jobs had no particular defined process, so this sanity check was particularly important.
I’ve found this question also to be useful in an agile team, but the dynamics are a little different.
Going into the sprint, I–as the team’s functional tester–have a good idea what business goal the story is supposed to achieve, in the form of acceptance criteria. That’s good enough to start writing basic acceptance tests. But I don’t necessarily understand the design and implementation details that enable me to test on a much deeper level than simply to determine whether the story meets the basic acceptance criteria.
In my experience, that common understanding is spread in stages in an agile team. First, the lead developer on a story (along with the product owner and, in our case, a UI designer) works out the basic design and functional details. At that point, those people share a common understanding of the design and implementation.
In our teams, we have the lead developer document this information on a wiki page in what we call a ‘mini-spec.’ At that point, the other participants in that story read the mini-spec and start asking questions (reviewing the mini-spec, essentially). As more details are ironed out, those details are added to the mini-spec, and the common understanding is spread to a wider group.
Finally, towards the end of the sprint, the other members of the team who may not be involved in a particular story begin to gain the common understanding.
There’s a great temptation to have all interested team members involved in the initial design and implementation discussions, but we’ve found that doing so is not very efficient: the team just gets bogged down in details, and the design and implementation meetings get out of hand.
I’ve found that it takes discipline to withdraw from those discussions and to trust my team members to do that initial work and to trust them to help me gain the common understanding a couple of days later.
The one frustrating aspect of this process comes out with more complex features. As each team member starts to come up to speed on the common understanding, the same questions get asked repeatedly–even if the answers were already documented–and, in many cases, even if the person asking them has read the documentation. It’s one thing to read the documentation; it’s another to really wrap your mind around it and gain the common understanding. That sometimes entails those who already ‘get it’ repeating the same conversation with different individuals who are ‘getting it’ at different times or at different speeds.
But I try to watch for those repeated conversations. The ‘ah-ha’ moments that occur are a good gauge that the common understanding is spreading as it should.