Usually a QA is part of a squad or feature team together with developers, a PO, tech lead…
In more than one company I observe that it’s not the best thing for QA, here it’s why :
lack of objectivity in tests (it’s easier to be influenced)
devs tend to test less because the tester is right there and he’ll test everything
waste of time in a lot of meetings where the qa is not needed and he doesn’t need to be there
less time available for topics like automation
In my opinion things would work better if the QA is not part of the feature team, the need of a QA full time in a feature team is mainly a cognitive bias, but actually the ROI of the time spent in this way is not that good.
What do you think ? Any experience related to this topic ?
I get quick feedback on problems and test strategy
I know the developers and how they work and what they are like so that I can better predict where they are likely to make assumptions, thereby making it easier to find bugs
Communication loops are smaller and faster
Communication is easier and more accurate
I get to be in meetings so that I can test kickoffs, design discussions, and the documents associated with them, finding risks before the product is written and saving a fortune
I can advocate for problems
I can advocate for testing
I have more influence over the process
I can build a better working relationship with others
I can build confidence in others about my capability, skill and motives
I probably wouldn’t work for a company where I cannot work with the team building the thing I’m testing (assuming they’re all in the same building anyway).
I don’t have the data or the time to go chasing it to say if one or the other is objectively better, but I have found that the more agile an organization’s development process is, the more likely that testers will be working closely with the dev team during the whole development process.
I’ve worked on both sides of the divide, and personally I’ve found that being part of the meetings is a good thing, not a waste of time - it’s a lot easier on the entire team when missed requirements and invalid assumptions are caught before the code is written or early in the process. At the same time, when the developers know you’ll routinely check things like tab order, they’ll generally make sure they take care of those little things that add a sense of polish to their code (most of them don’t take long to do).
I’ve also encountered very few devs who tend not to test because they’ve got a tester right there - most of the devs I’ve worked with were more inclined to ask me what sorts of things I’d be concerned about.
It is possible to become less objective - I find that’s much more likely for me when I’m on my third or fourth time through the feature and running out of new ideas to work with. In the early days, I’m focusing more on working out where the new feature intersects with the application and how to test that those new edges don’t introduce new problems.
When it comes to automation, there’s never enough time. That could be because I’m a perfectionist, or it could be because there’s never enough time, period. If there’s good unit test and/or other lower level coverage and good exploratory testing work, UI level automation can often safely wait a while - not least because after users see the new feature working they often want the flow through the feature changed because while it does what they want, they way it does so isn’t intuitive or sensible to them (read up on cognitive differences between tech geeks and the general public - it’s interesting and kind of scary).
So yes, depending on the project and the way it’s working it can be better for the QA to stay out of the feature team, or it can be better for the QA to be in the thick of it. Personally, I prefer the latter.
This is tricky, if you have a top notch tester the team will be faster and more productive if the tester is embedded in the team. If the tester is average / below average. The team will benefit more from not having the tester in the team.
@jean-l While I see some risk that it can happen what you mentioned I see also problems with not being in the team.
Especial at automation I perceive many testers overdoing it, too much and with a lack of skills.
Developers can at least help to make that automation code better, teaching you how to develop.
And together you maybe come up with new ways of (semi-)automation you have not thought about. Happend to me.
How does this come? What are your experiences?
What was the bad influence?
I find my decisions about testing to be more well informed while being in a team. Because I have more information, context, better insight into the release schedule, shorter feedback loops, good relations to developers …
The only superior I accept is the project manager. My work is to inform him about the state of the product (reporting bugs is part of that).
If they think I should test something different, that the priorities and risks are different than I think, I accept that. I ask for that. No matter if I’m in the team or not.
I exchange with devs, they are a helpful source and often I decide on what to test based on what they said.
But if they want me to (not) test something, they have to convince me. They can not overrule me by force.
With all respect & I hope this can work as guide for you
I understand your points of view even if they are quite different to what I said.
I would agree with you if I was in a situation where working closely with devs would be so powerful and regression tests already cover > 90% of the things, but in my case the problem is that devs just tend to push and hope that everything is fine. In addition what has just been pushed usually works, the problem is that there are many side effects (regressions) happening in other part of the product.
That’s why I was thinking to spend less time testing new features like “when I push the yellow button I see a yellow light” that can actually be tested by devs and doesn’t require to be a senior QA with 10y experience + spending time on meetings where you have to estimate this Story in planning poker, listen to a lot of technical discussions in daily meetings and so on.
I think it’s important to be there at the beginning in order to be able share feedbacks and talk about the risks, but later in the sprint I see that the importance of being there decreases a lot.
Having experienced both ways on the same project and team, I’ll try to address each original point in explaining why I much prefer testers to be integrated with the developers:
Personally I haven’t seen this translate to a lack of objectivity. Rather, when the testers are working closely with developers, the advantage is being able to ask questions and understand the developer’s intent much earlier, and potentially starting on the testing before the feature is “done” (particularly any automated tests but also brainstorming in general what and how to test).
Again, if you’re working closely with developers and talking as the feature is being developed, I don’t think this is necessarily an issue because you can coordinate who’s testing what. As the only tester on my team, I do set some general expectations about what I’m testing versus the basics I expect the devs to have tested before handing me something and if that contract is violated, I won’t waste my time trying to do additional testing. I’ll hand it back and basically say “try again”. A common one is not running the existing automated tests on their branch before handing it to me–if I see existing tests failing that we didn’t expect to be invalidated by the change, that’s a good sign the dev didn’t run them or do enough of their own testing. Personally, I’ve experienced this behavior of devs cutting corners on their own testing more when testing was a separate team than when I’m working closely with them as part of the same team.
I suspect this is a symptom of a larger problem. If being part of a particular team automatically means “a lot of meetings”, I question the value of those meetings. In my team, we have meetings for sprint planning, backlog refinement, retro, and sprint review (one each every two weeks), and a short daily scrum, but other than that, whatever discussions need to happen are typically 2-3 people who are directly involved, not the entire team. If you’re not needed, don’t go to the meeting .
I’m not sure how being embedded in the dev team vs. being separate translates to less time available for certain kinds of testing? The team should still be able to prioritize the testing that makes sense, reduces risk, and adds value, regardless of the team structure. There isn’t enough detail in the question for me to know for sure, but I suspect this could be a symptom of trying to adhere too much to Big-A Agile (versus actually being “agile”), where all the work is expected to “fit” in a single sprint. If that’s the case, I highly recommend this recent article by Wayne Roseberry: Think of testing across sprints like Lego bricks | Wayne Roseberry, Providing Testing Solutions.
I agree with you 100%. In the ideal set up in software development lifecycle, QA must be independent and function as a separate team. The purpose of testing is to scrutinise the development code or the application and the value here cannot be achieved unless this level of independence is present. Testing is just one of the activities in QA. This approach of moving testing into feature team is more of a cost saving exercise and undermines the profession by damaging the prospects of growth.
The leadership in most IT departments do not understand the purpose of QA and view it more of a nice to have rather than something as important as the development activities themselves. What we have today is testing not QA and you cannot achieve anything with just testing. You must have a QA strategy for each type of software developed. Instead of just runnning on the bandwagon of new ideas, as leadership we should think about each approach correctly. I have seen a lot of failures in such instances and the leadership team tend to keep changing team structure post the failures.
In my experience, all models can work, given the right support and in the right context.
I personally prefer being homed in a team, with some scope for working on things across teams.
I’m a big fan of collaborative working, using pairing and ensembles where possible, including for testing work. I find this hugely beneficial for many reasons, and over time it builds towards a better culture of quality.
Overall I truly believe that the ultimate goal of testing, is to help build better software. And being embedded in a team and working collaboratively has given me the best chance of reaching this goal so far.
One step further, the end game isn’t to simply build good software, but to solve business and user problems. And taking any role that is involved in building the software, and solving the problem further away from the team responsible for delivering the solution, adds complexity and beings a greater chance of bottlenecks.
It sounds to me that the wish for separation is more a fix of problems in the team/company culture and collaboration.
I do not judge this as bad. Changing the culture is a demanding, long-term task and a quick-fix can be a separation.
Also I found being a tester in the team a first and influential step towards changing the culture. Once more next to the team I can influence it easier for better.
(not doing bad manipulation, but honest communication with people, explaining and carrying for problems and helping each other)
We often discuss where the “testing people” fit into the organisation – are they part of a delivery team or an enablement team independently of the delivery teams? I have used the Team Topologies model (a model of organizing software teams for FLOW) to articulate the where the testers fit in:
Yes it’s right.
What I observe is that devs tend to feel not very responsible of quality because “it’s QA staff”, in addition there’s a QA in the team so it would not be his problem.
Pair testing and collaborating closely can be great, I agree, but probably in some contexts where things already work better.
At least in my case the result is that we spend most of the time doing silly test and have less time for tasks with added value.
What I observe is that devs tend to feel not very responsible of quality because “it’s QA staff”, in addition there’s a QA in the team so it would not be his problem.
That sounds like the devs are acting like children and management gave them their own kids table. I’m sorry that this is your experience, and I know that your efforts to do good work must suffer because of it. I can only imagine the frustration it causes.
I consider a team to be a group of people performing their own tasks to work towards some shared goal. If people are working against each others goals then that is not a team. It only works if it has the space and permission to do so.
That being said I could also say that testers being integrated with a team only works if the building isn’t on fire.
I think testers should be part of a team, provided that the company can actually provide one.
