1

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?

Shared Component Testing Scenario

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

3
  • I don't understand System A and System B. Are there other components involved? Because, based on this, System A and System B are identical in that they both include the same components. It seems unlikely that you would build two systems that have the same components, so there must be more to the picture and understanding how these two components actually fit into System A and System B is key. At this point, I don't see why you would need to do any coordination of testing between Team A and Team B. Jul 23 at 22:09
  • System A and System B are completely different applications but may be using the same two components. Example, maybe there's a logging component and an authentication component. These could be two different web applications dealing with different databases, etc. If you want to simplify it you could say System A is using Component Y developed by Team B. System B is using Component X developered by Team A. Jul 23 at 22:14
  • So there are many other components, which may or may not also be dependent on Component X and/or Component Y? I would suspect, for example, that if Component X was a logging component, it would be depended on quite widely within the system. Is that a fair assessment? Jul 24 at 1:03

1 Answer 1

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.