I am a fan of teams where roles and people are disconnected. A model where all roles are hats and people can wear any hat that they are capable of wearing. Basically, try getting an m:n relation between roles and people. However, one of the key to this model is, like I said, capability.
I recently attended a few QA conferences in Bangalore. I spoke with other participants about my experiences with “Selenium and Sahi” and I have a blog on test automation. In one of these conversations, someone who came to know my background asked if I am the QA lead on my team. I told the person that I was a developer and don’t do QA primarily. The person was confused as to why I would not call myself a QA, especially since I spent a good chunk of my time writing automated functional tests using Twist and Sahi on the Go team. Surely, I am some sort of a developer tester.
Here’s my take on why I continue to call myself primarily a developer:
Primary Responsibility...
Mark Chang, when he was my delivery manager, used to use this term. It was in the spirit of roles as hats. I have worn L3 Support , UI Dev and QA among other hats on the Go team but I have mainly been responsible for the delivery of software through writing code. My primary responsibility has been that of a developer.
I have spent time learning the practices involved in engineering software. The code I write usually involves dealing with the likes of Spring, Rails, Apache Webserver configuration, Chef Recipes or, say, shell scripts. Just like working with all of these, test automation using some framework is just another kind of code that I write.
QA on Go...
Whenever I wrote a Sahi test on the Go team, it did not mean I came up with the actual test case to ensure the correctness of the system. It just meant that I wrote code using a
framework to test some functionality. Just like how my product manager and business analysts told me what needed to be built for the release, my QAs told me what needed to be built for functional regression.
On Go, we have awesomes QAs on the team. Apart from other kinds of tests, they also do a lot of story testing. They come up with what needs to be automated for functional regression. I do pitch in and give them context on the implementation, but they do the heavy lifting and come up with the test cases.
I have paired with them before and have worn the hat of QA. In that sense, I have done some testing. However, I do not think just by writing test automation, I am testing.
QAs I have loved working with...
Have a crazy skill to figure out where the edge cases lie. Their exploratory testing skills are very good. Automation is a technique that frees them up from doing mundane manual regression and instead concentrate on exploring a system to find where the bugs lie.
Good QAs I have seen work closely with BAs and make sure they come up with a list of things that are not acceptance criteria because of business requirements but are AC because of reality (what happens when the disk space runs out, what happens if the server are upgrading when the payment gateway responds with a success etc.)
I am by default a “happy path” person - unless I am trying explicitly not to be one. I am quick to dive into figuring out how I would build something. In my head, I start thinking architecture, the design, logging etc. I do not naturally start thinking about - what the requirement should not be, what are the edge cases, what happens when things do not go as they are supposed to etc.
So, yes, while I can automate tests I am not a professional QA. Most awesome QAs have a very specialized skill set and it’s a humbling experience to work with them. So, if you are a looking to get generalists in your team, make sure they have the right skill sets before they wear the QA hat.