28 Jan 21 Events
Check out the full event recording below!
We kicked off our 2021 event calendar last week with our first digital panel event of the year. Organised by our QA specialist, Jay Despojo, we brought together a brilliant panel of 5 technologists to discuss the changing role of Quality Engineering and how to influence a quality mindset among your tech teams.
Organisations are increasingly trying to adopt the ideal goal of everyone thinking about quality, but face challenges along the way such as a lack of resources, mindset and hiring the right people. We wanted to create a discussion with our community, featuring perspectives from QA, Product & Engineering backgrounds to exchange ideas and experiences on the journey to a quality-driven culture.
Through an interactive online discussion with lots of audience participation in the chat box and through our Slido channel, we created a learning environment to hear how other teams are approaching the journey to quality, and our panel discussed some of the most common challenges you're likely to face along the way. Such as getting buy-in from the team and Engineers, allocating accountability and ownership of quality & how to balance delivery pressures.
It was a great discussion and we've shared a roundup of all the key advice and takeaways shared - we hope you find them useful!
Marie – I can see a trend from attending other meetups and reading about what other testers in the community are saying and it seems that some of them are asking the questions, is automation going to replace us? Do we need to automate everything? My personal opinion is that we are here to stay, however we need to adapt. Rather than acting like gatekeepers, the role of the QA is moving towards being a quality advocate. It’s all about sharing the knowledge and being a quality coach to your team, not just owning the testing.
This is backed up by emerging tools that are more Developer friendly that cater to improving their experience so that they're motivated to write the tests. It doesn’t mean that we are not needed, but where we provide value will be in a much broader area. Rather than owning the checks or functional tests we’re thinking about how we can improve the speed of our release process, the usability, the user experience etc. But this is also where we need help from Developers as well. We’re moving into a coaching role and championing the fact that everyone should be testing, it's no longer solely our responsibility.
Antonello – One pitfall to keep in mind is that by wanting to empower teams to take more ownership around the quality of a product and the software they develop, they also need to take on some of that ‘governance’ themselves. If they are not in charge of deciding when they want to release the increments that they have developed, then they are just going to give up on their desire to be the owners and the drivers of that. So I think the role of the QA as a coach can help with building those processes, practices and checklists that can help translate that governance into something that they own and can have control of, with the support from the QA. This is also part of creating a culture that can make it sustainable.
Marc – My hope as a Product Manager is the same thing as everyone else in the team, you deliver the value to the customer that you set out to deliver, and ideally as a team. The key thing is that quality should be everyone’s responsibility.
What does this mean practically? Well, what I am trying to do with my teams in my current role is things like pairing, where I encourage the Product Owner to sit with the QA or a Developer to sit with a QA so that we all have that shared understanding of the value that we are trying to deliver to the customer and making quality much more of a shared responsibility.
Marie – As a QA we can’t dictate what needs to be prioritised and this is a common misconception that we have the final say. But what you can do instead is communicate: what are the risks? For example, we do Tech analysis sessions where we gather the different requirements and QAs are always involved. We talk about different risks and what I love about this meeting is that it’s not just the QAs thinking about what the different risk factors are. Even our Developers are contributing so it goes to show that we are making small steps to ensure that everyone is thinking about quality.
Antonello – One of the fundamental points for me is to find allies. Find people who share your vision and who are keen to see things improve in certain areas. Amongst these allies it's particularly important that you find people who are recognised leaders within the organisation and invest in educating them. Listen to their needs and help them understand how quality will contribute to their own success and the success of the organisation. In my experience, if you persist and work closely with them, you will see change and they will see change too.
Pedro – In the wider business, people are quite obsessed with velocity these days, but sustained velocity can only be achieved with quality. So this is another way to sell to the business why you should be hiring more QA Engineers.
Marc – I always try to bring it back to the customer, I try to make sure that my Product Owners and managers do regular product retrospectives, really zooming in on the product and taking on customer feedback about what doesn’t work, what issues or bugs they’ve had. It’s very easy to focus on velocity, but to bring it back to quality through the customer is really effective.
Marie – I think it really helps if you speak a language that the businesses can understand. I read a book last year that I would recommend to everyone called ‘Leading Quality’. The authors, Ronald Cummings-John & Owais Peer, mention that whilst finding allies is really important, if you cannot connect to that person directly, find someone who is closer to that person and influence them first, as they will then influence the person you are targeting.
Pedro – I find it tricky in new companies where you don’t have that internal data to back up having more quality measures within your product development process. Sometimes it's hard to use external data, sometimes people need to see it for themselves, or even when it goes wrong – knowing that it was a result of not investing in certain processes. I think this is very common within young start-ups. Whereas with larger companies they have a lot of data about how things can go wrong when you don’t invest in quality.
Antonello – One of the advantages of a start-up is that if you want to create that culture from the start, it’s a more approachable challenge and you have fewer people to get on board. But at the same time, start-ups are really driven by fast growth, so whilst they might be on board there is also a desire to turn feature fast – so how do you balance quality with fast growth and ensuring the success of the start-up?
Marc – With larger companies you have more systems and more dependencies, which puts more pressure on consistency of process and standards.
Antonello – At Treatwell, we wanted to step up our approach to test automation, especially in the context of continuous delivery. We surveyed the entire tech team and asked them what their confidence was in our approach. We got a number of 7. We then spent 6 months hosting workshops with each team, trying to understand where we were at, where the gaps were and to articulate a vision and approach that would work for everyone. After those 6 months our confidence score from our teams went up and by involving Engineers in the conversations, their knowledge grew and they also became allies as they felt involved.
Marie – For me, just by speaking about testing and quality and educating the business really helps. Last year I did a flash talk where different people shared their insights and I spoke about accessibility testing. After my talk, within two working weeks we had some input from our UX Designer and she then did another talk about accessibility. It’s a spiral effect and your words have influence.
Pedro – From an Engineering Manger perspective, it's very important to have one-to-ones with your Engineers. If Engineers have to deliver something quickly under a deadline and they will accrue a lot of technical debt, you need to discuss with them that Engineers are assessed too on the solutions they come up with. That way they are incentivised to deliver quality.
Using our interactive Slido channel we asked the audience to share some of their biggest challenges they see when trying to influence quality - see the panel's full word cloud discussion here.
Marc – Finding time to focus on quality should be an integral part of what we do and not something we should necessarily carve out time for. But we should always look at the iron triangle between time, scope and budget and I expect a Product Owner to always fly the flag for quality as that is something that he or she can really influence.
I find delivery pressures can be a false economy, as a lot of the time we're trying to stick to an imaginary deadline that someone has set and so we start to cut corners from a quality or customer experience perspective which come to bite you shortly after. Ask yourself, why is that pressure there? How can we mitigate it without sacrificing quality?
Pedro – Why is there a deadline or delivery pressure in the first place? Before tackling quality, you need to tackle that first. Usually it's because you want to run faster than other companies as you think everything is a missed opportunity if you don’t deliver it on a particular date. Sometimes you do have a very tight deadline for a good reason, and in this case I would say come up with a solution that is not optimal but that you will come back to it as soon as possible to avoid issues like technical debt as it will hurt you later on.
Antonello – Another element is understanding as an organisation what is not negotiable. We have years of baggage when it comes to quality because of how it was approached traditionally – and even sometimes still today – as an afterthought; a stage after development in an agile world, a second class citizen etc. This opens up the possibility of making choices on quality because there are delivery pressures. But you wouldn’t treat other parts of engineering the same way? If in time we set what is not negotiable when it comes to quality, people would stop questioning it and it would become a part of those real or wishful thinking estimates or deadlines that people aspire to hit. I hope that in time most teams can get to a point where doing certain things around quality will just happen because there is no other way of doing it.
To conclude, it seems that we are all about creating a culture that makes quality sustainable. Teams need a shared understanding of the value that you want to deliver to the customer and to work together to do this, making quality a shared responsibility. Finding allies and recognised leaders who share your vision and are keen to see things improve is crucial. By listening to people’s needs and presenting how quality will make a difference to their own success is a great way to get people on board and share your quality driven mindset. Speaking a language that the wider company can understand is really important in order to avoid communication breaking down, which will hinder adding quality to the agenda. And finally, companies that do quality well tend to do better as a whole, and whilst the scope of the role of a Quality Engineer might be changing, the role of quality is certainly here to stay.
We'd like to say a massive thank you to our panellists, to Nicola for moderating the evenings discussion and to everyone in the audience who contributed to the debate and shared experiences, it made for a great conversation. If you have any additional questions or would like more advice on influencing Quality, please feel free to get in touch with any of our speakers.
How are you and your team implementing a Quality driven mindset? We'd love to hear from you and share your practices with our community!