5 Things You Hate About Testing

I was reading a blog post A Short List Of Things I Dont Like About Python ( a language I keep meaning to try out sometime ) in which the author says

"In my case, I’ve long maintained that if you can not name things you would change, irk you or generally dislike about something (not just a language) you supposedly love, whether it be a tool, a language, an OS, etc - then it shows you have a certain lack of self-awareness or pragmatism"

I've read plenty of blogs and posts about why people love testing so I thought I'd try the reverse and see what people would come up with and if there are any common ones.
Doesn't have to be 5 - top 3 or top 1 is OK

I'll kick things off with a couple:

1) Finding the same silly bugs year after year whatever program you are testing - leaving an input box blank, finding that 99999999999 overflows. Yawn

2) People asking for the program to be QA'd when they mean tested

▶ Reply to This

Replies to This Discussion

Permalink Reply by Fatima on May 27, 2009 at 11:09am: 3) Calling testers as QA (Quality Assurance), QA is process but not a designation title.; ▶ Reply to This

Permalink Reply by Bao Tram on June 5, 2009 at 12:00pm: I totally agree with this, I'm trying to get my team name change from QA Team to Test Team, but my boss refuse to let me change it.; ▶ Reply to This

Permalink Reply by Glenn Halstead on May 27, 2009 at 11:26am: 1) Not having time to satisfactorily (for me) determine the root cause of unexpected behaviour (test fails).

2) Crappy, unreliable test environments where most of my time and effort is expended identifying environment issues rather than product issues.

3) The same problem recurring again and again.

4) People who just follow the process by wrote without using their brain.

5) Wasted effort.; ▶ Reply to This

Permalink Reply by Rosie Sherry on May 27, 2009 at 11:29am: Poor test releases where blocking bugs are found within minutes meaning testing needs to stop.; ▶ Reply to This

Permalink Reply by Glenn Halstead on May 27, 2009 at 11:31am: We have this fault in our environment. It occurs EVERY time the environment is updated. The environment team smoke the test the environment. We run our regression tests, find this fault, raise a Trouble Ticket. The Env team fix the problem and we retest. Rinse and Repeat. EVERY TIME Grrrrrr!!!; ▶ Reply to This

Permalink Reply by Jason B. Barile on May 27, 2009 at 12:37pm: 1. UI Automation
2. See #1
3. Code that isn't architected in a testable manner, causing testers to have to write integration tests when simple unit tests could find the same bugs.
4. Testers who get comfortable with what they already know and stop pushing themselves to learn more
5. What Rosie said... code that gets "thrown over the fence" to the test org with bugs so bad that a simple 5 second sanity test could have caught a blocking issue.; ▶ Reply to This

Permalink Reply by Rob Lambert on May 27, 2009 at 12:44pm: Nice topic. Here goes:

1. Developers believing they know HOW to test, WHEN to test and WHAT to test. (Note: Not aimed at ALL devs. Just some of them.) (Note: If they do know testing - then why do I find so many bugs?)

2. None testers belief that automation is not only a silver bullet, but a really cheap one at that.

3. Having to retest an entire area of the app after finding a really obvious and pointless defect. (i.e. I wish people would smoke test their code and fixes before dropping to test)

4. Poorly interpreted or mis communicated requirements and designs which result in a system that is not only unstable but is also not future proof

5. The almost unbelievable emphasis and trust placed in metrics and their value by testers and non testers (especially when used a gauge a testers competence and project completion)

That's my five, but here's another one I just thought of that gets my goat too.

6. Best Practices and certain industry beliefs that they actually exist and should be followed by the letter.

Rob..; ▶ Reply to This

Permalink Reply by Andy Smith on May 27, 2009 at 12:51pm: 1. Unproductive test-tool shelfware, which was historically over-purchased and still swallows a recurring chunk of budget despite my protestations.

2. Inaccurate test prep, so you have a script where the objective is so test a specific condition yet the tester hasn't properly researched the way the system works and the script is effectively pointless. (The number of times I've had to splutter my way through a grilling by the project board and stuck-up for testers who evidently weren't thorough enough! Aaarrggh!)

3. My corresponding lead developer!!!; ▶ Reply to This

Permalink Reply by Joel Montvelisky on May 27, 2009 at 3:00pm: 1) The fact that no matter how methodically and consciously you plan & test, once in a while a trivial (and catastrophic) bug will escape that was literally 1 click away of at least 5 of the scenarios you ran before the release.

2) Many of our colleagues that see testing as a stepping stone to their "real-job" within the company.

3) Project managers, developers and non-testers in general who don't understand why you can't "just run a quick pass, so that we can release on time."

4) The lack of standard education around the field.

and

5) (Echoing a couple of people already) The misunderstanding around automation, and thinking it is your magical cure to all dev problems.

(there are more, but I guess these are my representative 5...)

Great topic Phil!; ▶ Reply to This

Permalink Reply by phil kirkham on May 27, 2009 at 3:50pm: you're welcome

The follow-up ( and partly the point of the post ) is how to go about changing the things on your list so they are not such a source of pain...; ▶ Reply to This