test design

The power of virtualization has made it easy and inexpensive to create multiple environments for testing. How you implement your virtualization strategy can boost not only the savings on physical gear and availability of test environments but also your testing productivity. 

We've all been there. You work incredibly hard to develop a feature and design tests based on written requirements. You build a detailed test plan that aligns the tests with the software and the documented business needs. When you put the tests to the software, it all falls apart because the requirements were updated without informing everyone. But help is at hand. Enter business-driven development and Cucumber, a tool for running automated acceptance tests. Join Mary Thorn as she explores the nuances of Cucumber and shows you how to implement specification-by-example, behavior-driven development, and agile acceptance testing. By fostering collaboration for implementing active requirements via a common language and format, Cucumber bridges the communication gap between business stakeholders and implementation teams.

The practice of software development, including agile, requires a clear understanding of business needs. Misunderstanding requirements causes waste, missed schedules, and mistrust within the organization. A disagreement about whether or not an incident is a defect can arise between testers and developers when the cause is really a disagreement about the requirement itself. Ken Pugh describes how you can use acceptance tests to decrease this misunderstanding of intent. A testable requirement provides a single source that serves as the analysis document, acceptance criteria, regression test suite, and progress tracker for any given feature. Ken explores the creation, evaluation, and use of testable requirements by the business and developers. Examine how to transform requirements into stories- small units of work-each of which has business value, small implementation effort, and easy to understand acceptance tests.

Test-driven development (TDD) is a skill that takes patience to master-you can’t learn it reading a book. As with learning any new language, to gain fluency you need to practice TDD with competent coaching and lots of hard work. Many well-intentioned programmers try and finally give up on TDD because they never develop the fluency it requires. On stage, Llewellyn Falco leads a live TDD demonstration, talking through the process and microsteps of: (1) studying a feature, (2) creating an initial test, and (3) iteratively developing the related test code and feature code until the feature is completely programmed. Watch how to iteratively write a test, see it fail, and then write the feature code to make it pass. After explaining the theory behind the particular TDD technique used, Llewellyn leads participants in testing progressively more complex objects and scenarios.