Let Testers Do Terrible Things to Your Code

January 7, 2016

Jeff Atwood (you may know him as one of the founders of Stack Exchange) writes about how he learned to test his code:

"I believe a key turning point in every professional programmer's working life is when you realize you are your own worst enemy, and the only way to mitigate that threat is to embrace it. Act like your own worst enemy. Break your UI. Break your code. Do terrible things to your software."

Unknown unknowns get even good programmers

He goes on to list (and link to) all the assumptions that software developers have about time, geography, names, addresses, and gender. When you're building a software product, it's possible to catch many, if not most of these misconceptions, but it's never possible to find everything. After all, if you didn't know about these problem areas, there are others that aren't on your radar.

What's a good programmer to do? Atwood says that you have to learn to break your own code, to be your own tester, and try as hard as you can to test beyond the limits of what you think users might do. Going through this challenge of your own creation is crucial for good programming. You're making something you want people to use.

"a good programmer knows they have to do terrible things to their code. Do it because if you don't, I guarantee you other people will, and when they do, they will either walk away or create a support ticket. I'm not sure which is worse."

An avoidable situation

This isn't even the worst part about having bugs in your software. The real tragedy is that the situation is entirely avoidable. Developers aren't great testers, they're too close to their code and have too much knowledge about how it's intended to work. They're the prototypical white box testers. Great programmers let someone else test their code.

The first step to writing better software and becoming a better programmer is to do terrible things to your code. The next step is to find good testers who will go through and check it for all the things you couldn't have possibly imagined.

Read More

January 17, 2020
QA Squads: a new offering from test IO, amplified by EPAM

Going beyond software  Customers come to test IO for many different reasons. Sometimes, an internal product or QA team needs a force multiplier for real-world testing – to extend the existing QA team’s processes and activities beyond their internal team. Other times, it’s crisis mode – perhaps QA leadership has left the company, or there is a critical product release upcoming that […]

November 25, 2019
iOS testing: TestFlight or Resigner

Here's our guide to which method you should use you to distribute your IOS app to the crowd.

November 15, 2019
Exploratory Testing vs. Test Case Testing

Exploratory testing emphasizes creativity and learning. Test Case testing emphasizes planning and execution. Which one is right for you?

Ship Faster, Sleep Better

Get a Demo