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?"
sharks with lasers (Score:5, Funny)
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: (Score:2, Funny)
Too close to the subject... (Score:5, Insightful)
Sorry this doesn't answer you question
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.
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:Too close to the subject... (Score:4, 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.
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.
Re: (Score:3, Funny)
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.
Re:Too close to the subject... (Score:4, 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...
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
Re:the developer should participate in system test (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.
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)
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)
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)
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)
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
Re: (Score:2)
Pop some Ritalin so the person in question 'chills out' and can focus? Or as an alternative to red bull?
Ritalin is actually an upper (to those who aren't afflicted with ADD/ADHD, which I imagine most developers aren't) and would be counter productive in most situations. Unless you are going with the idea many soccer moms do, so exhausted they need something to keep them going, so they hit up little Billy's stash of uppers they don't actually need.
Re: (Score:3, Insightful)
At the risk of sounding pedantic, I'd suggest that you limit your email testing to either address you own, or else domains like "example.com" that are reserved for testing. Domains like asdf.com are routinely flooded with unsolicited email due to people using it as a bogus domain name. More importantly, by using real domain names while testing software, you risk inadvertently emailing sensitive data to somewhere it should not go!
Re:Too close to the subject... (Score:4, Insightful)
Re:Too close to the subject... (Score:5, Insightful)
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:4, 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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Software always ships with bugs (Score:3, Insightful)
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.
Also Developer machines aren't end user machines (Score:2)
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)
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.
It may not be more stimulating (Score:3, Informative)
Re: (Score:2)
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)
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
Re: (Score:2)
Re: (Score:2)
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
Learn Ruby and BDD (Score:2)
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)
Focus your attention elsewhere (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.
Re: (Score:2)
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.
Re: (Score:2)
Expecting un
Re: (Score:2)
"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)
Clearly there aren't enough bugs in the software you are testing. As an experienced C programmer I can help fix this problem...
Re:More bugs (Score:4, Funny)
Let me guess, you can do that by writing your code in java or C#
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: (Score:3, Insightful)
The requirements are vague, such as "difficulty of problems presented to the user must increase gradually over the course of the session," where difficulty isn't defined rigorously.
Uh, you define the requirement. If you've written code, you've *already* done that, you've just made the requirement inaccessible as its now encoded in a programming language. Write it down first and everyone will be happier.
The application's specification includes a physical simulation with random, pseudorandom, chaotic, or ot
It's just who you are. (Score:2)
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
A few challenges (Score:2)
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
good question (Score:2)
I have the same problem. If you figure it out please let me know.
You need to get into Test Driven Development (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
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.
Reward yourself! (Score:2, Funny)
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: (Score:2)
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)
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: (Score:2)
"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)
Test Driven Development (Score:2)
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
Your asking the impossible (Score:2)
Unit testing achievements (Score:5, Funny)
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
recreate the stanley milgram experiment (Score:2, Funny)
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)
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.
Make it Automated (Score:2)
Write a test framework that lets you expand the scope of automated testing.
How about testing the test? (Score:2)
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)
Testing is a stimulating factor (Score:2)
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)
"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.
Re: (Score:2)
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.
Re:Then you are lazy. (Score:5, Funny)
or another title+table+paragraph in Word?
Yer documentin' it wrong.
You can't, so don't try (Score:5, 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.
Cultivate a bit of self discipline (Score:3, Informative)
It is part of your job (Score:2)
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
Thank you. (Score:2)
This Ask Slashdot was very informative. I'm serious. I liked this one. It's a good question.
Soulskill +1 : Relevant ; +1 : Motivational
Answer: don't. (Score:2)
Sure about that? (Score:2)
"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
how to make non-automated testing simulating? (Score:4, Insightful)
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.
Think of it as writing examples (Score:3, Funny)
"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.
So in other word.. (Score:2)
You come off and leave and let someone else raise the child..
Seriously, someone who cannot test his own code cannot write good code.
You can't... work smarter (Score:3, Insightful)
It's inherently boring....
SO, Build hooks into the 'ware as you write it, and automate the testing.
Work smart, not hard.
Red
attach electric wire controlled by Junit to.. (Score:2)
Testing is a mindset more than anything else (Score:3, Insightful)
A totally different challenge (Score:2)
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
Do what I do (Score:3, Funny)
Read Slashdot instead.
Examine your motivations, automate what you can (Score:2)
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
Test to the specifications (Score:2)
Test Techs & Engineers Rejoice At Your Lazines (Score:2)
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).
Dumb question, dumb answer. (Score:2)
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.
Re: (Score:2)
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
Get Creative (Score:2)
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
Gain a split personality... (Score:2)
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
Aside from unit testing... (Score:2)
Just think ahead (Score:2)
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 (Score:2)
Adderal or Ritalin...
Or, you could turn testing into a drinking game!
Realize the value in it (Score:2)
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
Don't test your own code (Score:2)
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.
Re:You can't? (Score:5, Funny)
Wear a different hat each day.
Re:You can't? (Score:5, Funny)
Wear a different hat each day.
I put on my robe and wizard hat.
Re: (Score:2)
It's the exponential that increases fast, exp(10) = 22026.4
Re:Go work for a porn website (Score:5, Funny)
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: (Score:3, Funny)
Then you have hookers killing themselves from boredom.
Although... trying to explain away the dead hookers would make debugging a lot more interesting.