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.

When you start writing unit tests, the tests that seem useful might be too involved to give a quick payback. The ones you write quickly might seem too trivial to add value. By starting with small, seemingly simple tests, you can both overcome the inertia that stops you from testing and add value to your project.

To ensure the quality and safety of Web applications, security testing is a necessity. So, how do you cover all the different threats-SQL injection, cross-site scripting, buffer overflow, and others? James Knowlton explains how Ruby combined with Watir-both freely available-makes a great toolset for testing Web application security. Testing many common security vulnerabilities requires posting data to a Web server via a client, exactly what Watir does. The Ruby side of Watir, a full-function programming language, provides the tools for querying the database, checking audit logs, and other test-related processing. For example, you can use Ruby to generate random data or large datasets to throw at a Web application. James describes common security attacks and demonstrates step-by-step examples of testing these attack types with Ruby and Watir.

Exploratory testing is a popular approach, but many testers secretly worry they might be doing it wrong. Jonathan Kohl addresses those concerns by explaining exploratory testing in ways that testers identify with.