Slashdot Mirror

← Back to Stories (view on slashdot.org)

Practical Software Testing Resources?

Posted by Cliff on from the verification-as-important-as-creation dept.

rhartness asks: "I've been a software engineer by profession for a few years and a programming enthusiast for much longer. As my experience has increased, so has the size of the projects that I have had to work on. My software testing method involves trying to do everything I can think of that the end user might try to do. Hopefully, this will break the application if there is a bug within my code. The current project that I am working on involves numerous tiers within a smart client environment. Trial and error testing is no longer sufficient — there is simply too much that could happen. Searching the Internet for software testing resources provides an abundant amount of information but it's often quite philosophical and verbose. What are some practical resources that Slashdot readers use for testing your software projects?"

1 of 42 comments (clear)

  1. My take by Pootie+Tang · · Score: 2, Interesting

    Let me start by saying that there is no one size fits all
    solution. You described the nature of your projects to a degree, but
    not the nature of your employment.

    Do you work for a company or are you a contractor? Is your
    responsiblity just for your code or the application as a whole (which
    is another way of asking how big the team is in most cases)? Are the
    users of the software someone close to you, you can ask them "does this
    do what you want" or is this going to go on the shelf in a store and
    you have no idea who might wind up using it?

    I think these kinds of things factor into the equation. For example a
    number of people have suggested having dedicated testers. My guess is
    if you had them, you wouldn't be asking slashdot. And if you don't,
    it's probably not something you can make happen by yourself, though it
    might be a good point to bring up to your coworkers/boss.

    I disagree with the Unit Testing advice that is being given out
    too. You should have unit tests, but it will only get you so far. Unit
    tests are effective at guarding against bugs being introduced when
    making changes, but far from sufficient to make sure there are no bugs
    in the entire system. In my experience the people who most heavily
    rely on unit tests are also the ones who produce the buggiest code. I
    think some of the comments make them out to be more of a panacea than
    they actually are, and worse yet can lead to a false sense of
    security.

    Automation is extremely helpful. However if your issue is that " there
    is simply too much that could happen", it's hard to realistically
    automate all those paths. Presumably a problem with the things like
    CRUD operations are going to be tested in virtually any path through
    the application, which is why I don't think unit tests are necessarily
    what you are looking for. Still do automate everything you can, just
    be aware of the limitations.

    My advice is as follows:

    1) Keep doing what you're doing. You won't be able to catch
    everything, but if you stop trying to do mimic what you think an
    end user will do, you're going to miss a lot of things.

    2) Write code that is likely to be bug free. Easier said than done,
    but it's extremely important. Comment things, use descriptive
    names, clear separation of concerns. You already know this, but
    don't lose sight of it.

    3) Use a logging framework. Have an error reporter for client side
    apps. Write assertion checks into your code. If you try to insert a
    row into the database, check the return value to see how many rows
    were inserted. If you expected 1 and got something else, make sure
    it's logged so you can find it later. Make sure you log as much
    about the data/application state as reasonable so you can tell what
    circumstances cause that problem. Make sure it's logged in such a
    way that you can distinguish between serious errors like this and
    as-you-go debugging output.

    4) Do code reviews with other programmers. Develop best
    practices. Re-evaluate them periodically to make sure they are
    still "best".

    5) Have a short write, compile, run cycle. Test that code as soon as
    you can after writing it. If you find one of those "hmmm... I think
    this should work", try to verify as soon as you can before you
    forget. Don't wait until the end of the day and then conclude
    "guess it worked". Test corner cases while the corner cases are
    still apparent to you. If getting just created code to run is a big
    pain in the ass (which could mean o