Testing and Quality Control the only Certification Needed?

Posted by Sadek Drobi on Jul 25, 2007

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Software Testing ,

Architecture ,

Training / Certification ,

Agile

Tags

Certification ,

Testing ,

Quality

A new certification for software developers should not be about OOP, metaprogramming, macros, design patterns or any in depth knowledge of programming languages. Reginald Braithwaite believes that only one subject must be on the examination list: testing and quality control.

Braithwaite stresses that this is not a debate on "whether to have separate testers or whether programmers should test themselves." He simply asserts that, judging from his experience, safety is of crucial importance for software development in commercial environment. Hence, developers' ability to ensure that software does what it is expected to do should be the prerequisite to any software development job:

My point here is that it's tough to call yourself a "professional software developer" if you aren't intimately familiar with the processes by which we evaluate the result of your work.

Imagine walking up to a Structural Engineer and talking about stress-testing materials. Wouldn't you be worried if they shrugged and said, "that's testing, I just design stuff"?

Certification is not meant to impose technology choices to businesses. It is not even meant to impose any kind of standards in term of software solidity. Managers can decide to ship software full of bugs, provided they are aware of that fact.

Such approach to certification is viewed as simplistic by Peter Harkins who argues that there is more to software development then safety. Using the restaurant business analogy, Harkins stresses that he certainly doesn't want to be poisoned while eating out, but he also wants "fine food, not just fast food." Braithwaite retorts that one may dislike Mc Donald's, but this is not a reason "to legislate them out of business." Having upper standards for software is good but one should not force it on others.

For Kyle Lahnakoski, certification is meant to provide information that is otherwise missing on labour market. If focused on safety, it may result in important losses for the company if the developer turns out to be "safe" but not "efficient". Chris, however, considers safety oriented certification as a good baseline criterion for hiring employees:

On top of this - and perhaps this is obvious and thus redundant - would then come the consideration as to whether or not someone can actually write code (cook), write good code (cook well), loves writing code, works well in a team, fits with the company, and the such (cooks well enough to work in an n-star restaurant).

This goes along with Braithwaite belief that whether a developer is employable is something marketplace can decide, based on technical skills and productivity of this developer. Certification is not the only requirement for employment, exactly as Chef's papers do not guarantee getting hired by a restaurant:

Do you think a restaurant would hire anybody with their Chef's Papers? Well, some might, but some would want to know who you've worked with, some would demand that you cook them a meal. And so it is with certification. I suggest such a thing be considered necessary but not sufficient.

Safety is the prerequisite; for the rest markets will decide.

1. Back to top

   Same certification for companies

   by Alex Popescu

   I think that the same certification should apply to the companies and their budgetting management. In my experience, the only developers avoiding testing were those that never got a budget for this. And even if due to this their life was/is harder there is almost nothing they can do :-(.
   
   ./alex
   --
   .w( the_mindstorm )p.
   ________________________
   Alexandru Popescu
   Senior Software Eng.
   InfoQ TechLead&CoFounder

   Reply

2. Back to top

   Re: Same certification for companies

   by Sadek Drobi

   I think that the same certification should apply to the companies and their budgetting management. In my experience, the only developers avoiding testing were those that never got a budget for this. And even if due to this their life was/is harder there is almost nothing they can do :-(.
   
   ./alex
   

   
   I guess it depends on the company. Some companies target this market of buggy cheap software. Personally I would quit fast after I am hired in such a company. For some other companies, quality really matters, and that’s where you can fight for having a budget for quality. Most of my missions fall in one of these two company cases. Surely there might be others, where quality matters, but management is not aware of methods that assure it. In that case, well they will once realize it. Hope it won’t be too late for them :)
   
   Sadek

   Reply

3. Back to top

   Re: Same certification for companies

   by Alex Popescu

   Looks like I wasn't able to pass my message thru :-).
   My point is that it would be nice if you would be able to know upfront if a company is using correct processing before joining it and having to fight to establish these processes (or quitting).
   Also, by reading your message I am getting the impression that you've been in the position where people/developers were afraid of testing. In my experience I haven't seen this, but rather situations were people were not able to start testing due to some real reasons (lack of budget, lack of experience, wrong solutions, etc.).
   

   Some companies target this market of buggy cheap software.

   
   This may be shocking but:
   - the lack of testing budget doesn't mean the software is cheap
   - (believe it or not :-) ), I've seen successful projects with very small QA cycles.
   However, I am not saying that this is happening everywhere.
   
   bests,
   ./alex
   --
   .w( the_mindstorm )p.
   ________________________
   Alexandru Popescu
   Senior Software Eng.
   InfoQ TechLead&CoFounder

   Reply

4. Back to top

   Re: Same certification for companies

   by Al Tenhundfeld

   >>- (believe it or not :-) ), I've seen successful projects with very small QA cycles.
   
   I believe it. Unless the software is inherently complex, I think ensuring the business goals are being achieved is much more important than having a robust testing and QA process.
   
   I like to use TDD in an Agile framework, mostly bits of Scrum and EVO. But in my experience, the largest "bugs" are not due to bad code; they are due to developers working against incorrect, insufficient, or obsolete requirements. If the QA cycles don't include some type of business stakeholder review, you're not really assuring the important quality metric, I think.

   Reply

• Older >