🐛 In the beginning there was a feature…

A long time ago, there was a team (let’s call it a team one for the purposes of this story) working on a certain mobile application. This product was created by many teams that took responsibility for specific functionalities. Team one had to update one of the libraries. This change may have affected the operation of the product on both iOS and Android platforms.

The QA team made every effort to ensure that the risk of a failure caused by this change was as low as possible. An action strategy and documentation of the test results were developed. Unfortunately, outdated documentation, lack of test data and test scenarios for other teams stood in the way of “success”.

After deploying the change to production, users reported a failure that caused the customer thousands of dollars in losses. This failure was quickly removed, but the losses were huge, as was the feeling of defeat for team one. The reason for the gap in the QA team’s tests was the lack of documentation and tests for one of the functionalities of the mobile application As a result, this functionality was completely omitted from testing and the gap went undiscovered.

💥 Conclusions

Teams may be dissolved, transferred or separated. If they don’t care about creating and maintaining documentation (in this case, test plans with test data), it’s a recipe for failure. This area will stop being tested as soon as the team responsible for its creation is transferred/disbanded.

One of the many problems when working on large and complex projects may be the lack of division of responsibility for specific product areas. The responsibility matrix and contact persons should be constantly updated through the leads/managers.

🚢 To sum up

In our work, everything is a team game. When one player drops out of the game, another one replaces him. Sometimes there is no reserve player, then all team members join forces to fill the gap. When this doesn’t happen, it’s a simple recipe for disaster.