Making Developers Cry Since 1995

Michael Hunter's blog byline is unapologetically over-the-top: making developers cry since 1995.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/09/making-developers-cry-since-1995.html

I can definitely attest to the fact that, as a professional developer, I hate testing. Debugging, fixing, no problem. Testing, ugh. I just find it so darn tedious. Though I have to admit, I have only begun to play with some of the sophisticated test suites available now. Maybe those really do help alleviate some tedium. But I also worry that they will just result in a false sense of security.

Oh, and also…

Holy buckets. That terrifying photo will surely haunt my nightmares for the rest of my days.

Thank you.

I’m all over TDD; unit tests rock. But the kind of testing you’re talking about? I’m awful at it. I get bored filling out the same UI, so I just plug in the same values I used the last 20 times. (=

Bane of my existence : Testing.
I cried when I saw that list. But, I have to admit… its true v: It does help - but does NOT mean that I have to like it…

I’m with Jerry. I have never (repeat, never) worked with an excellent tester. Plenty of average ones, lots of below average ones, and a few good ones. (The same can be said for developers, now I think of it.)
That’s in 10 years of professional development and about a dozen organisations, from blue chip to small software houses. Have I been unlucky? I doubt it.

I agree that developers don’t make excellent testers (that’s what users are for :wink: but I’m darn sure that I test a lot of stuff that most testers wouldn’t.

Good testers are very hard to find. I think that a lot of it is to do with there being no solid route into testing. No-one says ‘I want to be a software tester when I grow up’ (at least not that I’ve met). All the testers I’ve ever worked with have sort of fallen into the job after not having a clear career path. This makes for bored employees (hey, they’re testing!) and low level of interest in their work. Hence, poor testing and a high turnover of staff.

Nor does there seem to be an agreed approach or methodology to testing (again, not that I’ve seen, I’m sure they exist) so each tester or group of testers just do their own thing.

Maybe Microsoft (or other) needs to come up with an industry standard certification for testers?

Thanks for the great link. I think it is great that Michael is working on the Expression suite. The beta of Expression Web Designer is awesome, and there’s something more than testing in the mix.

So I just added three RSS feeds: Michael’s MSDN blog, his DDJ blog, and HMK’s Spurious Thoughts, stumbled over in passing. I need this. I do. It is good for me.

I would definitely want Michael and kindred spirits testing any product of mine.

The best software testers are woman :-)Their actions are unexpectable. uh… uh… painful!

Absolutely dead on.

I’ve only known a couple of really good testers in my life; the best had been a field engineer, so he knew what developers are capable of doing to users. We had a good relationship because I’d also done field work and knew how important testing was - we joked all the time that my job was to develop new code and his job was to make my life hell.

I’m a tester/verifier. Thanks for the photo, Jeff. Though, I’m sure sure I understand its underlying implications.

TESTER PRIDE!!! XD

At the big M, testers are hired at the same pay level as developers, and have the same potential career growth. As a result of this, MS has hundreds, if not thousands of testers with skills similar to Michael. It’s a good place to be a tester, and our developers really don’t cry that much.

I’m a software tester/QA and occasional developer at the same job. I do care more for coding than testing, but testing is my primary responsibility. So even though I’m a developer at heart, I take a great deal of pride in seeing software go out and work right the first time dur to my efforts.

It’s been mentioned before, but I get paid a fraction of what the full devs get–maybe half. It’s not a good motivator.

Pay peanuts. Get monkeys. The old adage applies.

It’s different where I work. Testers are paid at the same level as developers, and all of the test scripters also program in C++, some flavor of VB or a .net language. We’ve also found something interesting. The very best manual testers are also scripters, not the domain experts.

We program our scripts from scratch (no recording), so we’re forced to think logically about the software and our workflow.

It’s unfortunately true that bean counters try and cut testing first. Fortunately, those companies tend to be self-solving problems. Unfortunately, bean counters aren’t accountable and can get a new job more easily than the development and testing staff, which is perceived as the source of the failure. They are not, usually, in my experience. The root causes of software failure are almost always rooted in irrational behavior of an uninformed and lazy management.

I’m lucky to work where I work now, but I know many other poor souls out there testing some sort of CRM app for a WWW company (Widgets to Wankers on the Web), who hire uneducated people onshore or offshore, treat them as throwaways, and wonder why they’re having trouble.

You mentioned that “Even a mediocre tester will make your application better…”

Perhaps, but my experience has been that there are many, many sub-mediocre testers. Deficient tests and test cases actually increase the development workload with minimal associated increase in quality.

So, in disfunctional organizations, testing may actually have a negative effect on product development.

The relationship should not be adversarial, however, I think testers need to stand up for their rights, too. They don’t get enough respect, either in salary or the project plan.* Testers should push a little!

  • Evidently unless you’re a tester at Microsoft, which is certainly a good sign.

Hey Jeff, let me test your app? Pppppplease?

Ralph and Jeff are dead-on that the tester-dev relationship should not be adversarial, and I go to great lengths to prove to my devs that I am their friend, not their enemy. If they cry anyway, well, that’s because they still check in bugs for me to find. g/

Hi,
when looking at the list above, especially the Printing and setup options sound like bad use case planning to me.

I took a stab at beta testing a few months ago - and one of my most important conclusion was that good test cases can kill most really obvious bugs:
http://tamspalm.tamoggemon.com/2006/01/20/the-art-of-beta-testing-part-5/

In addition, eating your own dog food and code reviews should be ok for any one man micro ISV.

Best regards
Tam Hanna

This whole “you’re not done yet” attitude suggests that some of these tests are testing implicit or unstated requirements.

If the developers had this list of requirements up front, there would be no excuse to cry about the tests later. And there would be nobody asking “are we done now?”

As someone in development I remember meeting a interaction designer whose first words to me were: “I’m going to make you cry.” I replied - “Okay, I can do that if that is what you want.” I don’t understand why QA and Development allow themselves to be set up as advisories. I think that more can be accomplished when both sides have a common shared goal of shipping the correct features with high quality.

the trouble is… nobody likes someone saying their app is shit. even when it is.

The relationship should not be adversarial, but friendly competition is how I think of it. My goal is to check in software that you can’t break. You goal is to break it. Who wins? Obviously my job is harder, but the better I do my job, the harder I make your job. The more we compete with each other, the more the customer wins.

If I do a poor job, my QA should come in with a laundry list and just kick my butt. If I’m a developer worth my salt, I’ll either fight the bogus claims or hang my head in shame for sucking so bad.

My company has been bought by bigger companies, but back in the day when we had what I consider a proper developer-QA relationship we used to have the slogan, “It’s not cool till QA says it’s cool.”

Don’t get me wrong. We loved our QA. Still do. I don’t know a single member from the original crew that wouldn’t kill to get one of our original awesome testers. Yeah… you get rework, but rework is much better on the ego than bug reports from the field.

g