Testers, don’t be afraid to make Production Changes
Scenario: You are 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!