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?"
Change hat to a darker color. (Score:5, Interesting)
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.
Re:sharks with lasers (Score:4, Interesting)
Or another way to make it more fun - Godlike!
http://github.com/gunn/godlike [github.com]
Plays a sound when you acheive 100% test passing rate. The default sound is the Unreal Tournament voice: GODLIKE, but you have as other sound options: headshot, killingspree, perfect, supreme_victory, ultrakill, flag_capture, and frag.
Re:Too close to the subject... (Score:5, Interesting)
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.
Re:It may not be more stimulating (Score:2, Interesting)
That's exactly whats wrong with programmers these days. They never try large inputs. Like say, more than 1024 characters for their 1024 character, null terminated string. They never try weird input, such as input containing single quotes. Not so clear cut? I say, very clear cut! Programmers, that can't think of weird or bad stuff to give their program to swallow should not be programmers at all. They don't deserve it. How can they write good and secure code, if they can only ever think of the most straightforward way of using their program.
That said, it is different from the repetitive and boring clicking through your application from a users point of view. But in that case, do automated user tests (where possible). Where not, get a grip. Force yourself to do boring stuff. Its a skill you need in life anyway. Trying to make things interesting only ends in creating over-engineered solutions.
I don't say the story submitter is such a person, but a lot of people write "interesting" software, rather than the software that is needed. You can make programming interesting and have fun all day long and in the end, the customer still doesn't have his application running, which should have taken a month to implement. Instead he gets a framework for a framework for a framework to create the application that he really wanted after 12 months.
Make it a game... (Score:3, Interesting)
Re:Too close to the subject... (Score:1, Interesting)
Over time you learn to find joy in figuring out all the ways your app can go wrong and develop software that can deal with the real world. You sound a bit like a music student who doesn't like practicing their scales. Mastery takes time, like music. You can riff a bit, good for you, but you aren't developing software just for yourself (well, maybe you are). You are writing software for others to enjoy.
Re:Too close to the subject... (Score:4, Interesting)
Dropdown select boxes? Not enough of a visual cue, despite being pretty standard interface elements for decades now. The word online? That's fine. The word offline? Too technical. The phrase 'more options' in the context of a search box? They didn't understand what that meant.
Everytime I do user testing, my mind is absolutely blown by the number of things I've taken for granted about user interfaces. Swearing usually entails after finding out your design is no longer possible due to one of these underlying assumptions. The moral of the story being, you need someone else to test your work... and if you have no eye for user interface design, find someone who does.
Re:Too close to the subject... (Score:1, Interesting)
While its effectively a good idea to have somebody else test your app (even more if it has a UI), I think it is even better to design the UI with the users before actually creating it : Create a mockup of the interface, ask the users how they will use the app, what they do most often, etc, and keep them involved in the development cycle with constant reviews of the system. This way, you won't end up with your finished product, only to find out that your UI needs to be redone completely, and the core logic behind at the same time.
Just something I've learned in the past few years ... You'll see, not only will you end up with functionnal applications in the end, but you'll also have enthousiast users that will be more than happy to help you or to promote your work.
Re:Change hat to a darker color. (Score:3, Interesting)
Not bad, but pair with somebody. Test each others code, balance off the bugs, and pay for the difference in beers, or some other appropriate currency. Just gloating might do.
Re:Too close to the subject... (Score:3, Interesting)
A fun bit of psychology: assuming you're from a country where traffic lights follow the usual red-yellow-green pattern, you should make successful tests show the word "OK" in uppercase green. Make unsuccessful tests show the word "fail" or "Fail" in lowercase/mixed-case red. This causes you to feel a sense of satisfaction when tests come up green, and in some subtle way causes you to enjoy creating more tests because things turn green.
You do, however, have to be careful not to allow yourself to fall into the trap of changing the test result data to match the actual results just to get more green (unless you're sure that the changes really are expected, of course). That requires a great deal of discipline.
Re:Too close to the subject... (Score:2, Interesting)
Maybe you should arrange that changing the test cases causes enough work to offset that urge. For example, if you are working on a machine where you have root, you could add a second account for yourself as tester, and use an extremely tedious password for that. Then, when the test cases are ready, log out of that account before using the (readonly from your developer account) test cases. Since it's tedious to change a test case (log in to the test case account, type tedious password), you'll avoid it if it's not necessary (it also is an incentive to get your test cases right before applying them).