Users are the ultimate judge of the software we deliver because it is critical to their success and the success of their business. However, as a tester, do you really understand their tasks, skills, motivation, and work style? Are you delivering software that matches their needs and capabilities-or yours? Personas are a way to define user roles-imaginary characters-that represent common sets of characteristics of different users. David shares how his team at Microsoft defined and used one persona named “Ellen” to help them design, develop, and test the first version of a new product. David shares before Ellen and after Ellen examples of the product, showing how the product changed when Ellen joined the team. See examples of the robust test cases and acceptance scenarios they defined from unique insights that Ellen provided.

What features of your software do customers use the most? What parts of the software do they find frustrating or completely useless? Wouldn't you like to target these critical areas in your testing? Most organizations get feedback-much later than anyone would like-from customer complaints, product reviews, and online discussion forums. Microsoft employs proactive approaches to gather detailed customer usage data from both beta tests and released products, achieving greater understanding of the experience of its millions of users. Product teams analyze this data to guide improvement efforts, including test planning, throughout the product cycle. Alan Page shares the inner workings of Microsoft's methods for gathering customer data, including how to know what features are used, when they are used, where crashes are occurring, and when customers are feeling pain.

Quality assurance is more than just testing software through processing a series of controlled inputs and outputs. It must also include an assessment of all the deliverables associated with the project. Developers and testers often view software documentation as merely a source of information, not as artifacts that require evaluation. All software documentation should undergo a rigorous quality assessment just as the actual software is subject to comprehensive testing. Mark Haynes describes quality models and attributes that can be used to evaluate requirements documents. He shows how imprecision (that will haunt you later) can be detected and removed through a set of formal criteria and informal heuristics. To experience using these techniques, Mark shares examples of poorly written requirements for you to evaluate and improve. Additional quality attributes, even subjective ones, can be used to conduct a quality dialogue.

Some agile teams rely on user stories alone to articulate requirements, struggle with requirements rework on large agile projects, and spend too much time thrashing on requirements during iterations. Requirements expert and agile coach, Ellen Gottesdiener shares a wide spectrum of requirements practices ranging from traditional to agile to help you break out of the cookie-cutter mentality that some take toward requirements elicitation. Practitioners from a traditional environment learn how classic requirements practices are adapted on agile projects. Agile practitioners learn how they may lighten, tighten, or incorporate a subset of traditional requirements practices to mitigate risks associated with missing, erroneous, or conflicting requirements. Gain an appreciation of ways to adapt requirements practices to fit various project situations so you can do the right things for your project.