Testing software saved my (professional) life.
A long time ago I was totally stuck professionally. I was a project manager in the IT department of a giant insurance company that had absolutely no clue about freaking anything. I was miserable beyond belief. I wanted out. Out of project management, but most of all, out of corporate IT.
So I started testing software on the side for a friend’s company. I tested in the morning. I tested in the evening. I even tested on my lunch hour. Developer’s would deliver a story, I’d pull the code down locally, break it, and reject their story.
After about a year of this I was offered a full-time job by the company I’d been moonlighting for. I got the offer, wrote the shortest resignation letter ever, and handed it to my boss in the hall. I might have said “I’m outta here” or something like that. I think I also asked for my last two weeks off. That’s how bad I wanted out.
I tested full-time for the next two years and I loved it. All the corporate IT bullcrap was gone. We had less than two hours of meetings a week. We had a lot of freedom choosing what to work on and how to do it. If I thought a feature needed an automated test, I wrote it. If I thought it needed five test sessions, that’s what I did. I was my own man, and I was free. It was awesome.
Throughout this entire time, I’d been learning to program in Ruby in my free time as I built TroopTrack.com. I found I liked that too, and I eventually became competent enough that people started offering me jobs. I turned them down, until one day it became obvious that the startup I worked for was sinking fast. I jumped ship and started writing code for my day job AND my night job.
That was 2011. I think. I’m bad with dates. It’s been a while. I’ve been writing and testing software every day since then. And I’m happy as can be. I have a hard time imagining my life any better than it currently is. Especially since we finished the swimming pool a few weeks ago.
I owe it all to testing software, my gateway drug to a better life.
Gazillions of lines of code later…
My perspective on testing has changed now that I’ve written a lot of software, launching 1 – 2 new products a year. Here are five things I wish I’d understood then that I have only learned because I became a developer.
Writing software is real hard
Do you ever test a feature that fails in a way that is so obvious, so painfully stupid that you can’t help imagining what the heck the Roger was thinking when he committed? Roger is a freaking idiot!
I did. But I didn’t call the devs I worked with idiots, because they are all really brilliant programmers and I knew. But they still made really stupid mistakes sometimes, and I couldn’t help wondering how that happened.
A gazillion lines of code later, I know exactly how it happens. It happens in a million different ways. Here are a few:
- An interruption occurs just as I’ve figured out how to fix a problem. Later when I come back, I confuse understanding the solution with implementing it, and I commit. DOH.
- I code the happy path and test it. I work on the problem paths and get them working to my satisfaction, but break the happy path. I forget to re-test the happy path and I commit. DOH.
- I mistake an edge case for the common case and implement the edge case. I don’t find out that I’ve chosen the path of pain until a tester does a better job of understanding the feature than I did.
These problems have simple solutions, like re-testing, ignoring the phone, and talking to product owners. I get that. It’s also super easy to make these mistakes, and even though I spent several years zeroing in on these mistakes by others, I’m not any better at avoiding them than the other developers I know.
It’s hard to test your own code
TroopTrack was a solo project for most of it’s history. I didn’t have anyone helping me with the programming on a daily basis until last summer when I got my first intern. We only finally hired a tester last week. So, for the past seven years, I’ve been testing my own code day in and day out. I’ve learned one thing from this: It’s really hard to test your own code.
When I test YOUR code, I think about things before I start. I read about the feature. I think about the stuff that has already been built and how they might interact with this feature. I consider YOU and what I know about YOUR programming style and weaknesses. And then I start to attack. I find flaws quickly because I know that YOU tend to focus on the happy path first and ignore the problem cases until the end. Or that you have a tendency to use a limited data set in your development environment. Or whatever. When I attack the code I attack YOU.*
The problem is, when I test MY code, I have already considered all those things. I read about the feature. I thought about the stuff that has already been built. I even thought about the mistakes I tend to make. It’s extremely unlikely that I am going to think of anything new the second time around, and so I don’t find the bugs YOU would find if you tested my code. I generally only find the bugs that are the result of the code not doing what I already coded it to do because I am too biased by my understanding of the solution to see the flaws that are obvious to YOU.**
Untimely testing increases the cost of fixing bugs dramatically
It’s common on some of my projects to be delivered one day and not be tested for 2 – 5 days. This is really frustrating, especially when the story is rejected. It adds an additional 15 – 60 minutes to the time it takes to fix a bug if it has been more than 24 hours since I worked on it. That’s money down the drain. I never understood this as a tester and I resented the way devs got frustrated when I chose other work over testing a recently completed story.
Programmers always feel stupid already
Whenever I hire an intern, I tell them how great programming is. Except for this one little thing – you get to spend the rest of your professional life feeling stupid. The only consolation is that you will feel less stupid than you did a year ago, most of the time.
I have spent hours staring at code, testing various scenarios, and poking sharp implements in my eyeballs because the stupid code was just not doing what I wanted it to do. And then I notice that I did something asinine, like misspelling a variable name. Hours of my life down the drain because i before e except after c.
That’s an extreme example, but less extreme versions of it occur every time I code. For me, programming is a process of reducing a complex thing into a couple of simple things. Figuring out what simple things are needed requires experimentation and failure, and when I finally figure it out I am embarrassed at the crooked, wasteful path I took to get there.
Skilled testers are way more valuable than I ever knew
Most testers can find bugs. Really skilled testers can communicate about the bugs they find in a way that helps me understand a few things:
- How the result of the test varied from their expectations
- Why this variation is important
- What I need to do to see this problem for myself
Or, I guess you could just reject the story and add the very helpful comment “Doesn’t work”. That’s cool too. Because… skills.
Testing Skills Matter
Richard Bradshaw (@FriendlyTester) and I will be teaching a two-day testing skills workshop in Central London in the fall. If you would like to learn more about this, send me an email at firstname.lastname@example.org.
* Is that mean? I don’t feel like it is, but I frequently feel vindictive pleasure when what I know about a dev leads me to a bug quickly.
** Unless enough time passes between coding and final testing for me to forget how I solved the problem. That’s generally 3 – 7 days, which is way to long to leave a pull request hanging.