A week or so ago, I tweeted the following:
I loathe the use of "QA" as a verb to replace test. E.g. "Facebook needs to QA their features better" – that doesn’t make any f*ing sense.
Paul Carvalho (@can_test) didn’t agree – he stated that test is a subset of qa, and that since he considered much more than testing when performing his activities that what he did was “qa a feature” (massive paraphrase – sorry).
On one hand, I could say that good software programming is also a subset of QA, so a dev could “QA up” a feature rather than code it up under that logic. I’ve been whining about QA vs. Test for half a dozen years, and Michael Bolton more recently (and more eloquently) wrote up his thoughts on the subject early this year. I think anyone who pays attention knows that QA is widely misunderstood. I think Paul gets it – he knows the difference between testing and quality assurance, and what he does is more than just testing, so he may actually do some quality assurance activities along with his activities. I don’t details on his testing activities, so I can’t guess any more than that.
In regards to Bolton’s thoughts, where I differ is that I think that testers can dabble in Quality Assurance. This statement doesn’t apply if you only test apps after they are complete or mostly complete in order to quickly find any “ship-stoppers”, but when development and test are well integrated, there is a possiblity. In my world, testers get to be involved from the earliest inceptions of pre-design. Now, it’s one thing to be “in the room” during a design discussion, but many testers are capable of inserting some QA type goo into the discussion, as well as finding ways to improve the creation of software throughout the product cycle. Some examples include:
- Testers ask things like “How are we going to test this?”, and “how will we know if we’re successful?” during design reviews.
- Testers can look at the most severe bugs found during the last product cycle and develop tools or checklists to prevent those types of bugs from occurring in the future.
- Testers can instigate process change. I’ve never been on a team where testers weren’t involved in highlighting inefficiencies in software engineering processes and implementing changes to improve on those inefficiencies. Normal leadership gotcha’s on organizational change apply (i.e. it’s hard, but certainly possible)
- A HUGE point I agree on with Michael (and others) is that test is not the gatekeeper of quality. When I hear testers talk about “signing off” on a release, I cringe. What testers can do early is say “this is the information we’re going to provide – and we think you can make a ship decision with this information”. Then instead of signing off on a release, testers can say “only half the tests are running, and half of those fail. Customers are complaining, and perf is in the toilet. scheduled ship date is next Tusday – it’s your call”
Good testers have a critical eye – not just for product issues, but in how the product is made – so it’s not completely out of the question for capable testers in the right environment to dabble a bit in QA activities.
The summary – if you’ve both read this far, and I’ve lost you is:
- QA and testing are different
- IMO, QA is not an activity you do to a feature
- In the right circumstances, some people in test roles can perform QA activities
- But QA activities are generally separate from test activities
Got it?
If you have old issues of Better Software or a PowerPass thingie on stickyminds.com, I had an opinion piece in the Nov/Dec 2009 issue called “QA is Not Evil”.
A section of my chapter in Beautiful Testing has the same title.
Those might be of interest.
I remember that article….now (for readers, I just went and re-read it online at http://www.nxtbook.com/nxtbooks/sqe/bettersoftware_1109/index.php?startid=43#/44).
And of course, I read your article in BT.
Have I mentioned lately that I like the way you think?
This post seems to be channeling the way I’ve approached my job lately. In the past couple of weeks I’ve had discussions with:
Product managers
Developers
Tech writers
Support
Designers
Other testers on my product and other products
All of the discussions have helped to improve the product I test. In fact, I had the opportunity to write some test objectives for a feature that doesn’t even have a spec yet. Our product manager was grateful because it gives him additional scenarios and stories to consider when he’s talking with design about the feature.
To hippie-fy it a little, my role is becoming much more holistic, because I have hooks into our process at a higher level and a more granular level. It helps me to make connections not just about our features but about how we make the features. Since I talk to everyone involved with making our product regularly, they are now more likely to listen to me when I say something about our process isn’t working.