Testing components between software teams

Question

I've recently encountered this scenario in my exam preparation for a certification and I'm trying to understand how to coordinate testing of shared components across multiple software teams.

Team A is developing System A, which includes two components, X and Y. X depends on Y. Team A developed component X.

Team B is developing System B, which also includes the same two components, X and Y. X depends on Y. Team B developed component Y.

How should the testing of all this be coordinated?

Some of the possible ways were:

• Team A tests component Y and Team B tests component X concurrently. Another words, each team is testing the other team's component at the same time. This is a type of asynchronous process.
• Team B tests component Y first, then after that passes, Team A tests component X because X depends on Y. This is a type of synchronous process.
• Both teams collaborately work together testing the two components regardless of who developed it.

I am not a tester. I'm a developer. I don't coordinate testing activities. I've read that the old school method was to test synchronously and in isolation. So Y would be tested before X because X depends on Y. But it was shown this wasn't a good use of resources. A more modern approach has been to collaborate between teams.

Which one of these three scenarios seems best and is there a better approach than what I've listed?

I'm now referencing this article, Enabling Collaborative Testing across Shared Components

Distribute test effort and share results for common components to improve test quality. More specifically, when two or more component-based systems use at least one common component, developers ofthe systems can collaborate in the testing of the common component. i) Improve the quality of compatibility testing of component-based systems; and ii) boost the efficiency of testing software system configurations. The goal of this research is to develop automated collaborative testing theories and tools for individual developers of shared software components, so that their testing practice can be more efficient

Answer 1

Without knowing what exam/certification you are preparing for, I can't say what that certification body would deem to be the correct answer, but I can tell you how I have approached this scenario in the past, with positive results. This approach works equally well for various kinds of dependencies, such as direct dependencies where you include libraries or frameworks into your system or cases where the dependency is realized by interacting with a remote process.

You should not have to coordinate testing between Team A and Team B as they go about building System A and System B.

When a team is building a reusable component, that team takes responsibility for building and testing that component. This means that when Team A built Component X and when Team B built Component Y, they were able to test the component against some kind of requirements and demonstrate that it satisfies a need. When Team A builds System A and Team B builds System B, they should, generally, be able to assume that their included components work.

As a brief aside, when working in certain regulated environments, you may not be able to simply assume that the system works. Even for internally developed reusable components, you may need to determine the assurance level that the component was built to and that it meets the minimum required assurance level for the system that you are including it in. For any reuse, you may need to do additional work to ensure that it meets the requirements for inclusion.

When building System A and System B, Team A and Team B do not need to test Component Y or Component X, respectively, since they are already tested. What they need to test is to see if the behavior and performance of their system is correct, regardless of the implementation of these components. That is, these components can be black boxes in the context of the broader system.

If, when testing System A or System B, Team A or Team B find a defect in the component, they would have to follow the development methodology of Component Y or Component X to track that. Depending on the impact, they may also have to implement workarounds for the defect to ensure that the system they are building meets requirements. For internally developed reusable components, some organizations embrace the idea of inner source - applying similar techniques used by open source projects to their internal development projects. Other organizations may have stronger ownership and require even internal developers to submit bug reports which will be triaged and handled by the owning team. There is no right or wrong answer to how to manage feature requests or bug reports with shared components.

To understand what this looks like, you would need to better understand where the shared components are in their life cycle. If the reusable components are being actively built and developed, it could look like current testing and frequent releases of new builds. However, if the reusable components are stable, there could be little active development and new releases could be triggered based on the availability of the owning team (or the use of inner source to allow external teams to contribute patches and new features).