How many times have you heard the phrase "works as designed" used to describe software that is flawed and in some cases not fit for use? While "works as designed" has become an acceptable response for some, for real professionals, it's not.
Exploratory testing projects can have documentation requirements, just like any other project. Jonathan describes various ways we can create documentation on our exploratory testing projects, including guidance documents, test-coverage reports, and video software to help create lightweight, powerful documentation.
Vague or ambiguous requirements can cause loops in development processes. Creating requirements that include acceptance tests cuts down on the looping and increases the flow of working software to the customer.
For many organizations, automation is a burden--even with good tools. Keywords are popular but don't suffice on their own. Action based testing places a high emphasis on modularized test design, not only making tests lean and mean but also allowing for very stable and maintainable automation.
Observing customers in a usability lab can be invaluable for improving product design. But, once your software leaves the lab, do you know what your customers are actually doing and whether or not your software meets their expectations? Learn how engineers on the Microsoft Office team apply a variety of software telemetry techniques to understand real-world usage, how the results drive product improvements, and how you can apply similar techniques.
Testing regulated software is often seen as a tedious job that generates stacks of documentation and is subject to crippling rules. See five of these assumptions exposed as mere myths, and learn how regulated testers can use the same approaches, techniques, and tools at any other tester's disposal while still passing a process audit.