A Year of Startup QA

This year marked the first full year of QA at the startup I work at, working as the first QA hire on an existing engineering team. There were a lot of challenges, but I wanted to share some of my take aways and challenges that were overcome.

Starting from Scratch

There was not a system in place for me to plug into when I arrived, testing was happening, deploys were happening, and code reviews were happening all somewhat organically and maybe haphazardly.

I had what amounted to a clean slate and worked to build up some systems from there.

My first step was to learn the product. The most important thing i’ve done since I started last year was to become a product expert. Knowing our product intimately continues to be one of the best values I bring to the table and allows me to be more targeted and succinct in testing.

As the product grew I also began to maintain documents outlining a lot of the more esoteric behavior, outside of repo ReadMes. This has saved my hair more than a few times.

My second step was to integrate myself into the Dev team workflow. Finding out where QA lives in the release lifecycle is important and defines a lot of the actual QA work that gets done. In our semi-agile team framework QA became the last step on the Kanban board. I like to think of that part of the board as ‘active development part II‘. In an ideal state i’m working hand in hand with the devs assigning and closing out bug tickets until we have a stable feature.

The third step was deciding on tools. We use Asana as our management software, ticketing system, and QA tracker. I’ve enjoyed using it as I’ve reinvented the QA ticket process several times because it affords a lot of flexibility in the organizational structure of your tasks (tickets).

I use Google Apps for spreadsheets, where I document feature behavior, or maintain checklists that are shared with third parties.

And I use CasperJS to automate a lot smoke testing that would otherwise eat a huge amount of my time.

I’m still searching for a good lightweight tool to organize functional test cases, an essential part of reducing the bus-factor of the QA team (1).

Wrap-Up

If I had to describe my year in one word it would be: Iterative

I haven’t built the best QA system, nor the best processes, but in the last year they’ve grown to better match the challenges we have everyday. The next year will be even (iteratively) better.