The Quest for Quality conference was held in Dublin, on 3-4 October 2018. This article is a summary written by one of our Bright consultants – Pieter Laenen – who had the chance of attending the conference. This summary of his impressions and key takeaways are worth reading!
The Quest for Quality is a small (200-300 people), though sociable testing conference with quite some potential. This was the third edition, which translates into a limited set of speakers divided over 2 rooms, which also means less speakers linked to vendors.
This year’s topic: Artificial Intelligence. Sadly, a lot of buzz is generated by people who cannot pinpoint exactly what this AI is all about. Of the topics I attended, those not related to AI were the more interesting ones.
Bug rate is that much higher in software development as compared to e.g. aviation because the cost of a failure is that much more distributed over time and space. One failure (usually) does not cause the complete degradation of your product and data. For the same reasons, quality processes in software development are followed less rigidly as compared to other industries, although pushing for better (applied) processes will improve software quality.
Software testing cannot move to 100% automation. Furthermore, 100% automation cannibalises the time testers can spend on exploratory testing. The ideal mix in agile testing is automated regression combined with manual exploratory testing. Automated testing gives a baseline coverage but cannot catch all the subtle issues that degrade user experience. Emphasizing this mix is important to counter delusions about what test automation can achieve – because managers might overestimate this. No automation script can ever incorporate true human interaction, e.g. using a textbox in a flaky way (filling, removing, typing slowly, changing your mind).
Agile pitfall – not everyone can tackle every problem, not even after years of working agile in the same team. T-shaped people still only have approximate knowledge of a lot of things.
You don’t need to find every defect, only the ones that impact your client, which is a hard sell to your manager. Talk to Customer Support because they feel the costumer’s pain come in through the phone.
Communication and pro-activity are necessary skills for a good tester, ranking higher than any technical knowledge. Business knowledge is also very important, because it enables testers to distinguish between what the requirements say and how things should behave.
Countering bias in testing is done easiest by testing with people who have different views on the problem. Mob testing where even managers are involved gives a unique take on what the issues are for different stakeholders. Counterargument against these sessions is the price, involving high ranking people is expensive, so you might not be able to do them as often as you like. Other, easy to implement, measures against bias are to test in pairs.
In larger organisations, a testing strategy is something that should be defined top-down. Otherwise, you risk holes in your test coverage because people inside a particular domain don’t have the same overview. Furthermore, bottom-up testing strategies usually lack the proper foundations to extend their coverage to multiple levels.
The moment a good metric becomes a target, it ceases to be a good metric. People will find ways to skew their process towards attaining their goal, rather than testing correctly.
Many thanks to Pieter for his no-nonsense recap of this year’s Quest for Quality conference.
Interested in a career at Brightest? Check out our open vacancies!