Lessons from agile waterfall approach Agile Testing

The biggest lesson learned through the BLA Ltd project was that the in-house team had actually worked in a pseudo-agile way(we just didn’t realize it at the time):

  • We co-located development and test resources.
  • The system testers tested code as it was built(hence the request for an additional week in development).
  • Unit tests were automated using JRun.
  • Daily short progress meetings were held throughout the delivery to ensure everything was on target.
  • The V-model principles of early test design significantly enhanced our approach to delivery.
  • All documentation was delivered with the initial drop of code.

Webfrontendsrus,however,appeared to have used agile as an excuse to adopt ad hoc and unstructured methods:

  • None of their team had identified roles;developers did their own unit testing and the system testing(no trained system testers were used).
  • No documentation was delivered.
  • Code was rewritten on the fly,with no knowledge of the risk or impact of the change.
  • Resources were employed without the requisite development skills(in effect to make up the numbers required).

BLA Ltd has now adopted a far stronger supplier management position regarding the quality of third-party software, defining the required development approach(and building in audits to ensure they are followed), demanding access to review system tests, and trying(as much as contracts will allow) to work in partnership with third parties.

While they still use the waterfall approach on the older maintenance releases, BLA Ltd has successfully implemented projects using Scrum as their prescribed delivery method for all new developments.



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