Although testers know the ins and outs of functional testing, many of us don't have a smart process for doing software performance testing. To improve her personal performance testing skills, Mieke Gevers looked at processes from other disciplines-automobile manufacturing, medical rehabilitation, and project management. It was here she found SMART, which stands for Specific, Measurable, Attainable, Realistic, and Timely. Learn how Mieke’s organization used SMART to deal with chaotic performance testing situations-lack of clear requirements, discrepancies between business objectives and reality, running out of time, and changes in technology. In Mieke's organization, SMART has helped them save time, react quickly to production requests for developing and running tests, develop reproducible performance tests, and create better test results documentation.

The switch from traditional, top-down management to agile project practices poses a dilemma for managers and the team, including test managers and testers. If agile teams self-manage their work, what does a test manager actually do now? And without strong guidance from a traditional manager, how do teams organize their work? Dale Emery describes how successful agile teams resolve these conundrums-by adopting a seemingly paradoxical way of collaboration called “servant leadership.” A servant leader leads by serving and serves by leading. On high-performing agile teams, everyone is a servant leader in one way or another. There are no followers in the traditional sense and no command-and-control managers. Everyone leads-all the time. Everyone serves-all the time.

One of the challenges associated with testing in agile projects is selecting test techniques that “fit” the dynamic nature of agile practices. How much functional and non-functional testing should you do? What is the appropriate mix of unit, integration, regression, and system testing? And how do you balance these decisions in an environment that fosters continuous change and shifting priorities? Bob Galen has discovered that session-based exploratory testing (SBET) thrives in agile projects and supports risk-based testing throughout the development project. SBET excels at handling dynamic change while also finding the more significant technical- and business value-impacting defects. Join in and learn how to leverage SBET for test design and as a general purpose agile testing technique.

Jamie Mitchell explores an underused and often forgotten test type-white-box testing. Also known as structural testing, white-box techniques require some programming expertise and access to the code. Using only black-box testing, you could easily ship a system having tested only 50 percent or less of the code base. Are you comfortable with that? For mission-critical systems, such low test code coverage is clearly insufficient. Although you might believe that the developers have performed sufficient unit and integration testing, how do you know that they have achieved the level of coverage that your project requires? Jamie describes the levels of code coverage that the business and your customers may need-from statement coverage to modified condition/decision coverage. He explains when you should strive to achieve different code coverage target levels and leads you through examples of pseudo code.