Article by: Colleen Frye
How has the role of analyst evolved in software development projects?
Richard Bender:: Initially we were all jacks of all trades. Over the years people started recognizing that you needed the domain expertise, so we got to specialization. And people recognized that testing was a specialty unto itself, which the hardware people had recognized for many decades. In more recent years, to make budget cuts they will severely curtail staff on the test side and have the analysts take the primary role in testing. I understand the rationale—the analysts wrote the requirements, therefore they should be able to test the code to make sure it meets the requirements. But that has a series of fatal flaws.
What are the challenges/issues of analysts doing testing?
Bender::
The majority of defects have their root cause in bad requirements, so if you have the people writing the requirements just assuming that the requirements are perfect, you have over half the defects not getting out of the system. And it forces the whole process to be sequential because the analysts won’t get to testing until they finish the requirements. Usually by the time code is well under way is when they’re getting serious about testing, and developers are stumbling across problems with requirements. So they never really get traction on the testing until you’re deep into the coding side, and then everyone blames testing for why the project is late.
When you have a separate test group working in partnership with the analyst you can have about 90% of the functional test cases on the shelf before the project starts, so you’re getting a lot more concurrency. Plus, by having a separate testers you get checks and balances. You have the dedicated resources and they can work more concurrently. Also, one of the more underappreciated things is human nature. If you’re an analyst and you find a defect in the requirements, it means you did something wrong. If you’re a tester and you find something wrong with the requirements, you did something right. People like to do something right, so people’s whose job it is to find defects will do that really well.
Does partnering add people or costs to a project team?
Bender:: A good partnership between the analysts, testers and developers actually reduces the total headcount and total time to market/cost to market by about 25-30%, and when you deliver you’re at or near zero defect. That’s because you’re minimizing scrap and rework—where we spend a huge portion of our effort. If you have people testing the requirements early you get those defects out, and the process we use leads pretty quickly to defect avoidance, not just defect detection.
Loading ...