How Can I Make Testing Software More Stimulating?

An anonymous reader writes "I like writing software. In fact, I revel in it. However, one thing has always kept me back from being able to write the best software I possibly can: testing. I consider testing to be the absolute bane of my existence. It is so boring and un-stimulating that I usually skip it entirely, pass the testing off to someone else, or even worse, if I absolutely have to test, I do a very poor job at it. I know I'm not that lazy, as I can spend hours on end writing software, but there's something about testing that makes my mind constantly want to wander off and think about something else. Does anyone have any tips on how I can make non-automated testing a little bit more stimulating so I can at least begin to form a habit of doing so?"

Comments

sharks with lasers

[master_kaos]

just imagine if you don't test giant sharks with lasers will attack you.. with that stimulate you enough?

Too close to the subject...

[bgibby9]

Personally I feel that the dev should never do the testing of their own code as they are too close to the subject to test every angle.

Sorry this doesn't answer you question :P

Re:Too close to the subject...

[SpinyNorman]

The developer should unit test, and the test group should system test. The two are complementary.

The test group will hopefully test the software in ways you never thought it would be used, but you'll hopefully have tested every code path and end case that only you are aware of from having written it.

Of course the developer can system test do, or at least contribute test cases.

Re:Too close to the subject...

[Z34107]

That's similar to what my workplace does. You're not really expected to test your own code - it's assumed that if you're handing it to a QAer that all the use cases you could think of are working. Instead, you get at least one round of "programmer QA" where another developer on your team examines your code for correctness and efficiency before handing it off to QA proper.

The QA folks do mostly UI and workflow testing; they're fairly technical, but they're not coders. If they manage to break anything, you get your code back to fix and the process starts from step one.

That seems to work pretty well - you're not testing your own code, but trying to break your coworker's code before QA gets a chance to.

But, how to make testing your own code interesting? I'm not sure about that - there's not much you can do to make unit tests interesting. But people finding your UI baffling suggests a lack of design. Have you ever done a mock-up and demoed it to end-user victims? They make us at least find other developers before we start throwing around hWnds.

Simple

[Anonymous Coward]

Add porn

Re:You can't?

[Anonymous Coward]

Wear a different hat each day.

Focus your attention elsewhere

[afaik_ianal]

Does anyone have any tips on how I can make non-automated testing a little bit more stimulating so I can at least begin to form a habit of doing so?

No, I don't. I strongly think you're directing your effort the wrong way, and duplicating work if you're spending too much time on non-automated testing.

Software Engineers are not good at poking holes in their own work, so you should have someone else doing the bulk of that kind of testing anyway. You obviously need to do some cursory testing to avoid wasting someone else's time, but there are much better ways of directing your testing effort.

Focus on developing unit tests both before and during the development effort. Avoid developing your unit tests after writing the code though - your mind will be tainted with your approach, and you'll miss the obvious stuff. Not only do unit tests reveal bugs, the act of writing them will also help you get interfaces right, and help ensure a better overall design for your code.

Change hat to a darker color.

[Short Circuit]

Imagine that the guy who wrote the code is the royal, snobbish jerk who always thinks his code is better than anything else. Realize that, at some point, he's going to make a change that will change the way the component behaves, and will yet again break your code that uses that component. Don't let him get away with it. Let your fingers pound as you write code to check for the smallest fault. Let your lips curl in a snarl as you feed it poisoned data. Relish in the thought that you can catch him in every slightest mistake. Think of all those things that might not think to catch in the future. Not just the important stuff that defines the role of the component, but those little things that some people might call "implementation details".

Also remember that he's the same jerk who wrote those unit tests that screwed you over all those times. Don't just pay it back; pay it forward.

Unit testing achievements

[hansamurai]

http://exogen.github.com/nose-achievements/

*
Instant Feedback
A suite of at least 50 tests takes less than a second to run.
*
Coffee Break
The suite takes between 5 and 15 minutes to run.
*
Take a Walk
The suite takes between 15 and 60 minutes to run.
*
Take a Nap
The suite takes between 1 and 5 hours to run.
*
Take a Vacation
The suite takes at least 3 days to run.
*

Coming soon!
Anticipation
One test in a suite of at least 10 is slow, and all the rest pass.

Time

*
Night Shift
Make a failing suite pass between midnight and 5am.
*
Punctuality
Make a failing suite pass at 9am (give or take a minute).

Failure

*
Complete Failure
All tests in a suite of 50 to 999 fail.
*
Epic Fail
All tests in a suite of at least 1,000 fail.
*
Minor Letdown
All tests in a suite of 10 to 99 pass...except the last.
*
Major Letdown
All tests in a suite of at least 100 pass...except the last.
*
Happy Ending
All tests in a suite of at least 10 fail...except the last.
*

Coming soon!
Heisenbug
Make a passing suite fail without changing anything.

Errors

*
Sausage Fingers
Cause at least 2 distinct syntax errors in a single run.
*
To Understand Recursion
Exceed the maximum recursion depth.
*

Coming soon!
To Err is Human
Cause all tests in a suite of at least 50 to fail with a single error.

Size

*
My God, It’s Full of Dots
The suite has at least 2,001 passing tests.

Frequency

*

Coming soon!
OCD
Run the suite at least 5 times in the spa

Re:Go work for a porn website

[hedronist]

Actually it's just the opposite. It's like working in a candy factory and quickly getting completely bored/sick of the candy. I did one site where we were having problems with certain videos in different browsers and I swear to God that there was one clip of some really hot anal action that I got *really* sick of. After about the 3rd time I would watch about 5 seconds of it, see if the problem was manifesting, and then be back in the editor.

Now I watch whale documentaries to get my jollies. ... Wait! What?

Re:the developer should participate in system test

[lgw]

Unit tests should excercise the corner cases in your code. If you know what they are, write tests for them.

QA testing should break all design assumptions about how the software should be used. Having the programmer sitting there telling the QA guy what to click on (and I've seen that far too often) invalidates that. The most useful bugs are the ones where the QA guy says "I did what I thought would get the job done, and instead it formatted my hard drive", leaving the dev to sputter "but, but, you're not supposed to do that". Given enough users, every possible "stupid" thing you can do with your software will be done in the field, and you really want to know that you will at least fail safely in all those "but that's not how you're supposed to do it" cases.