Log in

No account? Create an account
Pirates of the Burley Griffin
A schedule bears the same relationship to reality as Astrology.
Ways of Testing Software 
30th-Jul-2009 07:40 am

Inspired by a recent exchange with ariaflame, software is often complex and difficult to comprehensively test in a single way. Much like good requirements modelling adopts views of the requirements that allow various aspects to be dealt with separately, a good test regime will test software in different ways for different reasons.

The theory is that one of these ways will pick up the critical defects somewhere along the way.

So here is a quick summary of ways of testing.

Unit testing: does this piece of code run successfully.

Function testing: does this function perform according to the requirements.

System integration: does this component of the system play nicely with the other children.

User acceptance: can I do my work using the system.

Performance: How long will I have to wait to do my work when N other users are also working.

Production Verification: Does the system still perform correctly under real conditions with real data.

And one of my personal favourites, smoke: can I make the magic smoke escape. :)

30th-Jul-2009 04:26 am (UTC)
That makes far too much sense.

Assuming of course that you can get the developers to unit test at all.

In my experience one of the sure signs of the passage of time is the 3 - 6 monthly reminder to coders about unit testing.

As inevitable as a sunrise, just less frequent. :)
30th-Jul-2009 04:52 am (UTC)
Starting with the various Agile software development methodologies, test-driven development has become quite common, regarded as a best practice, for smaller shops at least. I don't necessarily use it consistently all the time, but I do often use it for anything that is a bit tricky. And the test-driven methodology is that you write the unit tests first, then you write the code. That way, you immediately know if it works, it forces you to properly formalise constraints before wading in to code, and you can also refactor without worrying that you'll break important things and not notice.

In Agile methodologies refactoring is fairly common, so the last one explains its particular popularity in places that use some variant of Agile. Agile can be difficult to scale to big projects, and so is less common in big government projects etc, explaining why it hasn't caught on as much in the sort of projects you work on.
30th-Jul-2009 07:09 am (UTC)
Again making far too much sense there.

One thing I've observed in government is a failure to understand iterative development. I'm far more likely to see incremental waterfalls described as iterative.

Mind you, I'm not sure I could handle an honest-to-god iterative project effectively but I'm sure it would be fun to try.
This page was loaded Jan 22nd 2019, 5:01 am GMT.