Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Test, Test and Test Again 41

snikkersnak writes "Richard Collins has written a piece about developers and testers; the article is arguing that in closed development these two roles have to be chained together one-on-one in order to reproduce the 'release early and often' effect of open source development."
This discussion has been archived. No new comments can be posted.

Test, Test and Test Again

Comments Filter:
  • ABsolutly (Score:5, Funny)

    by Ingolfke ( 515826 ) on Monday January 08, 2007 @08:38AM (#17506858) Journal
    I am in 100^ agrement hear. Far to often developer dont test and check they're code before they release it This resultsi n a poor edn-user experience. Tey wrok two fast always trying to git on to to the next thing.

    Test test tst!!$
    • by pestie ( 141370 )
      The average quality of postings on the intarwebs being what it is, I was well into the second sentence before I even realized that post was a joke.
  • one-to-one (Score:3, Funny)

    by brenddie ( 897982 ) on Monday January 08, 2007 @08:42AM (#17506886)
    one tester for each developer?? bah, I have around 300 users^Wtesters.....
  • Besides, there are books on testing. What's the point of this little spurt of typing?
  • The article is very good, but I disagree with the part of "one tester per developer". I don't believe there is a formula to use, since each system is/can be a different case. I don't have a good theoretical background about the subject, but for me it always seemed a good idea to divide the system in specific parts like 'login routine', 'add foo routine', 'database connection' (...), and then test them.

    Too amateur?
    • by aadvancedGIR ( 959466 ) on Monday January 08, 2007 @09:01AM (#17506994)
      That's the kind of testing you can actually do fast and close to the development team, but the real problems come from the impact your code could have on parts you barely know they exist in the full system.
      Parts testing is just step 0 of the testing process.
    • Re: (Score:3, Interesting)

      by eric76 ( 679787 )
      I always test everything in detail as I write it. A good tester would be left with checking for something I missed, but that wouldn't take a full time tester.

      At one time, I had a tester assigned to me half time. That was when I was given someone else's code to fix. That was the worst code I've seen outside of a classroom. The writer, for some bizarre reason, had been promoted to project manager in spite of the fact that he had only been a software developer for a couple of years or so. Prior to that, h
      • by functor0 ( 89014 )

        That was the worst code I've seen outside of a classroom. The writer, for some bizarre reason, had been promoted to project manager in spite of the fact that he had only been a software developer for a couple of years or so.
        If he's that bad at coding, I'd promote him to project manager just to keep him from coding!
  • Automated unit tests (Score:5, Interesting)

    by tcopeland ( 32225 ) <tom@NosPam.thomasleecopeland.com> on Monday January 08, 2007 @09:25AM (#17507170) Homepage
    I think the trick here is for the developers to write lots of automated unit tests. This catches the vast majority of obvious bugs, and lets testers become more like "power users" or something. That is to say, rather than the testers writing bugs like "I did xyz and it crashed" they can write bugs like "it'd be great if this screen had a 'quick user lookup' field". The testers then begin to think of ways to improve and streamline the application, the end users get a better experience, and the developers have more fun because they're actually adding features rather than constantly fixing easy bugs.

    Andy Glover [thediscoblog.com] has a good blog on testing and QA in general. He uses FitNesse and TestNG and various other Java testing tools so he's pretty up on all the latest junx.
    • You seem to have confused QA and BA.

      It's OK, our QA group tends to as well.
    • Re: (Score:2, Interesting)

      by Anonymous Coward
      Oh, good idea! Have the developers do testing, which frees up the testers to do design work.


      If you think that the work of testers can be replaced by unit tests, you either have really stupid testers or really stupid developers. Or both.

      Unit tests don't fix bugs. A unit test tests a unit (hence the name), so if 'xyz' is a complex setup, it's likely your unit test won't have caught it. If a developer thought it could happen, he would have fixed it to begin with. Testers are there to find bugs that d
      • Re: (Score:2, Insightful)

        Well... Testers can't be replaced by unit testing, nevertheless unit testing does have some merit.
        When a tester spots a bug, a unit test might be written to document the behaviour, that the developer didn't think of, thereby reducing regressions.

        In additional to 'bugs', testing is useful in checking whether an application performs a task as dictated by a specification, i.e. missed functionality. Unit testing won't catch bugs in code that hasn't been written in the first place!

        As for the 'design work' matter
  • When he started out stating that all physics grads are stupid. If I wanted stupid name calling, I'd go eavesdrop on next doors kids.
    • Re: (Score:1, Insightful)

      by Anonymous Coward
      ...stating that all physics grads are stupid.

      First of all, I don't believe that is what he said! Quite the opposite, he seems to imply that physics grads are smarter (in at least one area) than compsci majors! And I think that is right on! Physics grads are trained in mathematics, physics and, more generally, how to solve a host of complicated problems. Compsci grads are taught programming languages and algorithm construction and not a helluva lot of problem solving.

      I personally prefer programmers who are e
      • Re: (Score:3, Interesting)

        Just re-read his opening comment. I was imagining a class of physics students licking butter off of bread, and it may have led me astray.

        As for the CS/Physics thing, I find physics grads (me, BTW) have a big weakness when it comes to 'correctness', and being able to simplify algorithms. If they can fix those weaknesses, they become better than ordinary CS grads. The same for CS grads not being able to break out of problems, if they can broaden their narrow focus on 'code elegance', they to can do great thi
  • by Blakey Rat ( 99501 ) on Monday January 08, 2007 @09:39AM (#17507272)
    From my experience, open source software may be released early and often, but it sure isn't tested thoroughly. Sometimes it seems to me that it's not tested at all, when extremely blatant bugs appear in releases. (One of the recent ones I found is a Import dialog in Inkscape that doesn't alphabetize correctly. This isn't 1985, open source developers, alphabetization of a list of files is a solved problem!)

    Of course, I also don't think "release early and often" is a good philosophy. If you release early, by definition you're releasing something that isn't yet ready for the public, and when the public uses it they're going to be disappointed and a lot less likely to try your next version.
    • I think he may be refering to internal releases. Instead of hoarding a load of fixes/features for large releases, increase the amount of incremental releases so the testing team can get their hands on the code as it is written.
      • That's a possibility, and is probably good advice unless your build system is especially cumbersome.
  • I have to call bullshit on that argument.

    First of all the word "early" in the good old "release early, release often" mantra really means releasing untested software.

    Secondly, pardon my own misleading subject line, the division is not about libre vs. proprietary (open source vs. proprietary). It is between gratis vs. non-gratis software. When people use software they expect to get what they pay for so when the users do not pay in cash they pay in testing time. This time is what non-gratis developers

    • Re: (Score:3, Informative)

      by TheRaven64 ( 641858 )
      Many Free Software projects (the BSDs in particular) split the tree into three sections:
      1. The active development 'this may compile, and if it does, then it may work, but don't expect it to be stable' branch.
      2. The 'this stuff seems to work, but may still break' branch.
      3. The 'we think this stuff is stable now' branch.

      On FreeBSD, for example, these three branches are called -CURRENT, -STABLE, and -RELEASE. Typically, only active developers run the -CURRENT branch, but a lot of people run -STABLE. People runn

  • When asked to comment on whether this methodology would be adopted at Microsoft, Steve Ballmer responded "developers developers developers testers testers testers!"
  • Heck, I even run internal tools that I write for internal company developer use past other programmers as a sanity check (after using them myself extensively) to make sure that things are actually working before I make the tools available to the general developer public.

    Multiple testers are better than one, since different users often have different approaches, and I think testers are optimally obtained from a pool of actual end users (or in our case, quite often, from a pool of business analysts who either
  • Moo (Score:2, Interesting)

    by Chacham ( 981 )
    Don't forget The Career Programmer [slashdot.org] which discusses testers at length.
  • I've been a professional software developer for over ten years. Based on my experience, I can say with certainty that there are three main sources of bugs.

    In order, they are:

    1. Lack of sensible high-level design and architecture. This causes the bugs that require massive amounts of churn or ugly hacks on top of hacks to fix.

    2. Source code that was written without regard for human maintainability/understandability/readability. This causes the bugs that take the longest time to investigate and which are th
    • Your list appears to be of items that make finding or correcting bugs more difficult, not a list of sources of bugs. Source code that was written without regard to human M/U/R doesn't necessarily contain more bugs than code that does take these concerns into consideration.
  • The first few paragraphs were so poorly written and full of unfounded opinions (even the EDITOR had to step in three times to comment on it!) that I couldn't even get to the potentially interesting parts... since I knew I wouldn't be able to trust anything else after that point.
  • Without development, there won't be much testing. Likewise, without testing, there won't be much development. Farewell, reputation.

Things equal to nothing else are equal to each other.