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.
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.