Pay Back Bad Developers

Here we are, in the thick of the holiday season when we give gifts to the important people in our lives. When doing your Christmas shopping, you should be careful not to overlook the founders of the feast - the Bad Developers.

I say this not because developers write the code that gets sold to your users, thus paying the bills. I say this because without Bad Developers, and the wonderful bugs they tuck away in the product like lumps of coal in a stocking, there would be no need for testers.

That is why I recommend that testers buy a gift for the worst Developers on the team. I say the worst, because it is these venerable engineers that make necessary most of the testing we do. You don't need to reward the good developers - if they are not going to send some wonderful bugs your way, you don't need to get them a thing. So Karen, Jeff, Dominick, and Alex - no gifts for you because you make me work too hard to find those precious few bugs.

But what is the best gift to show how much you appreciate the Bad Developers and their lack of best practices, unit testing, common sense, and skill than a fruit-cake. Nothing says "Thanks for the lousy code! Keep up the bad work!" like a cake made of fruit. This classic no-prize is just what every Bad Developer needs and wants.

Sharpen the Flaw

The Seven Habits of Highly Effective Testers
Part 7 of 7

This is finally the seventh post in a series many thought would never be finished. It is based ever-so loosely on Stephen R. Covey's book but focused on what you can do to be more effective as a software tester.

Like college freshmen, bugs rarely live alone. A group of bugs living together is called a pod, or maybe that is dolphins. Swarm? Colony? The best name would have to be the same as crows - a murder of bugs. Yes, I realize I am getting off track. Sorry.

The point is, when you find one bug, you can be sure that there are other bugs nearby. As a tester, you should exploit this by banging on the features in which you find the bug. Like pulling on a loose thread, testing heavily around a new bug can lead to the whole program unravelling.

You should also test similar functions in other features. Developers are at least as lazy as normal people, so when they can reuse a bit of nifty code, they will, and thus make another instance of the bug. The right way for developers to do this is to abstract the function and then call it from everywhere that needs it, but as we know, the right way to do things is not always the way things are done. And thank goodness for that.

Previous Posts:
1 - Be Protractive
2 - Begin With the Vend in Mind
3 - Put Worst Things First
4 - Think When/When
5- Seek First to Understand, Then to Exploit
6 - Sinner Guise

Sinner Guise

The Seven Habits of Highly Effective Testers
Part 6 of 7

This is the sixth post in a recently neglected series which is based ever-so loosely on Stephen R. Covey's book but focused on what you can do to be more effective as a software tester.

If Moses was alive today he would be a technical writer. Just like the ten commandments, the purpose of software documentation is to tell people what they should do and should not do. Also like the ten commandments, much software documentation is ignored.

Software is designed to be used in a certain way. Careful use cases and flows are thought out and implemented by designers and developers. Testers test these happy flows and make sure everything works the way it should. All is well until a user gets the software and tries to do something with it that no one ever imagined. What happens next is crucial.

A sign of quality software is that it either handles the abuse, or at worst, fails gracefully. It is our job as testers to make sure that this happens. To do this, part of your testing should include ignoring everything you know about what a user Shalt Do or Shalt Not Do, and go crazy:

• Put negative numbers into text fields
• Put ridiculously long strings anywhere you can,
• Paste inappropriate stuff - like binary files into text boxes
• Open 13 instances of your app at once
• Unplug the network or the power in the middle of an important flow
• Change the system date and time
• Install on a system way below the minimum specs
• Use weird characters like ì È Ö
• Run 10 other apps while you are testing
• Delete crucial files
• Don't close other applications before proceeding

In other words - be great and terrible in the way you treat the software. Put on the guise of a sinner and break all the commandments. The developers may not forgive you for doing this, but your users won't forgive if you don't.

Previous Posts:
1 - Be Protractive
2 - Begin With the Vend in Mind
3 - Put Worst Things First
4 - Think When/When
5- Seek First to Understand, Then to Exploit

Next Up:
7- Sharpen the Flaw