Speaking of Quality

Welcome to the first issue of volume 4 of STQE. Three years ago, we started a magazine that was focused on helping software practitioners—testers, test managers, development managers, and project managers—do the things they need to do to build better software.

And building software has changed dramatically over the last half century. We've seen significant changes even over the few years since this magazine has been in existence. As the years have passed, we’ve become used to an environment of uncertainty and change. What we'll be doing tomorrow is not as predictable as it used to be. We will not just grab a tool from our toolbox and apply it to some clear task described on a detailed plan.

Things today are much less static than they once were. Our context changes all the time. We are in constant dialogue with our environment, absorbing information and affecting our surroundings and future tasks by how we choose to respond.

With that in mind, we’re starting the year with a collection of articles that we hope will help you be in better dialogue with your environment.

In the MANAGEMENT & TEAMS feature, Dwayne Phillips describes a planning process that works with the people who will do the work, taking into account the relationships between the people and the tasks, and the problems to be solved. Plans are built and owned by the team, and the team can update them as the environment changes. This planning is designed to reflect reality at the start of a project and keep up with reality throughout the project’s life.

We’re also reprinting Anna Alliso's fine MEASUREMENT & ANALYSIS article, "Meaningful Metrics," from our third year. Anna tells us how to show other people the data about software quality so they get the information they need to make good decisions.

In PROCESS & TECHNIQUES, Cindy Necaise manages the end game of a project in a way that helps software teams know where the software is relative to where they want it to be. When customers and the team know about the state of the software, they can make reasoned decisions. They can make those decisions based on the environment, not on a static plan.

Two of our articles are about developer testing. In the TOOLS & AUTOMATION feature, Andy Hunt and Dave Thomas describe what it's like to be a developer who loves to test; Jason Bedunah looks at unit testing from the manager's perspective in FROM THE FRONT LINE.

The intent of today's developer testing is importantly different than it was in the past. It is not just about finding bugs; rather, the new developer testers write tests first in order to understand design. In a very real way, developer testing is another form of explicit conversation: between a programmer and the possibilities inherent in the code at that point.

Finally, in THE LAST WORD, Jerry Weinberg counsels us on how to talk about quality to create shared understandings of what is desired and what is possible. When communication about quality is explicit, teams avoid playing games that lead them to hide the real state of the software, hoping that someone else will be the first to blink.

As we said above, we software people spend our days in a dialogue with our environment—with our customers, with our peers, with our tools, with our product. Work today is ever more a conversation with many parties and at many levels. It is our hope that we can support you in that dialogue.