Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Software Programming

How Can I Make Testing Software More Stimulating? 396

Posted by Soulskill
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?"
This discussion has been archived. No new comments can be posted.

How Can I Make Testing Software More Stimulating?

Comments Filter:
  • by master_kaos (1027308) on Monday August 16, 2010 @08:31PM (#33270904)
    just imagine if you don't test giant sharks with lasers will attack you.. with that stimulate you enough?
  • by bgibby9 (614547) on Monday August 16, 2010 @08:31PM (#33270906) Homepage
    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
    • by SpinyNorman (33776) on Monday August 16, 2010 @08:39PM (#33271044)

      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.

      • by Z34107 (925136) on Monday August 16, 2010 @08:56PM (#33271220)

        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.

        • by SQLGuru (980662) on Tuesday August 17, 2010 @07:55AM (#33274576) Journal

          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.

      • by FooAtWFU (699187) on Monday August 16, 2010 @09:27PM (#33271488) Homepage

        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.

        • Re: (Score:3, Funny)

          by tqk (413719)

          So I like the "test driven development" approach.

          I like the "Ethel" approach (I may have got her name wrong; sorry $ethel).

          The story was there was this great tester lady, and when she found a bug she pounced on you "Ah hah!" like. She really took her job seriously.

          The developers loved her. Go figger.

          No, you can't definitively test your code. That's what users / testers are for. You can only ensure it works, within your limited space of $works. That's where $ethel comes in.

      • > 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

        • by lgw (121541) on Monday August 16, 2010 @10:15PM (#33271902) Journal

          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.

          • Re: (Score:3, Insightful)

            "but, but, you're not supposed to do that".
            Yeah, that one still makes my *hair* stand up. Most devs are superb at narrow domain problem solving. Of course, reality and users tend not to accommodate them. I can't tell you how many times I've pushed the limits of a software package to get something done and it fails miserably.

            So, yes, they will have 37 instances of the software running at once and yes, they will try and save one or more projects/files with the same name at the same time and yes, no matter h

        • Re: (Score:3, Insightful)

          by MadJo (674225)

          System testers have to know what the corner cases are. They can't guess them all
          That's why you need proper documentation, like use cases, technical designs. Often (and preferably) written by analists and not the developers.

          Preferably you have a setup like this:
          Business analyst writes documentation based on requirements from the business.
          Developers build the application, based on the documentation.
          Testers write testcases based on the documentation and test the software as soon as it is released to them.

          Test

      • Re: (Score:2, Insightful)

        by bgibby9 (614547)
        I think my point is that, devs that do unit testing are contributing to the testing overall which is sweet, but come on, who ever makes unit tests that are 'decent' enough to ensure that the testing is done correctly?

        IMHO testing should be done by people who CARE about testing. Devs who do shitty unit testing contribute to the facade that the testing is done and working properly but in reality a shitty unit test could mask other problems.

        At that point you're creating more problems than you are solving!
      • Re: (Score:3, Insightful)

        by weicco (645927)

        Developers shouldn't necessarily participate in unit tests if you follow TDD and CI techniques. Automate your unit tests and the whole build environment and you get regression tests as a bonus.

        I think that developer shouldn't test, at least, his own code. When ever I test my code it magically just works. When I pass it to someone else everything suddenly breaks. If you have to test your own code you need at least dedicated test environment.

        In system tests developers are a big no-no. We are currently running

        • Re: (Score:3, Interesting)

          by dgatwood (11270)

          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

    • by Chuck_McDevitt (665265) on Monday August 16, 2010 @08:41PM (#33271050) Homepage
      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.
    • by NorbrookC (674063) on Monday August 16, 2010 @08:42PM (#33271060) Journal
      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.
      • by euphemistic (1850880) on Monday August 16, 2010 @09:54PM (#33271746)
        You have no idea how much I empathise. My current job is to design and develop websites for what is probably the most computer illiterate demographic on earth. 45-65 year olds working in a non-technical environment, the majority being women. The assumptions and knowledge that have been ingrained into me does not apply to this group of people - this is something I very quickly learnt.

        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.
        • by bertok (226922) on Monday August 16, 2010 @10:21PM (#33271950)

          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.

    • Very true, but that would mean the company would have to employ a separate QA team. It seems many companies are too cheap for that.
      • by pspahn (1175617)

        While working at EA right after high school as a phone jockey, we were occasionally asked to work an hour or two extra to help test upcoming games.

        I was not typically interested, until they wanted testers for the new version of Madden (a favorite of mine at the time). So I went. I found bugs. I documented them thoroughly.

        Part of the deal was that we got a free copy of the game upon release. I took it home, fired it up, and the first thing I did was check for the bugs I found. Every single one of them were

        • by Sigma 7 (266129)

          In this case, testing for bugs is meant to get a list of bugs before the game gets on shelves. That way, the developers have a bit extra time to figure out the problems, and release a "timely" patch for the players.

          I heard that AvP2 had a patch before the game was released. They must have been following this concept, but mis-timed the patch release.

          • by pspahn (1175617)
            ...or is it? This was a release for a console system that did not have any type of patching capability.
        • The reality is that all software ships with bugs. Some known and some unknown. Typically it depends on how easy it is for the customer to find, what is the impact to the customer, cost to fix, and risk of regression. Given that software is typically patched after shipping, it means even more bugs get shipped rather than slipping the ship date.

    • I noticed this many times even after Microsoft figured they can never possibly test all possible uses of Windows and kinda gave away Windows 7 beta. Think about it, the Microsoft as we know gives away free, usable, fully functioning OS knowing some people will hack the "time bomb".

      Lets talk about OS X. High level developer merely changes wallpaper to something cool (they don't even do it), installs XCode, all OS X updates and codes. There is no resident software, no UI hacks (thanks to Apple, you gotta hack

    • Re: (Score:3, Insightful)

      by donscarletti (569232)

      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.

      No, the dev should never do final testing, since they have a subconscious incentive to do it badly in order to find less mistakes. However, nobody is as qualified to know the edge cases and weaknesses than the individual who just wrote it. So, the best result comes from giving the developers a large incentive to find problems in their own code before the reviewer gets to it.

  • by NEDHead (1651195) on Monday August 16, 2010 @08:31PM (#33270910)
    But you should be writing the test as you write the code
    • by Joce640k (829181)

      For coded tests (unit testing), sure.

      Sitting and using the program? Not so clear-cut. The programmer usually never does weird stuff or tries to load massive files like the users do.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        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 straightf

    • by rxan (1424721)
      I would say no under certain circumstances. When developing you often don't know how a function will work until it's "completed". I'll often write a whole class and only write the tests and documentation once I feel it's completed. When I write both tests and docs while developing I find that I end up rewriting the tests and docs. The functionality has changed from what I first imagined. Of course this wouldn't be too much of a problem with good design.
      • by Cylix (55374) *

        I do that to myself all of the time.

        If I don't write documentation and test hooks while developing the main body I will invariably do a very poor job later. The kicker is that if I change something or throw out some other bits that really means I have also have to destroy or rewrite other sections.

        In a rough guesstimate I would say that most of the code I do write invariably doesn't go through enough change to warrant not performing the other menial tasks. Generally, it works rather well and I find there is

    • Lest you think I'm a Ruby fanboy and dismiss me out-of-hand, try this or at least read about Behavior-Driven Development (BDD), as opposed to Test-Driven Development (TDD).

      Then, learn Ruby and some of the common testing methodologies, like Shoulda, Cucumber, mocks, and RSpec.

      Whatever language, OS, and framework you use, you just might change how you look at non-automated tests.

  • Simple (Score:5, Insightful)

    by Anonymous Coward on Monday August 16, 2010 @08:32PM (#33270930)
    Add porn
  • by afaik_ianal (918433) * on Monday August 16, 2010 @08:35PM (#33270970)

    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.

    • by Binder (2829)

      This... definitely this. You generally cannot test your own work. You have too many assumption about how it works.

      What developers SHOULD do is unit testing. One way to make this more bearable is to "code to the test". First create the unit tests which will prove your code does what it is supposed to.. then code until the tests pass. It's more like a game this way.

    • Unit tests are nice for some kind of programming, they rock at compiler testing and they are typically good for testing network APIs, but they are horrible for other kinds of programming. They really suck at test GUIs or anything visual, and they aren't so good for testing drivers. They also can't catch every type of bug. Since he is not an idiot, and he specifically mentioned non-automated testing, it would make sense to assume he's talking about the kind of testing unit tests don't do well.

      Expecting un
    • by dcollins (135727)

      "Software Engineers are not good at poking holes in their own work..."

      This kind of statement perplexes me. My expectation would be that engineers are scientifically-minded and skeptical and desire good evidence that something is working.

      At the last game-software job I had (now 10 years back), I was really troubled when I submitted a piece of work and the senior engineer came back pretty much astounded that, "It works, it doesn't have any bugs, and I can't even break it!". That was around the time I knew the

  • More bugs (Score:4, Funny)

    by MichaelSmith (789609) on Monday August 16, 2010 @08:36PM (#33270992) Homepage Journal

    Clearly there aren't enough bugs in the software you are testing. As an experienced C programmer I can help fix this problem...

  • BDD (Score:3, Informative)

    by Dishwasha (125561) on Monday August 16, 2010 @08:38PM (#33271012)

    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.

  • I think it's just who you are, and you're probably wise to partner with others.

    I'm quite the opposite. I like nothing better than to write a great benchmark, because I'm an optimization fiend. Also love to write a correctness testing benchmark, because it lets me check my optimizations for accuracy. However, I can't stand most high-level coding work, because I get horribly distracted. My brain gets distracted by what's happening on the metal when it doesn't matter at all, and then I get really bent out

  • First of all, try to break what you just wrote. Not hack it; just break it. Lean on the control key while typing input, feed it binary files for text & data. Run it in a VM on the slowest hardware you have. Make a game of trying to break your own code.

    Then go back and do it again, but this time play black-hat hacker. Get creative rather than methodical. Try sql statements everywhere that might touch a database. Hammer every communication method it uses with denial of service abuse and then crafty

  • I have the same problem. If you figure it out please let me know.

  • by CodeBuster (516420) on Monday August 16, 2010 @08:45PM (#33271092)
    Have you given Test Driven Development [wikipedia.org] and NUnit [wikipedia.org] a try? If you haven't heard of these things or taken one of the TDD frameworks out for a test drive then you owe it to yourself to invest some time. The software industry in general and the .NET community in particular is moving towards automated unit testing and Continuous Integration [wikipedia.org]. You should get on this train too.
    • by carlzum (832868)
      I agree, developing tests after the fact is boring and forces you to remember what you did. When you create unit tests during the creative, problem solving phase it's much less of a chore. The end result is much easier to maintain too.
    • I agree 100%

      Definitely get into TDD and do some reading on "inversion of control" it really makes you think about how rigid your classes should or shouldn't be. I wish I had some good links handy on both subjects.

      I got into both a few years ago at about the same time it was one of those "eureka" moments for me.

      I actually look forward to writing the test cases first, it points out all the design flaws I overlooked on paper or in prototyping.

  • Allow yourself one porn^H^H^H^H^H download per bug found. Not only will this stimulate you, but you will be able to test with one hand.^H tied behind your back.
  • by Short Circuit (52384) <mikemol@gmail.com> on Monday August 16, 2010 @08:48PM (#33271114) Homepage Journal

    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.

    • Imagine that the guy who wrote the code is the royal, snobbish jerk who always thinks his code is better than anything else. Don't let him get away with it. 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.

      And when you finally catch up with this righteous bastard who wrote such lousy code, be sure to pound his goddamn skull in with a tire iron.

    • Re: (Score:3, Interesting)

      by jmcharry (608079)

      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.

    • by dcollins (135727)

      "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

  • Don't test manually (Score:3, Informative)

    by Scareduck (177470) on Monday August 16, 2010 @08:50PM (#33271140) Homepage Journal
    If you're not testing your code, you're not doing your job. Find ways to automate your tests.
  • TDD is the best approach. Write unit tests BEFORE you write the code. First of all you'll be motivated to get it done. Second of all you'll write MUCH more testable code and thus spend a lot less time on testing. In the long run you will actually get to write more fun stuff than if you didn't do it this way.

    Honestly, not all testing will ever be fun, but there's really no point to writing bad broken software and untested software is invariably bad software. Honestly though whatever organization you're worki

  • Its like asking "How is the most stimulating way to self file my taxes?" The answer is most likely there isn't unless you're of the rare few that do enjoy doing just that. Easiest way is to just hand it to someone else and get creative in forms of payment, maybe booze or some movie/music/game they want for doing it (everyone is different).
  • by hansamurai (907719) <hansamurai@gmail.com> on Monday August 16, 2010 @08:53PM (#33271174) Homepage Journal

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

    *
    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

  • http://en.wikipedia.org/wiki/Milgram_experiment [wikipedia.org]

    except for you, the shocks will be real, and you will be both tester and test subject

    every time your code throws an exception, make it so you receive a small, incrementally growing shock

    after about 10 or 20 bugs, and the growing voltage of the shocks, you should be breathing heavily and sweating and be focused like a laser on ensuring the integrity of your code

  • Read The Daily WTF (Score:3, Insightful)

    by Red Storm (4772) on Monday August 16, 2010 @08:57PM (#33271236)

    http://thedailywtf.com/Default.aspx [thedailywtf.com]

    The threat that one day someone will post your code and or screen shots from your programs for everyone to ridicule should be motivation to either improve or write worse code.

  • Write a test framework that lets you expand the scope of automated testing.

  • You've just written some cool new fangled program for something. Maybe it automates a process. Maybe it creates a new interface for something. Maybe it's the next app killer. And best of all, you wrote a test suite for it during the development.

    But does the test suite itself work right? How do you know that your test suite tests correctly, and completely? Did you also write a test suite test, too?

  • Make it a game... (Score:3, Interesting)

    by LynnwoodRooster (966895) on Monday August 16, 2010 @09:12PM (#33271348) Journal
    I hate testing too! So I devised a little game with a compatriot in code: we unit-test each other's code. Each class is unit tested by the other person, and whoever finds the most bugs wins. What do you win? Usually pizza and beer. Free lunch or dinner can be a strong motivational reason, plus the chance to brag about trouncing the other person. Makes you a MUCH better "defensive" coder, always thinking about how/which parameters to validate, return codes, etc.
  • I'm a test developer right now, so this may skew my opinion. When I develop any code, whether it's tests, frameworks, utilities, or actual development, I always consider testing of my own code a stimulating factor. Do you enjoy knowing that your code works as you intended? I do. In my opinion good design is reflected by good testing. If your tests are bad then you won't know if your design is good either. This includes performance testing.

    Try this: do no testing at all for a month and see how annoyed you ge

  • Then you are lazy. (Score:4, Insightful)

    by Alcoholist (160427) on Monday August 16, 2010 @09:22PM (#33271446) Homepage

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

    • Think this way: do you prefer testing or writing documentation? at least for me, good tests are an excellent way for users of your code to learn how to use it, so they will not annoy you for comprehensive documentation. What's better, another dummy method or another title+table+paragraph in Word? This works at least for testing library code.

  • by a9db0 (31053) on Monday August 16, 2010 @09:33PM (#33271544)

    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.

  • by JuzzFunky (796384) on Monday August 16, 2010 @09:33PM (#33271548)
    You don't need to make it more interesting, you need to make it part of your routine. It's like waking up at 6am to go for a run. The first few times you do it it'll be hard, but if you stick to it and do it every single day it will become just something you do. Start small - don't try to run a marathon in your first week, just don't make any excuses or invent reasons to skip it just this once. The fact that you care enough to ask slashdot suggests that it is important enough to you to make the effort. If you can make the change and stick to it you will probably find more fulfillment in your work.
  • 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.

    It is part of your job... testing that is. Just do it. Not every part of your job is supposed to be tantalizing or pleasant. If it were, it wouldn't be a job. It's just part of what a job is. And doing those things that are necessary (even if they suck) is part of being professional. Testing does suck balls sometimes, but hey, if something sucks, do it more until it stops sucking (either because you became proficient or numb.)

    I consider testing to be the absolute bane of my existence.

    Your outlook on things certainly won't help in making things better, will it?

    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.

    In th

  • This Ask Slashdot was very informative. I'm serious. I liked this one. It's a good question.

    Soulskill +1 : Relevant ; +1 : Motivational

  • Do your unit testing, but otherwise: Hire a QA engineer. If you test your own stuff you won't see the mistakes.
  • "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."

    Well, actually, that is kind of lazy :-)

    Seriously: you do the parts you enjoy and you skip the parts you don't. That, my friend, is lazy. Or at least undisciplined. And if you are getting paid to do it ... well, that's just unprofessional.

    I'm not trying to be a jerk, it's just that I have been at this for 15 years, an

  • by BLAG-blast (302533) on Monday August 16, 2010 @09:47PM (#33271690)
    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.

  • by dr2chase (653338) on Monday August 16, 2010 @09:49PM (#33271714) Homepage

    "Here's how it works..."

    That is, if you can write a test that looks like that. I work on compilers, so the trick is to write the example that tweaks just the feature that I want to check, and not 17 others. But, my test cases look like squirrelly little programs that could actually be inputs from especially peculiar users.

    You ought to also think about demonstrating your error cases. "If you do this wrong thing, it says...." I am sort of a nut about error messages, partly because I once read the Apple Human Interface guidelines and thought they were a good thing. In particular, does the error message provide the user with information that will help him make the error message go away? When you decide that an error has occurred, what special information do you have that might help? My anti-favorite error message was "Bad SOCKS version number". Not "unexpected", not "too old and not-supported", but "BAD". Morally wrong, so unspeakable that not only can the BAD number not be named, even the good numbers cannot be named, because they might therefore name the BAD number by process of elimination. Truly unspeakable, the version number that shall not be named.

  • You come off and leave and let someone else raise the child..

    Seriously, someone who cannot test his own code cannot write good code.

  • by RedLeg (22564) on Monday August 16, 2010 @09:55PM (#33271768) Journal

    It's inherently boring....

    SO, Build hooks into the 'ware as you write it, and automate the testing.

    Work smart, not hard.

    Red

  • by crimsontime (1666391) on Monday August 16, 2010 @10:11PM (#33271868)
    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...
  • First off, try to avoid testing your own work. If your company won't hire proper QA staff (which is stupid of them, but never mind that), then trade off with a co-worker: you'll test his stuff, he tests yours.

    Now, your goal is to seek out the flaws in whatever you're testing. Be experimental - try doing things that are stupid and/or malicious. If you see a text input box, try putting in nothing, or putting in "Robert'); DROP TABLE Students; --", or putting in huge numbers of copies of the letter "A", or tos

  • by Eil (82413) on Monday August 16, 2010 @10:20PM (#33271932) Homepage Journal

    Read Slashdot instead.

  • Why do you hate testing?

    Is it because you're goal oriented (meaning you can't get motivated to spend time writing unit test code)? If so you need to do a little growing up and realise that ALL untested code is garbage.

    Or is it because you're doing it by hand (which means it's boring and laborious)? In which case the solution is obivous - you like coding, so write the code to do the job for you.

    Either way you need to adjust your attitude or find a different job. A coder saying they dont' test is like a pilot

  • My comment will probably not apply to the coding you are doing: it's an old-fashioned, 50-year-old view of programming. Software starts with a statement of what it's supposed to do, in English and without any technical jargon. Ideally, the users of the software participate in the process; sometimes the marketing department proxy for the user. The next step is to determine the solution, again in English without a bunch of jargon. You break the solution into smaller pieces, then divide again, until you h
  • Thanks for the job! I work in SW QA at (big company).

    There is NOTHING that will make manual testing suck less. It just does. I have written many a test plan for the manual test monkeys (both stateside and offshore) and I have performed many a manual test. It just sucks. There is no way around it.

    I suggest heavy stimulant use or psychoactive drugs (warning, your employer might not be as friendly to my suggestions).

  • What? Am I the only one that drinks a shot for each bug I find? I keep trying to get a job at Microsoft so I can have myself a real party.

    • I don't think anyone could survive the 1 shot per bug found at an MS shop.

      On the other hand I don't know why the OP finds it difficult... one of the most rewarding and fun things to do for me is to write code, get it to behave exactly as I want it to, write it as robustly and as well as I can, and then find some absolute garbage to throw at it. I love breaking my own code. At first its a challenge to get all the bugs out, and then afterwards comes the more fun challenge of finding something that WILL break

  • Often times, particularly in boring java web apps, the actual product code is less exciting than the unit tests I write to test them. Example:

    A product needed to limit the number of events that were fired given some maximum rate of events/minute. The events can be fired from many threads simultaneously, but all threads contribute to the same calculated rate that must be monitored. The "RateQueue" as I called it was actually kind of neat, very compact and uses java atomic variables for concurrency. But
  • ... and, in the days you set aside for testing, the first thing in the morning when you drink your coffee and slip into Jerkyll skin, swear to God that you are going to break the code in the most imaginative ways possible, and derive your satisfaction from ridiculing the stupidity of the developer.

    This is the only way I know to test my code... however painful, the advantage of the approach is that the stupidity of the developer gets known only among the two of me.

    If you cannot get a split personality, then

  • Everyone says you should unit test, and it's a good idea, but aside from that, what I try to do is write code in small pieces, and then compile and test. I try to not write more than 100 lines without being able to test it. You can't always do it, but when you can write in small pieces and test often, it does help eliminate bugs.
  • It's not boring when you think of all the bullshit and wasted time you'll avoid by testing properly from the start.

  • Adderal or Ritalin...

    Or, you could turn testing into a drinking game!

  • As a jr. level sw engineer, I abhorred testing. But I wrote the code, made sure it worked and moved on to the next feature. I was merely testing features as I went, until I made a change to the code that affected the code in more than one place.. then I was hunting bugs down everywhere because I had a function that was modified ever so slightly and it broke every thing that relied on one corner case.

    Then a few years ago, I got my first taste of XP (Extreme programming) It was a completely new experience and

  • I used to work in a group that tested each other's code. It was great. The best times I ever had as a programmer was in coming up with fiendish tests that would reduce a colleague's code to a smoldering pile of ash. Testing your own stuff is boring and you're bound to have blind spots to what to test since you wrote the code in the first place. Make it a challenge where you win if you kill somebody else's code, though, and it becomes a fun game and highly motivating.

In the sciences, we are now uniquely priviledged to sit side by side with the giants on whose shoulders we stand. -- Gerald Holton

Working...