“Radically delete tests that are not worth the effort. Always question the purpose.”
How to cut cost overheads, when to make developers part of the Quality Strategy, and why we all need diverse QA teams.
Sarah Hutchins is a seasoned professional with over 10 years experience in the QA field. She started her career as a consultant and later shifted to working directly with companies. Currently, Sarah is a QA strategist at Vinted, an app that enables people to buy and sell clothing from one another, keeping items in circulation for longer.
We discussed the importance of QA as a strategic role, the challenges faced by QA teams, the need for collaboration between testers and developers and the Swiss cheese model, which can take your project to the next level of security and help save money at the same time.
How does your current role differ from your previous consulting experience?
In consulting, even if team members were complete strangers at the start of a project, we quickly formed a close-knit team. We collaborated effectively, supporting each other and discussing our work to ensure success. It was a great experience.
Now, at Vinted, I work closely with individual product teams, focusing on their quality initiatives. The interesting part is that not every team has a dedicated QA resource. That’s where I come in. I provide support and guidance to ensure that quality remains a top priority.
Consulting offered a more defined structure that didn’t change much from one project to another. Here, things are more dynamic. I adapt to the ever-changing environment and find ways to contribute effectively.
As a professional who identifies as a Quality Strategist, could you please elaborate on the concept?
In my field, terms like Quality Assurance, Quality Analyst are often used interchangeably, causing confusion. As a Quality Strategist, my role extends beyond traditional testing.
At the strategic leadership level, I shape the Quality Strategy for projects. This involves more than just conducting tests; it encompasses various elements such as test planning, monitoring, security, and performance. I believe that almost everything we do in the software development process, apart from writing production code, has an impact on quality and should be explicitly acknowledged and addressed.
By embracing the role of a Quality Strategist, we ensure a comprehensive and proactive approach to quality. It’s about taking a strategic perspective and actively shaping the quality outcomes of our projects.
As a Quality Strategist, how closely do you collaborate with the development team?
I strongly believe that product creators should take full ownership of the quality of their work. I work closely with developers to ensure that their quality strategy is on point and effective. Developers are the pros when it comes to coding, so they should be actively involved in creating automated tests. In fact, it’s our default approach for the teams I support.
However, if the need arises, I happily take the lead in testing while working hand in hand with developers to provide them with the necessary context. This collaboration between strategists and developers really paves the way for successful and robust quality practices.
Each team develops its own quality strategy, which involves defining the necessary tests and monitoring. We consider factors like critical user flows and performance requirements to determine appropriate testing strategies. By addressing quality concerns proactively, we prevent it from becoming an afterthought and ensure its impact on our products is meaningful.
Our Featured Testing Projects
They say that development is much more domain-based than QA. How does this gap affect QA strategy?
From a strategic perspective, QA is indeed less domain based. But in reality, QA becomes the domain expert within a team, and losing that expertise can have significant consequences.
QA professionals often possess extensive knowledge of edge cases and use domain-specific understanding to conduct better exploratory testing. While documenting edge cases is important, having someone who can explain the reasoning behind them and lay down all interactions adds invaluable insight.
Experienced QA professionals hold a wealth of knowledge that may not be easily replaceable. Acknowledge them! Although our tools and techniques may not be domain based, our knowledge and work approach certainly are.
Speaking about approaches. Which concepts or frameworks do you find useful?
In QA, we tend to neglect discussing malicious users and the costly layers of protection. My intention is to make these implicit factors explicit and raise awareness about the importance of a comprehensive quality strategy.
I often emphasize the Swiss cheese model’s elegance and efficiency. It was originated in the aerospace industry, and emphasizes the need to address all layers of potential vulnerabilities.
Similar to Swiss cheese, software development strategies can have gaps. For instance, relying solely on unit tests may overlook issues when integrating with external systems. By adopting a multi-layered approach, these gaps can be addressed effectively.
It’s crucial to evaluate the suitability of each layer for specific events. Applying the Swiss cheese model involves examining our interactions with security, automation tests, and other aspects of quality. It prompts us to question their efficiency and whether the investment is justified.
I advocate for radically deleting tests that aren’t worth the effort and rethinking their purpose. For example, focusing automation tests on critical flows and keeping their numbers small can lead to more effective testing and maintenance.
When evaluating tests, we need to consider what they are actually testing. Some tests may have been written just for the sake of having tests, while others may focus on specific integrations. In the latter case, we should explore alternative testing approaches, such as focused tests that directly assess the code and integration. In some cases, replacing tests with monitoring can also be more efficient and cost-effective.
In terms of improving the process, we’re seeing a shift towards automation. How can we strike a balance with manual testing?
You know, it’s like a pendulum swinging back and forth. In the past, QA was all about manual testing, and then automation came along and took the spotlight. But here’s the thing: the real essence of QA lies in identifying risks and finding ways to mitigate them. It’s not about being strictly manual or fully automated.
That’s why I believe QA should be seen as a strategic role, encompassing both manual and automated testing. It’s like finding the perfect balance, where exploratory testing adds that extra layer of assurance on top of verifying critical flows. That’s when QA truly shines and delivers the most effective results.
Where does AI testing fit into this picture?
AI testing can be a valuable addition. Automation tools can cover many UI aspects, but there are gaps. For example, accessibility testing requires a combination of automated tools and manual efforts. There are various “deviations from standard usage” like being colorblind or using left-hand for apps predominantly created for right-hand users that AI tools may not fully capture. Manual exploratory testing remains important for uncovering such issues.
QA should be strategic and not limited to specific tools. AI has the potential to automate many repetitive tasks in QA, but there are also cases where automation goes beyond what AI can currently handle.
When approaching a new project strategically, what are the key questions you would ask?
One of the first questions would be about the personas interacting with the application. Understanding their wants and needs (which are different!), as well as our relationship with them, is crucial. Additionally, we need to consider the technical aspects of the project, such as external and internal integrations, and their characteristics.
This information guides our focus and helps us determine which aspects require attention. For example, mature and stable third-party tools may not require extensive integration tests unless there are concerns about our usage or lack of documentation. The goal is to test our usage of the tool rather than the tool itself, ensuring our confidence in its stability.
You said meeting someone’s wants and needs is not the same. Can you elaborate on that?
Absolutely. Needs are the critical path in an application. If you fail to meet the needs, customers won’t find value in using the app. However, meeting their wants takes the application from necessary to a pleasure to use. When you meet their wants, it creates an emotional connection and builds customer loyalty. Customers are more likely to give you leeway and provide feedback instead of jumping ship when issues arise.
Meeting needs is essential, but meeting wants is what fosters that emotional connection with the customers that helps you beat the competitors and stay afloat when some issues arise.
Having diverse teams brings different perspectives and experiences, allowing us to address a wider range of wants and needs that people may not even think about until they interact with someone who is different from them.
Do you have any advice on how to address this diversity and inclusion issue?
The best advice is also the hardest to follow: hire more diverse people. By having a diverse team, you can ensure that different perspectives are represented, and various wants and needs are taken into account during the development and testing process. It helps avoid missing crucial aspects that could negatively impact certain user groups.
The industry is making progress. Accessibility and diversity are becoming more prominent topics. For example, at an upcoming testing conference, there will be a speaker discussing the interoperability of spaces, highlighting the importance of inclusivity in testing.
This shows that the industry is moving in the right direction.
We all should.
Share:
Hire a team
Let us assemble a dream team of specialists just for you. Our model allows you to maximize the efficiency of your team.
Written by
We Help With
Your tech partner needs to be well versed in all kinds of software-related services. As the software development process involves different stages and cycles, the most natural solution is to have them all performed by the same team of experts. That’s exactly what our diverse range of services is for.
The choice of technology for your software project is one of the defining factors of its success. Here at QArea, we have hands-on experience with dozens of popular front-end, back-end, and mobile technologies for creating robust software solutions.
In-depth familiarity and practical experience with key technologies are one of the cornerstones of successful software development and QA. But it also takes specific knowledge of the industry to develop a solution that meets the expectations of the stakeholders and propels its owner to success.
Ensure an effective online presence for your business with a corporate site.
