I was in a discussion with some other test architects at work today. We were talking about challenges in testing, and at one point in our discussion someone mentioned his frustration in finding bugs in the basic functionality of an application or interface.
Many, many years ago, I thought it was cool to find basic functionality bugs – “hey – when I select this menu item, nothing happens” or “when I call this function with nominal parameters, it crashes”. I remember thinking, I’m so glad I tested this so I could find this bug. That minimalistic euphoria lasted about 36 seconds (give or take a few years) before I realized that finding bugs in “the happy path” was a big fat waste of my time. I
hate despise receiving code to test that doesn’t work in basic scenarios. If all of the basics don’t work when I get the code, the developer should probably be fired – but at the very least embarrassed if not suicidal over handing code to test that does not work for the most common scenarios.
I know many great developers who are embarrassed when a tester finds any bug in their code – even convoluted “a customer would never do this” bugs. These developers write great code – plain and simple. On the other hand, there are a ton of developers who blindly throw code “over the wall” to testers. Testers spend several seconds testing the freshly caught code, then have to throw it back when they are blocked because basic functionality doesn’t work.
Here’s a message for these developers who happily deliver bad code to testers: I think you should consider doing something else for a living. You have no business making software. If you don’t see the idiocy in creating software with this mindset you are probably too stupid to get another job, so you may want to consider moving back in with your parents and getting a paper route (apologies to intelligent paper delivery people everywhere).
Sheesh – the happy path should always pass.