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:
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:
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.