What if D = A + B + C? Agile Testing

Now imagine one project, D, where all three issues combine, since this was the reality. We need to get the picture of how they interrelate.

The agile part felt like a project within a project. Despite the issues mentioned earlier there was good visibility of what was happening. The development work was generally successful within the sprints, as shown by low programming and design error rates found in later stages of testing. JUnit was used with considerable refactoring and code/unit testing. (As an aside, some of the development stories took significantly longer than expected and we suspect this was because the refactoring element was significantly underestimated). Agile worked well from a verificationviewpoint. Developers were “building the software correctly.” This part felt under control.

In contrast the rest of the project felt less and less under control as time progressed. Errors and faults injected early into the project were surfacing during late stages of test execution. User acceptance testing and integration-in-the-large testing were combined. The idea was that as individual interfaces were released from a Sprint cycle they were put into user/integration test immediately. The lack of user involvement in the sprints led to simple yet high-impact defects getting through to test execution. Test runs had to be repeated many times but they only gave a slow increase in software reliability. In this respect the project did not work well from a validation viewpoint. It was not good at “building the correct software.”

The critical issue was the lack of risk management. There was no risk register, let alone a process for populating it and identifying risk mitigation actions. Without a proper understanding of business, project, and product risks, how do you decide the appropriate techniques to manage, plan, develop, and test a system? How do you apply a QMS? How do you know if agile will work for you, and if so, which agile? Should it be an ultralight software factory run by Scrum or a heavy-duty project following ICONIX?Or should it be a combination of agile and traditional techniques?

What was not well understood was how Scrum would mitigate risks in this project, and areas where it would not.It reinforces the received wisdom that without a risk analysis your project will adopt a fatalistic approach. The North American saying is, “This project is like a log floating down a river with a thousand ants on it, and each of them thinks they’re steering it.”

What could have been the solution? In another institution the internal and external development parts of a new trading system were treated as two separate projects. Internal development was run as an incremental project. Instead of stories we had many use cases, but with increments measured in weeks and daily meetings it was not that different from Scrum. We developed burndown charts for testing, showing the velocity at which we could test and close bug fixes. An experienced bond trader was assigned to the team to act as a user, keeping the user view close to the developers and to act as an oracle for the testers. The external integration was managed separately with different business groups providing the testers to specifyand run the tests once the trading platform had been delivered. The system went live on its planned deadline. But then, this project had a risk register, as did individual groups such as the testers.



Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics