Testers, don’t be afraid to make Production Changes



You’re testing a new page and there’s a typo. What do you do?

  • File a bug report?
  • Mention it in passing and hope the developer fixes it the next time she remembers?
  • Fix it yourself?

If you’ve got access and aren’t afraid to commit (eventual) production changes, I highly recommend making small fixes yourself. It’s a small but visible way to have an impact on the quality of your software outside of testing and writing bug reports.

A Scary Proposition

I used to be afraid of making small obvious changes. I’ve spent most of my software career testing other people’s code and when first given the chance to make and commit changes, I hesitated. It seemed so counterintuitive. What if I broke something? Who tests my change if I’m the (only) tester?

In hindsight starting small with text or label changes meant dealing with low risk bugs whose solutions are incredibly straight forward. Solution: change the spelling. That also meant my colleagues weren’t ever worried about me making things worse. Worst case is something’s still misspelled.

Learning this perspective helped me get over the initial fear and over time the benefits of me being able to fix small things meant I could reduce potential bug reports and make quick, actionable fixes that were trivial for the programmers to make. They could focus elsewhere on higher value, higher priority work while I catch and fix the small things they missed.

Today I regularly commit small changes around typos, broken links, general CSS weirdness and a few other slightly more complex things. I also add testability hooks into the production site to aid my automation code (which isn’t production bound). I enjoy this small, visible impact.

Start Small

For anyone who wants to try this I suggest starting small with the things that annoy you and that would be easier or less time consuming for you to fix, than someone else. Once you’ve made the fix have someone code review your changes (don’t worry they’ll be very easy to review initially). Over time as you learn the process and become comfortable with it, you’ll be able to tackle more difficult, yet small changes.

It’s important to set boundaries around what changes you’ll make and won’t make. I don’t jump in and mess with things I don’t understand. I also won’t volunteer to make changes being worked on by other programmers to avoid stepping on their toes.

All of this depends on your comfort level, the visibility you have into the code and your desire. If you try it and still don’t feel comfortable, or you don’t have access to your code (and don’t want to get it), then don’t worry. It’s not for everyone. For those that do, sometimes those actionable bugs are compelling enough to just fix them instead of reporting them (or in addition to). Especially if you suspect such a request is likely to be ignored for some time as low priority.

As testers it’s easy to get into this mindset of someone else writes code or fixes the bug, not me. It doesn’t have to always be that way. Sometimes it takes less effort to just fix an issue than it does to report it, wait for someone else to fix it and then test the fix. Making small fixes is really about being a team member and helping to improve quality. Testers, don’t be afraid to make small production changes!

  • matthewheusser

    Thanks Chris.

    One thing I would be leery of: If you make a LOT of bugs fixes, you may find the developers have been enabled to be sloppier. So be careful. As a quick way to get the team out of a jam and demonstrate some technical credibility, though, I think this is a good idea.

    • Agreed. Personally I highly doubt I would make a LOT of bug fixes and still be in a testing role. In general I want to be a collaborative team member, who can help out when necessary. =)

    • Definitely agree. Everyone should feel enabled to make changes, but developers shouldn’t feel like they have a crutch that cleans up their mess. I grew the most as a developer at a small startup where I had to do most things on my own.

    • Matt

      In an Agile team, surely this would be something that would be raised in a retro?
      I do agree it is a way get involved and earn the respect of a developers, but if you are constantly fixing bugs because the devs are getting “sloppy”, find a forum to make it more visible.
      Or if nothing changes, refuse to fix bugs for a sprint or two and watch the fallout or create something public like a “bug wall”?

      The team needs to come together to own quality as a whole, if one person is fixing (and caring about) all the bugs, is that still the case?