First a bit of context: I am a QA engineer working in an organization that has 5 different product teams. I am a part of the 2 member QA team that exists outside of the product teams. We are not embedded in the product teams. So far, our responsibility has been to implement and improve Automated Tests for different products. Testing of individual features during the sprint is done by the product owners of the respective product teams.
I have often felt that in our current setup, the scope and impact of the QA team is very limited. Not being embedded in the product teams means we have not been able to influence Quality culture in the teams. I see lot of scope for various improvements such as adopting risk based exploratory testing techniques, coaching devs in exploratory testing, implementing shift left approach to testing, and so on.
This talk on Atlassianâs approach to QA really resonated with me: slides and talk and got me motivated to implement something similar in my company.
A high level summary of this strategy:
Embed QA in different product teams on a rotational basis e.g. 3 months.
QA initially does exploratory testing of features during the sprint. But they also conduct knowledge sharing sessions with devs on how to approach the exploratory testing during the sprint and coming up with a test strategy by assessing risks associated with the features.
Gradually start involving devs in testing. Pair with devs and coach them on various exploratory testing techniques and helping devs come up with a test strategy on their own.
As devs start to test better, QA can reduce their involvement. QA role can be limited to just reviewing the testing notes shared by devs.
As testing capabilities within the team improves to a desired level, QA can now move to a different team.
I presented this strategy to my manager and his feedback was quite positive. However, he also highlighted some potential risks associated with this strategy, if we are going to implement it in our product teams.
Some of the risks were:
Would developers feel motivated to do exploratory testing? These are the people who love to code and they may not be interested or motivated to do exploratory testing. How do you proceed in that case?
Devs spending time on testing means their output in terms of writing code would be impacted. How do you convince EMs and Business folks if this is the right approach?
Manual testing is considered obsolete by many and devs would rather say that we should focus on doing more and more Automation instead of too much manual testing. How do you convince them in favour of exploratory testing?
I am really curious to hear from you if you experienced similar pushback when trying to involve devs in testing and how would you respond to the above questions. Do you see benefits of this strategy? If so, I would love to hear from you how can I make a strong case for it.
Thank You
Building a quality culture within engineering teams is essential for developing a high-performing, resilient software development environment. In my experience, implementing an effective quality-focused mindset goes beyond just adding testing to the processâitâs about embedding Quality Assurance (QA), Quality Control (QC), and testing seamlessly across the development lifecycle. Here are some strategies that have proven effective:
Educate Beyond Testing: Quality is often misunderstood as just âtesting.â Educating engineers about the broader QA spectrumâQA, QC, and testingâhelps reshape this view. Quality is a continuous, proactive effort woven through planning, development, and delivery stages, not just a final step. This foundation helps teams appreciate that testing is one component of a holistic quality approach.
Visualise Quality with Metrics: Engineers often focus on metrics like velocity, which can create the impression that quality processes slow things down. Introducing metrics that track the impact of quality efforts helps illustrate the value added. For example, I use metrics such as the number of story points accepted by product versus those delivered. Emphasising that itâs better to deliver 15 points with high acceptance rates rather than 20 points with only 12 accepted demonstrates how focusing on quality improves team output and satisfaction.
Use Relatable Analogies: Using everyday examples can make quality processes more relatable and engaging. For instance, I might compare quality checks to a builderâs responsibility to inspect a wall before declaring it complete. Just as no one would accept a builderâs work without checks, software delivery should also involve thorough quality assessments. These analogies help normalise quality as a critical and expected part of delivery.
Show, Donât Tell: Engineers may be sceptical initially, so itâs crucial to visualise the impact of quality improvements. Sometimes, only when they see firsthand the difference that quality efforts makeâsuch as reduced bug counts or smoother feature releasesâdo they fully buy into the culture. Being ready with examples, comparisons, or even dashboards displaying the before-and-after metrics can help bring this to life.
Celebrate Quality Wins: Recognising achievements in quality not only reinforces the behaviour but also boosts morale. Highlighting quality-driven successes, like a smooth release or a significant drop in post-release issues, shows the team the tangible benefits of their efforts and builds enthusiasm for maintaining these practices.
Refocus Dedicated Testers: When quality practices are embedded throughout, dedicated testers can concentrate on higher-level testing effortsâlike exploratory testing, complex scenarios, and integration pointsârather than spending time on basic validation tasks. This elevates the value and impact of the QA team, allowing them to work on areas where their expertise is most needed.
By establishing these practices, you foster a culture that views quality as a shared responsibility rather than an afterthought. A strong quality culture not only drives better software but also increases team satisfaction, customer trust, and ultimately, long-term success.
Motivate developers on QA aspects that they are good at and that they can do better than testers, e.g. unit tests, some automation, tech docs, code reviews, using new effective tools/tech/frameworks, helping testers to understand their code, helping with test envs/generating test data, etc. Testers/QA engineers can do exploratory and manual testing better than devs (in many situations) and they are motivated to do so
Do not mix different problems in your team/organization:
1 - lack of engineering culture, lack of understanding of the value of QA and testing, lack of understanding of how quality impacts business goals, product success and user satisfaction
and
2 - lack of knowledge of how to properly apply and utilize team resources for achieving higher product quality in more efficient ways
Seems that you have both of them and without dealing with the 1st one you wonât be able to effectively do anything regarding the 2nd one.
Iâd like to known more about the problem that the company, team and you have with the current roles, processes.
Having a âfeelingâ that something might be bad isnât enough. Iâd first consider doing some quality related assessment on various levels: product, process, company.
I can understand that the QA engineers have been hired not to test, but to implement automated checks/scripts/programs that would go into certain pipelines.
And you want to take ownership of something more.
What would you want to achieve? Does the company/team need it? As your manager said, can you convince stakeholders about itâs business value, financially speaking mostly.
Have you thought of what youâd need to achieve it: budget, power, people, support?
Devs spending time on testing means their output in terms of writing code would be impacted. How do you convince EMs and Business folks if this is the right approach?
Yes, writing code will be impacted: They will write better code if there is a tester in the team embedded because they can do ensemble testing with 3 Amigos and learn from eachother. Testers knwing their heuristics to design tests very good. Developers normally didnât have the training on this. So, both will win: Developers will write better code and testers will be empowered as they can contribute their expertise.
Manual testing is considered obsolete by many and devs would rather say that we should focus on doing more and more Automation instead of too much manual testing. How do you convince them in favour of exploratory testing?
Manual testing wonât die because we are doing the job at the end to support humans in using technical things. Also the impact to do e.g. optical checking for correctnes in layouting is high. It makes more sense that humans look at that. Exploratory testing from many team members in different roles is like 3 Amigos: It gives early feedback from different views and at the end we are all users.
Based on the conversation I have had with devs in different teams, few things are common across all teams:
Testing is given a serious thought only after a feature ticket is marked as âready for testingâ
Testing is very superficial. Good exploratory testing practices by doing risk based assessment to derive test plans is not being followed. Testing is done only to validate âfunctional correctnessâ. Other quality aspects are not considered.
Automation is strongly encouraged but it is thought only in terms of unit testing or e2e testing. We also have API tests for our public APIs. Creating automated tests as part of feature development is not followed consistently.
The current testing processes makes me believe we are following waterfall model in a sprint based setup where testing is thought about only when the feature leaves developerâs hand. Thatâs where I feel shift left testing strategy coupled with 3 amigos can come in useful where dev is already aware about all the risks beforehand and knows what kind of testing will be done for the feature even before he has written any code.
My concern is that the teams donât consider it as an issue but I feel its also my job to make them aware about it and try to put in good quality practices across development cycle. It also makes it tougher for me because I feel I am trying to sell a solution for a problem that is not considered to be a problem by the teams. So my question is how to make a strong case for it in terms of the business value? What kind of metrics can I use to make a case for it? I need strong arguments to convince both devs and business people to put in more effort in improving testing capabilities across teams, since there is no plan to have dedicated testers in the team.
A few arguments I can think of are also in line with some of the previous comments:
Devs will be prompted to write better code taking into account all the risks. But can I support this statement with any metric?
Less back and forth with the feature tickets moved back to developer from the testing phase. So better dev experience and productivity, less context switching.
Less production bugs, surely? But We have to try it first to see its results.