Here is a scenario. Team1 has made changes to it’s own code which is also used by Team2, Team3 etc. Are there any situations in which it is okay to expect Team1 to test the impact of their changes on other teams? Have any of you ever had to test other teams code in such a scenario?
Argument for testing other teams code - If other teams have fast and reliable automated smoke tests to test their dependencies on Team1, then Team1 can at least run these tests after updating code. That way, they can catch bugs sooner. The other teams can do deeper testing on their own after smoke tests pass.
Argument against testing other teams code - If other teams have unreliable automated tests or manual tests which require too much effort and/or domain knowledge, then Team1 can let the other teams do all the testing.
Are there any situations in which it is okay to expect Team1 to test the impact of their changes on other teams?
Isn’t that was is testing about? Testing how your changes impact the client.
How can you test without that?
Or development as whole? How does someone develop without having an idea of the intended impact?
Sure, this is not completely black and white. Some things are up to be discussed. I just mean the over direction.
Especial company internally you should be able to finde a shared understanding and agreement.
I had this with 2 teams. One developed core functions and the others integrated them at the customers.
Everyone carried out different tests (not just automated ones).
At the beginnen less testing was done be the first team and more by the second.
Especial for improving the product handed over from the first to second I was moved from the second to the first team.
We now test more & better so the second team has less to worry.
This was a decision in our business unit / department, partly by our collective manager.
The second team is still finden some bugs in the product, but way less than before.
I suggest you:
Bring this topic up at your team and/or manager to find a holistic solutions. No matter what any org chart says.
Finally you are all in the same company / department.
I suspect if that’s a question, then the concept of team is broken in the company culture. The entire company is really a big mega-team. The fact that 1/3 of that mega- team is entirely tied up with taking money off of people is a sideshow distraction, but a company, is a team. If the company fails, the teams inside it fail and visa versa. What you don’t know is what kills you ultimately, and I can see how teams that struggle to test can get a bit of help from outside teams whose perspective is not fatigued by junk testing tools perhaps, or by plain and simple some other cause that distracts their team. Always be diplomatic.
Companies that get so tied up and busy that they fail to rotate members between the teams (traveling or secondments) are vulnerable to not only software defects, but to security threats too. I just realize I have echoed Sebastian’s input too.
If the product falls over in public, excuses of "no team tests another team’s output’ will not cut it with Management. Is no-one doing integration testing? Is no-one doing end-to-end tests? Is there no pre-release testing of the finished product?
If your code is affected by third parties, there is a boundary problem. I would take a look at your architecture before focusing on deep testing and bug fixing.