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.
Agile Testing Related Interview Questions
|ETL Testing Interview Questions||Manual Testing Interview Questions|
|Selenium Interview Questions||Database Testing Interview Questions|
|Automation Testing Interview Questions||Software testing Interview Questions|
|Performance Testing Interview Questions||Embedded Testing Interview Questions|
|A/B Testing Interview Questions||Hadoop Testing Interview Questions|
Agile Testing Tutorial
Old-school Development And Testing
Agile Development And Testing
From Waterfall To Evolutionary Development And Test
How To Test A System That Is Never Finished
Implementing An Agile Testing Approach
Agile Testing In A Remote Or Virtual Desktop Environment
Testing A Derivatives Trading System In An Uncooperative Environment
A Mixed Approach To System Development And Testing: Parallel Agile And Waterfall Approach Streams Within A Single Project
Agile Migration And Testing Of A Large-scale Financial System
Agile Testing With Mock Objects: A Cast-based Approach
Agile Testing – Learning From Your Own Mistakes
Agile: The Emperor’s New Test Plan?
The Power Of Continuous Integration Builds And Agile Deve- Lopment
The Payoffs And Perils Of Offshored Agile Projects
The Basic Rules Of Quality And Management Still Apply To Agile
Test-infecting A Development Team
Agile Success Through Test Automation: An Extreme Approach
Talking, Saying, And Listening: Communication In Agile Teams
Very-small-scale Agile Development And Testing Of A Wiki
Agile Special Tactics: Soa Projects
The Agile Test-driven Methodology Experiment
When Is A Scrum Not A Scrum?
Analysis Of The Case Studies
My Agile Process
The Roll-out And Adoption Of My Agile Process
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.