Slashdot Mirror

← Back to Stories (view on slashdot.org)

How Can I Make Testing Software More Stimulating?

Posted by Soulskill on from the flamethrowers-spice-up-any-chore dept.

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?"

13 of 396 comments (clear)

  1. Too close to the subject... by bgibby9 · · Score: 5, Insightful

    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

    --
    http://www.gibby.net.au
    1. Re:Too close to the subject... by Chuck_McDevitt · · Score: 4, Insightful

      The developer should never be the ONLY one testing the code. But the developer should absolutely test the code before turning it over to QA. You should be convinced your code works before giving it to someone else to test.

    2. Re:Too close to the subject... by NorbrookC · · Score: 4, Insightful

      When I wrote code, I knew how the program was supposed to work. I made the user interfaces "obvious" - to me. So my "testing" was along the lines of "does this compile properly," and "does it output what I expected it to?" The rude awakening came when I handed off the "finished" product to someone else. All sorts of errors I hadn't thought about handling happened, people were confused by the user interface, and more than one "oops" cropped up. While the "boring" testing you're doing on your code may catch the obvious things, it's always better to have someone else test it.

    3. Re:Too close to the subject... by bertok · · Score: 3, Insightful

      UI design is one of those areas of expertise that is both an "Art" and a "Science" at the same time. Very few people are capable of excelling at both simultaneously. That's why you end up with ugly but capable interfaces, or beautiful but useless interfaces. There are several examples in other industries that are similarly difficult, and the people who do them tend to be highly paid specialists. Plastic surgery comes to mind, for example.

      The computer industry hasn't evolved to quite that level yet, people just don't realize that good UI design is hard, so it often ends up a some random task assigned to whoever is available.

    4. Re:Too close to the subject... by Firehed · · Score: 3, Insightful

      If your users aren't testing your code, then you don't have users.

      Of course, they shouldn't be the first people to test your code...

      --
      How are sites slashdotted when nobody reads TFAs?
    5. Re:Too close to the subject... by SQLGuru · · Score: 3, Insightful

      Yep. Much more fun to try to break someone else's code than it is to trudge back through your own. Pair up with someone (officially or unofficially) and swap code. Your goal is to find more bugs than he does. I've got a reputation for finding "gnats" that I'm quite proud of. Everyone "hates" that I find them, but the code from our group is usually pretty solid because of it; making the whole team look good.

  2. Simple by Anonymous Coward · · Score: 5, Insightful

    Add porn

  3. Focus your attention elsewhere by afaik_ianal · · Score: 5, Insightful

    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.

  4. Then you are lazy. by Alcoholist · · Score: 3, Insightful

    "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."

    Which sums up why software is so shitty today. I seriously hope that you don't write software for the areospace industry because I don't feel like falling out of the sky because you were too bored to test your code.

    Every job has its boring moments, testing your code is one of those things that programmers must do. Should do, it encourages discipline and discipline is what makes good code. You can automate the testing to some degree but at some point you've got to poke it and prod it yourself because computers are stupider than even we are. If you can't hack that, find a different line of work.

    --
    Bibo Ergo Sum.
  5. You can't, so don't try by a9db0 · · Score: 4, Insightful

    I do software QA for a living. And if you're not a tester, don't try to be. It's your job to write code that meets spec, runs clean, is efficient and effective. Write it well. Write it secure. Write it to handle errors from data, users, networks, etc. Double check that you validate input. Make sure it doesn't leak memory. Write good unit tests. Test it enough to make sure it works. Then give it to a tester.

    Good software testers are a different breed. They are a sceptical, picky, pedantic, detail oriented bunch who take new code as a personal challenge to find the inevitable bugs. They will test your code a dozen different ways you would never think of. They will find bugs that could not possibly exist. They don't care that your shiney new whistle or bell will be the next big thing that will make you all rich. They care that it doesn't barf when you pass it a string with more than 256 characters. Including special characters. In German. Or Japanese. They care that when it's been running for 12 days straight with automated stuff beating on it that the memory usage hasn't ballooned. They care how it deals with data files 10 times larger than you say it should handle, or runs on a machine with half the ram it should have, or handles twice the workload it should - because somewhere out there is a user who will ask it to. They will chew it up, spit it out, and ask you to fix it. Then they will do it all again.

    Testers are a strange bunch, and good ones are hard to find. Find some good ones and cultivate them. They are a lot cheaper than a ticked off client.

    --
    -- "Never underestimate the power of human stupidity." - R.A.H.
  6. how to make non-automated testing simulating? by BLAG-blast · · Score: 3, Insightful
    Simple. Automate it!

    I used to dislike testing until I learn how to implement code designed to be tested. Use a dependency injection frame work (that will keep you busy for a while) and write testable code. Writing elegant, readable code which scalable and testable is not an easy or boring task. If you can not automate the tests, you are probably do something wrong.

    --
    M0571y H@rml355.
  7. Testing is a mindset more than anything else by crimsontime · · Score: 3, Insightful

    Do you enjoy finding the weak points in things? Do you use new devices, maps, etc without reading the instructions because you just think you should just know how they should work? Do you find that alarm bells go off in your head when you read a phrase that could possibly interpreted in more than one way? Do you often use things in ways that they were never intended yet those ways seem the most logical to you? Do you possess powers of intuition that lead you unforseen vulnerabilities? Do you find the needle in the haystack? Coding isn't inherently more interesting than testing. Anyway, if you identify with any of these phrases, you can apply it to testing...

  8. Re:the developer should participate in system test by lgw · · Score: 5, Insightful

    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.

    --
    Socialism: a lie told by totalitarians and believed by fools.