Software Testing Humor and Jokes that Brighten Your Day

I love testing…and I love humor too

For those who don’t know me, I’m a professional tester and I do software testing seriously and sustainable. While I’m very into serious software testing stuffs, I always try to keep a good sense of humor to make software testing more amusing.

“Laughter is the only medicine, without side effects.” ― Shannon L. Alder

2 years ago, I started a LinkedIn discussion about Humors in Software testing in Quality and Software Testing group, a group of experts and amazing testers where serious software testing related topics brought up and discussed.

And you know what? There were around 100 comments with interesting humor and jokes shared.
Until recently, there’s a similar discussion about humor in software testing received the same interest from testers community.

These humors and jokes are so interesting that I would like to share with you in this post. Hope you enjoy them and make you do better testing.
Special thanks to commenters who contributed those humors and allowed me to re-post their comments. Thanks again, you guys awesome.

No, it’s not a bug…

I had a developer that always used to say, with a twinkle in his eye, no that’s a feature! – Joe Green

I always love when developers close a bug with status “As Developed” – Todd Lemmonds

My favorite response to “it’s working as designed” is “broken by design is still broken” – Derek Bergin

In my recent project, every time I found a bug, Developer used to say, No user will use that feature so we don’t care about that bug 🙂 – Suresh Parimi

In one of the projects, to one of the bugs filed by me, the developer said that its not a bug but it’s a new feature, which he later on agreed to as bug – Yumnam Piyai

“It’s not a bug, it’s a forthcoming feature” – Anon
“It’s only a one line code change” about 5 minutes before the PM demanded to know who broke the build. – Programmer, name withheld to protect the guilty.
“Ah, of course it won’t work. Sun spot activity is far too high at the moment” – Anon
– John Wilson

It’s not a bug, it’s an undocumented feature! – Lana Decker, CSM

It works on my system! – Dinesh RAMKRISHNA

I was discussing an error with my team lead, who was not able to follow everything I was saying.
The response (accompanied by a snarky smile) was, “All I can tell you is that it’s working as coded.” – Angela Marckel

BA: “It’s working as designed, will update the requirements accordingly.” – Erwin Maniwang

Funny stories between Testers and Developers

In our testing group, we have a list of reasons provided by Dev on why something doesn’t work in our test environment :
Oldies but goodies:
1. Works for me
2. As designed
3. The “end user” would NEVER do that.

Latest and greatest :
1. ” You need to think outside the box…”
2. It works the same in production
3. …has bigger fish to fry…
4. It’s a waste of our testing time
5. Test is test
6. Test is fluid
7. You can find out for yourself
8. That’s not a bug, that’s a “nice” to have
9. Your computer is too slow
10. You’re typing too fast
11. Don’t allow end users to press the “enter” key
12. Change the change request
13. It works in production.
Historical :
1. You need a new keyboard
2. You shouldn’t test using wifi
3. You are not typing Ctrl + ‘c’ correctly
– Tammy Baxter

There are times when the reason for a bug is hard to diagnose and sometimes spirited discussions will break out. Sometimes participants will be unable to even consider the possibility that they or their area had anything to do with it. In which case I have a set of reasons/excuses written up on Post-it notes which I pick at random and hold up like a flag:

USER ERROR
MS REPORTING SERVICES BUG
MUST BE A SOURCE DATA ISSUE
CORONAL MASS EJECTION
RUSSIAN HACKERS
COULD BE THE ASH CLOUD
DID NOT GET THE MEMO
DID YOU TRY REBOOTING
– Chip Collins

BA or Developer: “Works as designed”.
Tester: “So what you are saying is that it was designed not to work?” – Moshe Roseshter

Many years ago I had a developer walk over the day before I was due to begin testing a project and tell me he had used my test cases to check his code was working OK. Back in those days I was kinda thinking this was going to make for a pretty easy ride to completion (I was new to testing at this point in time). Four test cases in, 3 critical issues. Testing stopped. Kinda sad, but did make me laugh in a sort of WTF way. Never really did get a good understanding how it went from “easy ride” to “Oh dear!” – Paul Seaman

In one of our earlier projects, same thing happened, we use to call our developer PCs as haunted with ghost power as everything work in their PCs in a non-producible way as compared to our test environment 🙂 – Sankara Narayanan

This is not a developer response, but rather a real life experience in Test.

In the early days of the digital revolution, I worked for a company that integrated the digital video from a video disk player with a computer. We created an application that controlled the disk player and combined the video and computer generated signals onto a single monitor – allowing for a more seamless experience of reading text, seeing video, and having computer text overlay the video images.

Standards did not exist across video disk manufacturers, which meant that we needed to create custom drivers for each disk player and video card combination. We needed a way to test them outside of the application that used the drivers (as the application was also under development).

We requested that a developer creates a test harness for us, but were told that would take weeks and cost a small fortune.

Fortunately, we discovered, by accident at lunch one day, a few amateur virtual pilots noticed that Microsoft Flight Simulator failed to run a specific view on a given machine and video card combination. After lunch, they noticed that our drivers and application also failed to work on that same machine.

Further investigation indicated that our software failed on the same combinations as Microsoft’s Flight Simulator.

This gave us a tool that addressed several of our requirements for our test harness. While this didn’t solve the problem of exhaustive testing, it provided us with a quick, inexpensive, and easily available tool to identify failing combinations of machines and video cards.

As a bonus, some of us learned to fly a plane (a virtual one at least) during our lunch breaks. – Bruce Katz

In one of my first testing projects I was testing a full-text search feature in a windows app. One of the capabilities was the ability to search for X near Y, where near could be up to 50K words apart. My test case for this was to repeat the same two words 25K times to get the correct distance. This caused the compression algorithm to implode.

