When we consciously measure something, we try to measure precisely and often assume that our measurements are accurate and useful. However, software development and testing activities are not subject to the same kinds of quantitative measurements and precise predictions we find in physics. Instead, our work is like the social sciences, in which complex interactions between people and systems make measurement difficult and precise prediction impossible. Michael Bolton argues that all is not lost. It is possible and surprisingly straightforward to measure development and testing accurately and usefully–even if not precisely. You can measure how much time is spent on test design and execution compared with time spent on interruptions, track coverage obtained for each product area, and more.

Does your test organization create test data that represents production-like data? Does it fully protect the privacy of customers and the confidentiality of the business? Effective test data creation and management are critical for improving software quality, reducing costs, and ensuring data privacy and security. Fariba Alim-Marvasti shares Aetna Healthcare's Data Manufacturing practice that generates test data which thoroughly mimics production business data. Previously, each application team would use a subset of production data and rely on upstream applications for test data. Test data availability was limited, resulting in insufficient test coverage. Now, the Data Manufacturing process uses the applications themselves to manufacture test data. Using this process, data flows the same way as it flows in production-across applications-which creates integrated data across enterprise.

When Insurance Australia Group wanted to launch a new online car insurance service, complex technical issues called for early integration and strong testing capabilities. The project was distributed across multiple partners, each working on different horizontal components and employing different development approaches. In this environment, it was critical to continuously integrate the software and test-test-test. Kristan Vingrys shares his experience establishing a build pipeline that started with pre-commit tests and ended in the pre-production environment. The agile build pipeline often enabled changes to go into production the same day the code was written and with high confidence that the new build would not cause any regressions. Significantly, this build pipeline approach supported going live only two weeks after the last feature was completed in a six-month development effort.

Are you tired of finding seemingly simple defects late in development? Do you detect the majority of defects during late-stage, formal testing? Are your development teams too resource-constrained to perform serious unit testing? Brian Robinson describes how ABB utilizes advances in automated unit testing to help their development teams perform more comprehensive testing at the component level. These techniques enable developers to create and maintain high quality unit test suites with significantly less effort. Brian's results show that many defects are detected earlier, saving time and leading to a more stable software product for later formal testing. He discusses the techniques and tools they use and ways your organization can best integrate them into your development and test processes. The tools Brian uses apply to C, C#, and Java, and can be integrated into Eclipse and Visual Studio.