How Can I Make Testing Software More Stimulating? 396
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?"
It may not be more stimulating (Score:3, Informative)
BDD (Score:3, Informative)
First off, don't do non-automated testing. It's unnecessary. Do Behavior Driven Development with Cucumber http://cukes.info./ [cukes.info.] It's massively more fun than unit testing.
Re:Too close to the subject... (Score:5, Informative)
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.
You need to get into Test Driven Development (Score:5, Informative)
Don't test manually (Score:3, Informative)
Re:Too close to the subject... (Score:5, Informative)
It's hard to effectively test after you've written code, because it is really boring. So I like the "test driven development" approach. You write the test first (or shortly after some very skeletal code) and when it passes, you know that you're done. (Well, or that you need to write more tests.) The time spent writing tests doubles as time to review and internalize the requirements of the task ahead of you. Benefits of the approach include extensive unit test coverage (which provides cover for you when you're refactoring) and uncovering (or sometimes even anticipating) boatloads of small bugs, long before they even hit QA.
the developer should participate in system testing (Score:3, Informative)
> The developer should unit test, and the test group should system test.
In my experience, the developer should participate in system testing too.
System testers have to know what the corner cases are. They can't guess them all (unless they're more skilled at each unit than the unit's developer is, in which case what's this product genius doing in the system test group!). Brute force takes too long for most systems, and even brute force requires knowledge of what variables to change and what ranges to span for each variable.
I used to program embedded systems for oil pipeline tools. (Not a sector with a glowing reputation for reliability right now, but bear with me.) The system testers had decades experience in pigging, hydraulics, tool operation, an ISO certification, but they weren't programmers. The whole team participated in system testing (or a member of each unit group did), so that we'd collectively know all the combinations worth testing.
(As for answering the question of the story, I think the asker really should have given a hint as to what sort of software it is.)
Cultivate a bit of self discipline (Score:3, Informative)