Most companies are using the agile software development approach in building great software. While agile has significant benefits, there are some dangerous pitfalls.
Agile Pitfall #1: agile has a lack of integrated software testing
Lack of integrated software testing is especially dangerous when companies have multiple products and are running multiple agile teams. The agile teams are often heads down and focused on their product only, and don’t have the time, energy or effort to understand how the systems interact with each other and what potential pitfalls are downstream. Most systems have dependencies with each other in terms of data or interfaces. Product teams today have subject matter development and testing experience, but may not understand other systems and how those interactions. If there are understood impacts, the responsibility usually is handed over to the team who is responsible for that product. It usually occurs with little to no planning, and typically little warning is done in advance. Something to the effect of: “hey can you perform some regression test this feature real quick and make sure it works, and provide me a sign-off before the end of the day since we are releasing into production tomorrow?” If you are in testing and a part of an agile team you understand that agile has a lack of integrated software testing.
Agile software development works great for the most part, but there are some pitfalls that will happen. Agile works well with a single product because there is essentially no integration points, however, most enterprise systems are going to have integrations with either other internal applications or third party applications. It is not sufficient enough to assume that is it is the responsibility of another product or team to ensure the quality is going to work from an end to end perspective. You certainly don’t want to have your business partners or end customers find out that something does not work properly.
I currently manage an agile team and my direction to them is to get the necessary access to all the interfacing systems and run the test to make sure it works properly. Our application is the upstream system, so if something goes wrong, we will be the group that will be held accountable, regardless if it is our system. Sure, it takes additional time and effort to perform that testing, but as long as we account for the work in the sprint, we are covered. I would much prefer to test it ourselves and be sure rather than suffer the consequences.