Looking for some advice really and if anyone is in a similar situation is your process working.
We are a team of 8, 6 devs, 1 QA and 1 PO. If there are more than about 3 tickets in QA then devs will jump in and start testing but not their own work and the same applies to the PO, where they can test they would help out. I’m doing manual testing and test automation. At the same time exploring Playwright and writing some tests as well as continuing to add to our Selenium test suite.
There is no plan afaik this year to hire another QA.
The only thing that worries me is yes there’s some burden off me but at the same time devs are not QA’s. We haven’t had any major issues recently in the sense that devs haven’t QA tested properly and there have been bugs , which is good.
Anyone else in a similar situation and feel the same?
Have you taken a different approach instead?
In the last couple of years I really wanted to focus more on Test Automation and this approach has enabled me to do so. Currently doing about 30%-40% Automation and about 60-70% manual testing
I think you already provided the answer yourself. The devs need to get involved with testing, getting them to write the automated selenium tests for their features might be the best place to start. Make it part of the definition of done of a story.
Then you as QA can jump into reviewing the tests they write and help extend coverage where needed. Hopefully, this will allow you to have some extra time to validate features from a more holistic view, minimising the risk of issues being missed by the devs.
Thanks for the reply.
Yes the devs get involved in manual testing. I normally focus on writing the selenium/playwright tests as well as manual testing and when needed the devs help out on test automation as qwll
Not all features are automated just depends which ones provide more value.
Hi,
I don’t see anything about product and business risks.
A product might need more testers than devs, some can work without any.
How do you know there’s more testing or automation needed?
And why do you think dealing with it as a team isn’t a good idea? Are the others sharing your point of view?
Although this is a common problem in most of the smaller teams, you could consider few best practices
Adopt Shift-left testing approach
You could introduce TDD or at least encourage devs to write unit tests before feature development ( if not already being followed)
Since developers are helping with testing, giving them some basic Testing guidelines can help them look at the product differently and not just from their own coding perspective.
I’m often working with 10 plus developers across multiple projects for example.
What works for us is developers do a fair amount of testing and own the automation, they tend to be really good at this and its generally more efficient to automate as the code is written.
That switches most of my time to technical hands on discovery and investigation of risk. Its usually the fasted feedback loop when unknowns are in play. This is my much preferred role and activity so I likely have a bias for getting teams on board with the value of this model.
On some projects I do focus on the automation a bit more, for me this is more focus and I tend not to be as comfortable jumping in and out of 4 projects in parallel when this is my focus. It’s less efficient than above but sometimes that automation would just not happen unless I picked it up myself.
When its one to ten though, it makes sense to me that developers pick up the known risk coverage including automation and I add that area of unknown risk specialisation that comes with being a pro tester.
Sounds like the set up you have isn’t too bad, to be honest, as it seems like everyone on the team has some involvement in testing.
What I’m missing a little bit is what you’re trying to achieve, or what problem exists to solve? You said you wanted to focus more on automation - do you want to be the one writing it, or do you just want to increase the utilisation of automated checks on the project? You’ve asked about different approaches, but I’m not sure what the approach would be towards in this case.
Regarding your concerns about devs / the PO testing, is there any reason you couldn’t teach / coach them to test more in a way which would increase your confidence? Since there haven’t been any major issues recently, is there any reason you have concerns apart from the fact that “devs are not QAs”?
Hi, So in the company we have about 3 teams of about 5-6 devs to 1 QA. So we have about 16 devs and 3 QA’s
In my team devs are happy to pick up manual testing so we don’t end up with too many bugs/features that need testing.
I’m pretty happy with the current setup we have but wanted to check if other’s have a similar approach as well
Thanks for your reply. We do work in an Agile ish kind of way. One thing we haven’t done is write UI automated tests early as possible. Most of the time its done once the feature has been manually tested by myself or a dev. On rare occasions we have done this
Testing guidelines sounds good. Are you aware of any on this site or should I just create it myself?
Thanks for your input. We have another team of devs and a QA and the devs in that team own test automation and they manage all that so the QA just focuses on manual testing.
I thought 6 devs to 1 QA wasn’t a great ratio but 1 to 10 doesn’t sound great
Thanks for the reply. For the last couple of years i’ve tried to focus more on writing selenium tests with c# and now spending some time on playwright with c#. I’ve wanted to move more into test automation, which means less time in manual testing. I’m happy with that as a) i’m gaining more experience in test automation and b) when its time to move on its on my cv
I know we won’t be having another QA anytime soon but if we did then it would have been likely the would focus on manual testing and myself solely on test automation.
Devs/PO have in the passed looked at my JIRA ticket testing notes to see how i’ve tested just so they can get an idea of it. I’ve also spent a bit of time with certain devs to show them how I would have tested a particular feature but as someone previously commented testing guidelines would be a good approach.
I can speak from experience as currently I work at a place where there are 16 software developers and 2 QA. For the QA’s, my co-worker acts more in the form of bug triage. I was the first QA brought out board to build QA practices from the ground up and build our automated test suite.
From your original post, my understanding is that you are taking a gut check almost? My main question for you and your team is, is it working for you? If it is, great! Don’t worry about the numbers. If it isn’t, what are the pain points? Is there anything frustrating for you? It doesn’t sound like the developers are frustrated though it would be good to ask.
For myself, I am brought in on a few (not all) projects. All developers are expected to test their own work, and have their work tested by developers. For the projects that I am working on, my focus is manual testing while maintaining our current automation (we just finished the bulk of the work recently so I’m not doing major adds at the moment).
How do you feel like you are doing? Do you have the support that you need? And, is this an organization that listens to you when you have concerns? Being the only QA, your health and well-being are crucial since being in this type of position can feel a little isolating. I’ve experienced this as well.
I have to agree with Cassandra. When you have that kind of imbalance in resourcing, the most important thing is that you’re not being left on your own and the rest of the team are picking up areas of testing that are their strength.
I think this is where you ask yourself, is the problem what you “want” to be doing or what you “need” to be doing in this team shape.
I would see my role in this environment as a Quality Consultant to be honest. Yep accept that dev will need to do some testing, embrace it, but work with them to make sure they’re considering the pertinent scenarios. Test where you can, automate where you can using your expertise in the areas that play to your strengths.
Hi,
I’m an QA and with 11 dev & 1PO . I totally feel with you. We changed our process to automated everything so QA shoulder is a bit lighter. But this was a team decision and where I keep an big eye on it that every day the full automation is running green. Tip automate your basics first and then get bigger.
I haven’t seen any specific testing guidelines on this site ( I may be wrong!) but creating your own based on your product / application needs might be the best approach. You could include things like:
Basic testing principles - exploratory testing, edge cases etc. How devs can test better - looking beyond just happy path scenarios Key areas to focus on - error handling, accessibility, performance ( anything specific to your application)
but 1 to 10 doesn’t sound great