The developer referred to this as “an extraordinarily pathological test case.” – Pete Schneider

One time I had a developer tell me that there were no bugs in his new code and that he would buy me lunch if I found any. I think I found 5 in the first few minutes… – Sue Edward

“I don’t believe it” was a common response from one of our developers when looking at our defects. Even with log data, we had to reproduce the defect in front of his eyes for him to believe it. Once he saw the defect reproduced, he would always walk away grumbling something we could never decipher – George Perkins

A tester came to me saying: “Niels, we got this stuff to test, but we have no requirements. How can we test this?” A developer overhearing the conversation said: “Just test what we gave to you!”
I suggested (as a coach I always ‘suggest’): “No requirements: nothing to develop, nothing to test. Then there is only one defect: they made software that is not required.”
The tester liked the concept. The developer didn’t agree.
– Niels Malotaux

We started using the requirement for testing: “No questions, no issues”. If a tester has one question, or finds only one issue, the test is aborted as failed. After all, when the user starts using the software, we’re not there to hold hands, are we?
The testers liked the idea. The developers initially said: “That’s impossible!”, but I insisted: “It’s a simple requirement: ‘no questions – no issues. Period!’ Easy to measure, and I’m sure you’re clever enough to accomplish it.”

One development team managed to succeed immediately (perhaps accidentally).

Others took a bit longer: rather than coding some software and asking testers to check it out, they now started designing, reviewing the design, then implementing and reviewing the implementation. After a few cycles, the testers found no questions, and no issues.
Conclusion: developers know how to do things properly and they can deliver Zero Defects. It’s only difficult to keep the discipline, especially if nobody clearly sets the requirement: from now on no questions – no issues. Mantras work.
– Niels Malotaux

I had a developer while I was telling him there is a serious defect in his code (as we already registered) he was always saying the following : “man, you have just made that me&my family has something to eat – again! God bless you” 🙂 but he was a totally freaked out 😛 – Sylwester Ronda-Tchórz

I had a developer once tell me that “software does not break”. He was serious – Igor Mendeleyev

Technically testing should be kept separate from the development team I.e., it should be independent with some autonomy, and still be part of the overall development process. However, in one of my previous companies I was directly reporting to the development manager and got told off for finding too many bugs. His exact words were “I want you to test only this much and not go too deep”. It was hilarious. – Yadvinder Chauhan

I asked my developer if he’s an exception. When he asked why, I told him because I can’t handle him so I want to throw him. lol :)) Sounds mean but we laughed it off and he’s a dear friend of mine 😀 – Paola Gia Aquino

After I reported a “very bad” bug, the developer came to find me and gave me a very helpful tutorial about why the scenario I described could never be allowed to happen because it would be “very bad” if it did. Therefore it can’t happen. Tester educated, problem solved. Please close the bug. – Ralph Case

I always hear “as designed” and the bug is closed. As a tester, you are ‘required’, as part of the job, to be part psychic and be able to see what people don’t tell you. – Nancy Grande

“what did you do to put the system in this condition???”
QA ” Nothing…I was not working with it”….
Dev “ok…what did you do before you did nothing??” – Nuno Rocha Esteves, Eng, PMP

Image courtesy of Mister GC at FreeDigitalPhotos.net

We had a dev who was pretty laid back and didn’t care much about pesky things like requirements, so he developed code with no documentation opened or in mind. So one summer Sunday evening the whole team had to stay up until 2 am to meet a sign-off deadline, and his code was the last to be bugging out on us, and me being the QA team lead I hear the person responsible of testing his code going ballistic, so I call the dev over. He waltzes into the room, and says my QA team member is imagining things, so I open the document and show him where the req for that is clearly stated. Then I proceed to explain to him that we have 2 types of documents, one explaining the build criteria and one the specific transformations that should occur (which is standard for this particular client, always has been, and is the first thing we teach at trainings). The guy looks at me and says: “That’s your interpretation”. .. – Yana Nancheva

I remember a developer calling me saying “You cannot enter bugs on my code, I have reached the maximum limit of bugs that I can attend to, if you enter one more I will lose my job…”
Never took that seriously, but if he was serious, then I’m happy I am not working at that place anymore 🙂 – Marie-Claude Belanger

Long ago when I worked for the MI Support Desk (don’t chastise me) I had an interesting response to a patch.

I sent the customer the latest patch to “resolve their problem” and told them to unzip it at the

Program Files etc. etc. I said it that way as I had people go on about not having Program Files installed on their C drive

Yep you guessed it, I got a response stating that they couldn’t find the YOURDRIVE folder, but in their defense I did get a second email 10 mins later saying

“I’m being stupid aren’t I?” – Sean Wilkinson

I’ve had, “No one is going to do that, that’s a tester bug.” After release, the bug is occurring for consumers. ^.^ – Carlos De La Torre Jr

I named my sitting area as tester’s zone and all bugs are a cause of zone effect according to me… 😀

REASON: Most the issues detected here are never replicating while developers test it before submitting and most of the steps to replicate are “so called forcefully bringing out the issue and users never use that way” !!
Build sent and same issues come from client’s end.. Believe me then it’s so easy to replicate
– Dipshikha Bhattacharjee

Often heard from developers. All users are smart , no one is going to input these types of values… – Anil Rana

One of developer in my company writes this error messages throughout the application “Operation has been failed successfully” – Usman Butt

Alright, let’s take a break…It’s long enough for the post today.

Like What You’ve Read?

Subscribe now to be updated on humor and jokes in future posts!

Email Address

Related: Software testing humor and jokes that brighten your day – Part 2