Who Assures Quality?

Who “assures quality” on your projects?

Who assures quality? Is it the team of testers are left out of conversations when features are first being discussed, instead of providing their valuable input on overall complexity, risk, and their impact on business value? That same team of testers who aren’t co-located with developers and do work in parallel, instead of pairing up with devs as the work is being done? Those testers who work on testing as an event after development is complete instead of working on testing as a constant activity starting long before developers write code?

Who assures quality? Is it the team of developers who get technical solutions handed to them instead of being involved in determining how to deliver business value? That same team who spend time fighting organizational-mandated friction-inducing processes instead of focusing on writing code? Those same developers who are pressured in to shipping code faster versus supported in learning how to build well-crafted code that’s maintainable and lends itself to fast delivery of value?

Who assures quality? Is it your business analysts and program/project managers who are told to act as customer proxies without having true, constant interaction with those humans who have real needs? Those same BAs/PMs who are constantly re-directed by management who thinks that “Agile” is an excuse for poor planning?

Who assures quality? None of these folks I just spent half a page talking about.

The only person/role/group that assures quality is the people who write the checks for the work being done. The stakeholder is the sole person/role/group that can assure quality.

Stakeholders assure quality in many ways, including:

• Providing enough funding to ensure each role (PM/BA, dev, tester) is adequately staffed
• Giving enough time on the schedule to allow systems to be built in a solid, maintainable fashion
• Ensuring project teams have the resources (resources, damnit, NOT people) to do their jobs
• Working out a reasonable priority for value, and not reprioritizing at a whim

Delivery teams help the stakeholder assure quality by:

• Providing useful information to the stakeholder about the project’s state
  
  • Useful information, NOT counts of bugs, number of test cases, lines of code, etc., etc.
• Ensuring the stakeholder knows the impacts of reprioritizations and scope changes
  
  • Also, understanding that those changes are often actually important
• Holding each other accountable to creating high-value, well-built systems

Who assures quality? THE WHOLE DANG DELIVERY TEAM INCLUDING STAKEHOLDERS.

I’m far from the first person to write about this. I’m just the guy who woke up today with several mails in my Inbox that touched on this subject.

Go back to work now. Have a conversation about value in production, and what that really means. Then go ship value. It feels good. Honest.

Don't Empower. Expect.

We’ve heard plenty about empowering teams:

“You’re empowered to make decisions.”
“You’re empowered to do TDD.”
“You’re empowered to raise concerns.”

Empowering your teams lets them know you’ll support them in doing things the right way. Leaders need to give their people top cover, so this is really a great step.

Unfortunately, just empowering teams leaves them the room to rationalize why they shouldn’t do things we expect of professional craftsmen.

“We were running behind so we stopped pairing.”
“Bob wasn’t here this week, so we skipped all our Three Amigos conversations.”
“Someone reset the QA environment and all our data got wiped out. We had too much work in progress, so we didn’t stop to refactor our tests to handle their own data setup.”

These sorts of things aren’t what you want with your teams. You’ve given them the room to do things right by empowering them. Take the next step and make it clear you’re expecting them to get these things done. Moving to a culture of expectations helps your team members hold each other to a higher standard. “Hey, we skipped tests on this story. Let’s pair up and go fix it right now.”

Do what it takes to make expected behaviors clear. Speak up, send unequivocable communications, ensure your “done” barometers clearly state these activities must be accomplished.

Change the culture. Now. Stop talking about empowering. Talk about expecting.

Estimating Your Testing Effort

“How long is it going to take you to test the release?”

Heard that question before? What team hasn’t? It’s a fair question from the business, even if they don’t understand the complexities involved.

Often I’ll turn the question around, not to push back on the stakeholder, but instead to try and level-set on what the stakeholder’s goal is. Testing is emphatically not about “assuring quality.” Testers can’t do that, only the whole team can. Instead, testing is about providing information about the system/product/application’s value, risk, and suitability.

I’ll work with the stakeholder to understand their most important goals for the release, then focus my testing efforts around those goals. Those goals should include the stakeholders high-value areas and also high-risk concerns.

High-value areas might be things like

• Checking out properly handles credit transactions, including errors like invalid card numbers
• Users can save their profile information so it’s automatically retrieved next time they browse
• Players can no longer hack their mech to run 100 MPH and instead are limited to the 10MPH as specified in the rules

High-risk concerns might include

• No privacy information is surfaced outside the account holder’s profile
• No SQL injection is possible on public-facing pages. (A lesser risk is the same concern on internal pages)
• Performance for the five most-valuable workflows are within the agreed upon metrics

I’ll use that conversation to drive out what I feel is the needed level of effort given the stakeholder’s desire for clarity around their highest priority items.

Want to learn some approaches to estimating your testing effort? Join my pal Matt Heusser on 21 April for a webinar discussing different ways to get reasonable, realistic estimates fleshed out.

More information and registration at the QASymphony site for the webinar. Go sign up!