Project C: How to Be Agile and Operate at CMM Level 1 Agile Testing

In the early days of this project the qualitymanagement system(QMS)included reviews of requirements, specifications, and other key documents with users and developers. Because this financial system integrated with many others, the analysis work was complex. General progress was slow and difficult and the project moved to an agile footing to create a more manageable project. During this transition, basic quality disciplines were no longer enforced;it was left to individuals to decide how they implemented the QMS. In project B, I described how agile should address business risks through close involvement of users. What happened was a slow degradation of quality in the analysis model as users were less involved. This happened in two reas.

First, existing specifications were amended without proper review. This made it difficult to examine a document and determine if it was current and trustworthy. Second, new documents were created with minimal desk-checking. In some instances there was no information on author and history, so they were particularly untrustworthy–we found they contained serious errors. As a consequence, testing was compromised, particularly test execution. Unreviewed documents had been turned into code that did not do what the user wanted. This gets you into the protracted cycle of errors created during early analysis not being found until late acceptance testing.

This relaxation of quality disciplines showed itself in some areas of development outside of the agile part of the project. Developers considered it reasonable to fix bugs in code but with minimal testing, leaving it to systems and integration tests to find them, even if it compromised those activities. Consequently, later stages of testing found errors that could have been removed much earlier had the QMS remained in operation.

Here are two examples. A router interface specification was written by an analyst, not reviewed with users, and not even placed under control of the project repository. It was given to developers who wrote the interface code and the analyst signed off their work. When the software reached integration/user acceptance testing, it failed immediately with a simple and obvious error that caused every transaction to fail. The users were unimpressed. A cursory inspection found more fatal errors in the specification.

The second example is where bugs were fixed in a router interface. The fix was tested and declared OK, which it was. However, when the developers declared the interface ready for acceptance testing they had not tested that the router was configured to the trading platform as opposed to their development environment. The router failed to pick up all transactions during an acceptance test run and took that external system out of testing for over a week. When asked about this, the developers did not consider it part of their quality responsibility to test whether the configuration was set correctly; this was for the testers to do.

In summary we had a project where individuals applied their own ideas of quality control. Some ideas were good, many were not. This created a lot of uncertainty and unpredictability. We were not in the repeatable environment of Capability Maturity Model (CMM) level 2, let alone the confident environment of knowing how to tailor our processes to new demands, CMM level . It felt like CMM level 1; many avoidable problems appeared through poor prevention and big gaps in the QMS, accompanied with the recriminations and closing of ranks that destroy team spirit.



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