My company has several products on the market, developed in multiple offices in Europe and the US, which use the same common library. This common library wraps up a lot of industry-specific details, as well as adds some enhanced user controls, extension methods, math bits, etc.
Problems arise when QA comes back with a bug or the product owner for one of the products wants a change, and that bug or change requires changes to the code in the shared library. Because it is a change to a library used by all of our products, the change can have far reaching effects. The defect / bug report / change request is typically placed in the product backlog for the "original" product – that is, the product being tested by QA or owned by the PO requesting the change. This means that there is very little visibility in the other products for these changes, and things may break (very obviously with compile-time errors or more subtly with different run-time behavior) when the library is updated in those other products. QA for the other products may see the changes as regression failures.
The library is fairly mature at this point, so most of the changes being made are the result of bugfixes. Changes are submitted via a pull request, where a representative from each of the regional offices can review it (though only 1 needs to approve it); known high-impact changes are typically communicated over email, but may be forgotten by the time development resumes on a given project.
How can I manage a library like this, to ensure a good visibility among QA product owner, and the Developers?
Best Answer
Based on your description, the common library appears to be a collection of business functionality and utilities common to many of your projects. Regressions caused by one product's modifications may not be immediately visible in the other products.
Some core recommendations are:
Versioning
As you mention, the library is pretty stable. Versioning this library, if you haven't already, is the first step to preventing side-effects. Once released, versioned artifacts are assumed to be immutable.
Each consuming project should lock to a known-good version of the library. QA only has to worry about breaking changes when they choose to update to a newer library version. At this point, they should be running full regression testing anyway.
Semantic versioning (major-minor-patch) is a compatibility-based versioning scheme that might apply in your case. Library versions can be easily managed through artifact-management tools such as NuGet. Source code can be maintained using branches, tags or similar mechanisms.
Release Notes: With versioning, you have the additional advantage of release notes. Each version can describe the bug fixes and enhancements that went into that release. This makes it more visible to product owners, developers and QA, so they can make informed decisions.
Decomposition
Based on historical data, you might have a good idea about which areas of the library have the most changes or churn. You might also have fairly independent areas of functionality within the same library.
It might be a good idea to separate these areas into independent libraries and modules, each with their own versions and locked dependency versions. This helps to reduce the impact of a version upgrade and isolate ripple effects to a more defined area.
Product owners can now track which sub-modules need the most attention, and would be able to create a dedicated team to manage or QA those specific areas, if necessary.
Unit tests and e2e tests
Define your "units" of functionality. In most utilities, the unit is a single class or a single function. In some cases, it might be a module.
Design unit tests to cover individual functionality. Use the 80-20 rule to decide which units need the most tests. In addition, design end-to-end tests as necessary, mocking out sample library consumers and testing the expected behavior.
This will be the first line of defense, and should alert developers that they are making incompatible changes and need to update the version.