Quality Is Job #1
Those of you who've been reading my previous articles will probably agree that I usually make an effort to stick to objective subjects with recommendations that can be verified and even quantified. However, certain topics are harder to quantify and defend scientifically. One such topic is the value of a dedicated team of testers.
Should organizations developing software (a) have a team of dedicated testers, or (b) make the developers solely responsible for the quality of their application?
Based on my experience at companies that have used both strategies, the answer is clearly (a). If you're in a hurry and don't have time to read this article, just go ahead and hire 1 tester for every 2-3 developer in your organization. Otherwise, read on and discover why a dedicated team of testers is so important.
Developers Don't Like to Test
The sooner you accept it, the better. The vast majority of developers do not like the activities associated with testing. By testing, I don't mean executing ad hoc feature tests to verify whether or not the code works. I mean formal testing activities, like writing and updating detailed test cases, raising problem reports with detailed “How To Repeat” sections, setting up valid testing environments, executing formal performance and reliability tests, etc.
And what happens when developers don't enjoy what they're doing? That's right! They do the job as quickly (read “poorly”) as possible so that they can move on and develop some other core product functionality.
What Do They Mean by Almost Done?
Ever asked a developer how his/her project was going? “I'm almost done!” is usually their answer. But what does almost mean anyway? And what about done?
I've had developers tell me that they were done when they had in fact not even committed their code to the source repository. When I asked them what they meant by done, they replied their code worked on their machine. Sure, they had not committed their code, integrated their feature, installed it on the daily build or developed unit tests yet, but That's something you do after you're done, right? Wrong!
Being a Good Tester Calls for Specific Skills
The best testers (just like the best software developers or project managers) require specific skills. If you're not a professional tester yourself, you might think that anyone can test software, but let me ask you this. Certainly anyone can pick up the latest copy of Teach Yourself Java in 21 Days, or Project Management for Dummies, but does that make them good developers or project managers?
Testing Goes Beyond the Software
While testing software obviously takes up most of the testers time, there are other areas that need testing, like user guides, white papers, and customer training programs. If you agree that software developers are perhaps not the best candidates for testing software, imagine how poorly they'd test your 500-page user guide!
Quality Should Be a Priority
Let’s be honest. When schedules get compressed, developers don't spend less time implementing functionality. They spend less time testing their application. Their top priority, rightly so, is to develop features as defined in the SRS (Software Requirements Specification).
Agreed, project schedules never get compressed (How do you spell “sarcasm”?). But if they did, wouldn't it be nice to be confident that the application has been properly tested and meets your quality acceptance criteria even though the developers were rushed to commit their code?
In Summary…
Having a dedicated team of testers is, in my professional opinion, well worth the investment.
- Professional testers enjoy testing applications. The best of them find this activity challenging and rewarding, and as a result, are great at it.
- Since they enjoy testing software and have built their career around this activity, they possess the skills required to be a good tester and are keen on learning new skills.
- They are objective. They're not afraid to accurately and truthfully report the status of the individual projects because they don't feel like they are being held responsible for keeping feature development on track.
- They are excellent candidates for testing other areas of your solution, like documentation and training material.
- Quality is their #1 goal. No matter how much you compress the development schedule, your testers’ top priority will always evolve around testing software and evaluating its quality.
Still not convinced that having a dedicated team of testers is more beneficial than making your developers solely responsible for software quality? Would you like to share arguments that support NOT having a team of dedicated testers? Please forward me your comments, and perhaps I’ll make them part of a future article.
This article was originally published on www.gantthead.com.