Chase Seibert

Director of Engineering at Dropbox

We all tend to tie our self-esteem strongly to the quality of the product we produce - not the quantity of the product, but the quality. [Lister, DeMarco: "Peopleware"]

For the last two weeks (equal to one sprint), I have been working in a QA role. Ever since laying off some QA people several sprints ago, we have been falling behind in our work. This time, it was decided that it was worth it to have one developer essentially be a QA person. Me.

Now, I have never done QA per say. I have tested my own code. I even answered support phones years ago. But never having played this explicit role before, I wasn't quite sure what to expect. Going into it, my definition of what a QA person does would have been:

  • Think about how the product is supposed to work, and document as many cases as possible.
  • Think about how the product could break, and document as many cases as possible.
  • Run through all your cases to see which if it's working the way it should, and not breaking in the ways you can think of.
  • Communicate with the developer(s).

Before this, if I had to break it down, I would have said that QA people spend 10% of their time writing test cases, and 90% executing the test cases.

Having done QA for just a week, it's clear to me that at least where I work, QA people spend 10% of their time coming up with test cases, 10% running test cases and 40% talking to developers and product owners. The other 50% is lost doing mundane tasks like building and deploying, and getting sniped to work on unrelated stuff.

For the first three days, I did nothing but come up with test cases and talk to other people about possible test cases. Lots of looking at the existing code to figure out possible ways to break it. Lots of conference calls.

After that, every day pretty much looked like the following:

  • 9 AM - Download latest code, build, deploy
  • 9:15 AM - Get the deploy actually working, usually involving new config, sometimes involving talking to developers.
  • 10 AM - Run the test cases.
  • 11 AM - Talk to developers about what is broken, what new test cases then have run into, what acceptance criteria they think will have to change.
  • 1 PM - Document new test cases
  • 2 PM - Talk to product owner about changes to acceptance criteria.
  • 3 PM - Work on unrelated stuff.

Percentage of my day running test cases: 12%, max.

On the other hand, I was still playing a vital role in the feature. There is no question that without all the conversation around change management, we never would have delivered it on time. I guess what I learned is that a QA person spends a lot of their time making life easier for the developers. And, a lot of that doesn't directly relate to catching bugs.