“QA versus Testing: Antagonism or Symbiosis?” was the theme for the 2012 Belgium Testing Days Conference. QA and software test have often been used synonymously, but there are some subtle and not-so-subtle differences, depending on who you talk to. In this second part of a two-part series, I continue with a summary of many of the conference sessions, starting with keynote from industry leader and SSQ contributor Karen Johnson.
Is it important what I’m called?
The “QA vs. Test” debate was a force in Karen Johnson’s keynote. Karen asked us to keep an open mind and look at different viewpoints of one’s job title. A job title can help define your abilities to others, it can affect your salary, or give you access to influential people.
On the other side of the coin, influence is earned, not assigned via job title. Titles may contribute to pigeonholing us in one position, and they don’t measure career accomplishments. Karen quoted many software professionals talking about why they care or don’t care what they are called. Do you want to be a “Senior QA Engineer” or a “Tester”? In the end, the professional contributions we leave behind may be more important than our job titles.
Solving large-scale testing and QA problems
One of the most valuable sessions I attended was a workshop on large scale Agile testing and QA, facilitated by Kirsi Korhonen and Eveliina Vuolli. Kirsi and Eveliina asked each table group to come up with our biggest challenges in large-scale agile projects. We wrote sticky notes to post on the wall and then voted on which topic to tackle first.
I asked for help with a colleague’s problem: If you’re given a huge, traditional requirements document, how do you engage stakeholders in slicing those up into small user stories, and prioritizing which to do first? Johanna Rothman, who was in my table group, suggested asking the stakeholders, “What do you want to see in the first demo?” I left the workshop with several experiments for my own team to try.
What’s in a name?
Stefaan Luckermaan explored the “what’s in a name” quandary generated by the “Test vs. QA” debate. He used the metaphor of a bowler hat, which was originally designed to protect gamekeepers’ heads, as it was shorter than a top hat and let them slide under low-hanging branches on horseback. Just as we have different names for software quality and testing, bowler hats are called by other names, such as “derbies.” Different people and characters have used bowlers for different reasons: a trademark, a status symbol, part of a uniform, comedy, an artistic statement.
Like a particular style of hat, quality doesn’t fit one stereotype. Quality is the result of a carefully constructed cultural environment. It has to be the fabric of the organization, not just part of the fabric. Stefaan suggests creating a Quality Mission Statement that is similar to a balanced scorecard – quality according to us, according to our customer, the benefits, the results of our work, a learning process. We must keep experimenting, and get out of our comfort zone, to grow our skills and improve quality.
One project, two perspectives
Adrian Rapan and Tony Bruce shared lessons learned from an ill-fated project where cultures clashed. Permanent employees of the organization didn’t want to change, so contractors’ attempts to improve quality met resistance. Different teams working on different parts of the same system didn’t talk, and they also didn’t talk to customers, citing that they couldn’t afford the time. Long feedback cycles left testers “in the dark” and resulted in last-minute requirement changes.
Tony and Adrian had to find new ways to learn business needs. One lesson learned was the importance of making requirements visible to the whole team in order to get feedback on potential gaps. One way to accomplish this is to find a format that’s accessible to everyone. Automated regression testing provided “living documentation” as well as coverage metrics.
Their experience showed that the purpose of testing is to provide information, and the purpose of QA is to use that information as part of the effort to optimize processes to improve quality. The problems Tony and Adrian described are common, and one important step they took was to understand the conflicting cultures and find ways to work around resistance to change.
Both testing and QA are pro-quality
In Sigge Birgisson’s view, testing is product-centric; QA is process-centric, but both are pro-quality. For Sigge, QA in a product context is checking, a verification activity. Testing moves the project forward.
Sigge recounted his experiences working in a Waterfall project. Their manager pressured them to update documentation “for the future,” and provide metrics such as the number of tests completed. Sigge’s team felt that adding business value “now” was more important, so they intentionally incurred “document debt” by delaying documentation updates. They turned to the overwhelming number of defect reports, analyzed bugs from a business perspective, and told the business what was and was not working. Business experts could then identify what really mattered. In the end, they went beyond both testing and QA, to focus on delivering the value needed.
Focus on outcomes
Are we doing QA or testing? After the excellent discussions at Belgium Testing Days, my own conclusion is that we should focus on whether the features we deliver are providing the expected value to the business. A continual feedback and learning loop will help us stay on track to ever-improving quality.