Join my Webinar on Participating in Code Reviews as Tester

Last year I wrote an article for Stickyminds about Participating in Code Reviews as a Tester where I made the case for Code Reviews being more than just a chance to catch bugs. They also serve as a chance to see how something is built and have a conversation about it.

We, as Testers, question software differently from developers so it’s important that we participate in this knowledge-sharing practice and now I’m going to try to show everyone how!

I’ve partnered with TestCraft for a webinar on May 21, 2019 at 9am PST.

I will demonstrate a live Code Review (or two) and show everyone it’s not about knowing how to code, it’s about asking questions and learning about the changes.

Expect to Learn:

  • The basic git workflow, where the creation of a Pull Request leads to Code Reviews
  • What to look for when you are Code Reviewing from a tester’s perspective
  • A practical way to get started doing your Code Reviews on your own
    The webinar will end with a Q&A.

[button url=”” color=”blue” size=”medium” type=”square” target=”_blank”] Sign Up Here! [/button]

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!

Tinkerer, Testerer

There’s something fun about web development. Something fun with trying to build a website from the ground up or tinkering with a template with it until it fits my needs (like this site), building a Jekyll site from the ground up to display a list of software testing conferences or even a Rails app (I want to build more of these as well).

For the last few months I’ve been tinkering with ways to improve’s overall design, improve readability and also move to something more modern and minimalist. Then I found a new template from my favorite WP designer ThemeBeans. You can see the difference:

Previous Blog Layout & Home page:

New Blog Layout:

New Home page:

Although these screen shots don’t do the themes justice they do show a very different approach that includes a lot more negative space, less use of black (which always bothered me) and a more minimalistic look. For once I took the opportunity to customize my child theme in a few ways:

  • Set a specific color theme
  • Moved the search button
  • Separated the list of blog posts by year

Over time I expect more customizations like updates to the footer, more pages and maybe an AMA option?

I’m always tinkering and testing new customizations. Software Testing Conferences just got an update that includes:

  • Event videos link for past conferences
  • A status for current conferences (Calls for Proposals and Registration open / closed information)