Table of Contents

Part III — Infrastructure Alignment

Chapter 36

Quality Assurance (QA)

"I couldn't repair your brakes, so I made your horn louder." — Tater, Disney's Cars

Microsoft taught me an important lesson in the 1990s. They would release development tools and server operating systems for free. New versions shipped roughly quarterly, mostly containing bug fixes rather than new features. What Microsoft demonstrated was that software doesn't need to be perfect to win. It needs to iterate faster than the competition and patch problems before users lose patience.

In early 2000, we launched a feature to our legislative tracking service that sent text-message updates to mobile phones — flip phones and BlackBerries with severe character limits. We invented a vocabulary of abbreviations for legislative actions. Users provided feedback within the first few weeks, and many of our initial abbreviations were changed based on their suggestions. The users were the quality assurance team, and they were remarkably good at it.

The best QA is your user base. Failing to put something in front of them early — out of fear it isn't ready — will cost you more time in the long run than the feedback would have.

Roadmap Considerations

◆ Is your service in a regulated industry? If so, your QA process may need to be more formal and less agile than you'd prefer. ◆ Have you determined whether load, stress, and penetration testing are appropriate for your platform and your risk profile? ◆ Do you have meaningful incentives — for users and internal staff — to actively test and report bugs?