By: Gil Zilberfeld
Everything we do has an economic impact because what we do has costs and benefits. Testing is about getting real feedback quickly, reducing wasteful testing activities, and putting a mirror in front of our applications. It becomes advantageous to understand the costs of these activities and direct the effort investment where it’s most beneficial.
You might think that when someone decides to write a book, everything is set up in his mind. Wrong. With my unit testing book I had a couple of topics to start with, but only after something like four months did a common thread appear. The thread was economics, which surprised even me. But I’ve started to see how economics fits into everything we do in software development, and specifically testing.
If you’ve done some kind of professional development, you probably developed certain skills. When we apply these skills, we call that work. We don’t think about it much while doing the work—sometimes even less after work—but everything we do has an economic impact because what we do has costs and benefits. Testing activities, regardless of who’s actually doing them, are the same.
Software is quite a young field, and testing as a profession is even more so. We needed testing right from the start, before a tester existed. After World War II, the software field grew bigger, and along with it came economic risks such as quality and maintenance costs and reputation loss. Back then, developers tested the software; it was part of the job. Then, in the 1980s, things changed: Computers became cheaper, and operating systems were finally stable and accommodating. Software was now cheaper to write.
At least, if you had developers. Developers were a scarce resource even before. Now the market needed more of them. This led to one of the industry’s most logical and stupid decisions. Many organizations decided they could replace those doing the testing activities with cheaper people and keep the existing developers working on features. This makes economic sense, but once developers were free from the shackles of code responsibility, quality suffered big time.
The first testers were bug catchers. Today’s testers do much more: They report the status of the product from all sides. To do that, they need to understand the risks, the market, and the users. They find ways to reduce those risks by exploring areas of uncertainty in the product, proving assumptions, and suggesting modifications. They define testing strategies, knowing that they don’t have all the time in the world and they need to prioritize their activities. In order to maximize the effectiveness of testing, they also need to be aware of the testing skills and activities in their team. Good testers understand economics.
All these qualities in a tester? No wonder we can’t find many good ones, and those we do find cost like (gasp!) developers!
Let’s see how testing activities impact the bottom line, and begin with where the testers are. We all know that in agile teams, testers are embedded in the team. There’s an economical benefit for that: When they are collocated with the team, feedback flows quickly and collaboration speeds up and becomes more effective. However, mature agile teams are now facing another challenge.
Imagine we have five teams working on a web application, and one of the testers is a performance-testing expert. All the teams need her help, but how do we manage it? We can build different models of work to satisfy the growing need of performance testing in the organization. We can develop the performance capabilities of every tester in every team (although that may be excessive—should everyone know everything?). The tester can rotate among the teams, but then she won’t really belong to any of them. Or she could offer her consulting services to the other teams and limit her time in the current team.
That’s not a process issue. Step back and you’ll see a bigger issue: how recruitment, placement, and retention of testers should work in the agile era. How many do we need, and what should their skill set be? What’s their status in the team? And shouldn’t we ask the same about developers? That’s a big HR question that can make or break an organization.
... to read more articles, visit http://sqa.fyicenter.com/art/