Slashdot Mirror

← Back to Stories (view on slashdot.org)

QA Under The Open Source Development Model

Posted by timothy on from the sound-the-pdf-klaxon dept.

carrowood writes "A survey was conducted questioning open source developers from both large and small projects concerning their quality assurance practices. A research paper based on the survey result was just published in the Journal of Systems and Software. Some comparisions between QA practices of open vs closed source projects are made with some interesting observations. While on the whole it looks like open source QA can be as good as that in traditional software development, there were a few areas pointed out where the open source community does not do so well, such as regression testing and setting release dates. A thought provoking read."

3 of 180 comments (clear)

  1. QA is harrrrd by The+Bungi · · Score: 5, Insightful
    It's hard when everyone is sitting on the same floor of the same building - it must certainly be a *lot* harder under the distributed development model.

    Ultimately, while development can, in certain cases, be done in a vacuum, QA cannot (and should not). It's by nature a collaborative and interactive process.

    I have nothing but respect for the few (good) QA engineers I've worked with.

  2. Re:ISO by zagy · · Score: 5, Insightful

    I suspect clients requiring ISO 9001 just go for commercial software. One part of OSS often is to refuse warranty and alike - IMO this does not quite fit into ISO 9001.

  3. No surprise to QA folks by Anonymous Coward · · Score: 5, Insightful
    QA is a weak point of OSS. Over the years I've occasionally tested OSS to check out what seemed to be inflated claims of quality. Everything I've tested so far has more or less failed to pass muster. The biggest failures are in complexity metrics such as the Halstead or McCabe tests. I don't mean marginal failures or borderline cases. I'm talking huge blowouts. Nothing seems to be immune, from nasm to the OpenBSD ftpd. And fixing the problem is usually so simple--decompose a complex function or procedure into several simpler ones.

    Other areas of problems are attributable to slovenly or "don't give a damn" attitudes--unused variables, unreachable code, "magic number" constants, and so on. Ignoring values returned by a function are very common. Maybe it is acceptable with a library function, but why return a value if you aren't going to use it? It's better to make the function into a procedure by returning void. On a more theoretical level, the use of weak typing even when the language allows for tighter specification of variables. Strong typing is designed to prevent such oddities and inadvertently multiplying a color by date.

    However, in the end it all comes back to complexity. And that is where the biggest improvement in OSS quality can be obtained.