Slashdot Mirror

← Back to Stories (view on slashdot.org)

Seeking Input for Software Verification Policies?

Posted by Cliff on from the making-sure-everything-is-done-right-the-first-time dept.

e8johan asks: "I currently work at a company in the automotive industry. It is importat to ensure quality and for our products we use extensive testing before, during and after the assembly. Now I have been asked to help in the creation of a company instuction for ensuring that all 'in-house' developed software works properly. I have written a short summary describing the essentials such as: "do not ignore compiler warnings", "always describe what the code is intended to do in your comments", "do not assume that all users run in the same environment", etc. I now feel that I need more input, has anyone done anything like this before? How do you test your software?"

2 of 24 comments (clear)

  1. Unit tests & automation by Pyromage · · Score: 2, Informative

    Use automated unit tests. It is true that it won't catch everything, but nothing will. The only system operating perfectly is off. Unit testing aint a panacea of perfection, but its a heck of a lot closer than "Well, the numbers /looked/ right!".

    Read all the extreme programming practices. No, you don't have to follow them (any or all). But you should READ them and WHY they were suggested. Knowing why will help you.

    Standard code practices are good. Anything that can help you automate things is good.

    My software can log every memory allocation and uses a quick n dirty perl script to ensure that each was deallocated (I write code with ZERO memory leaks and no garbage collection). Consider similar practices.

    Work your ass off. There is no magic toggle switch somewhere you can flip between hell and perfection, you gotta do it yourself. But I do and it aint that hard. You can too.

  2. Maybe a little obvious / easy by randombit · · Score: 4, Informative

    But if you haven't already, read the Practice of Programming. It has some good thoughts about testing applications that should help you out. And it's a pretty decent book, anyway.

    Here's a few random things that occur to me (most are probably repeats of other posts, though):

    Automate as much as you can (testing, code generation, anything that's possible to automate - do it).

    Use strongly typed languages, and strongly typed interfaces.

    Use any and all warning flags, if available

    Whenver you find a bug, add a test that detects that bug to your test suite. Then, and only then, fix the bug.