Final lessons Agile Testing

The lessons learned from this project so far include the following:

  • Deliver testable function as early as you can – With very short iterations(two weeks for us), it is imperative that development deliver testable function as early as they can to reduce last-minute integration and testing. A hard cutoff for integrating new function, leaving at least two days of testing(and defect fixing) time is crucial to getting a functional and tested driver for the end of the iteration.
  • Do not underestimate the time and effort required to develop and maintain an automation infrastructure– We had a complex,distributed,asynchronoussystem to test, which made choosing an automation framework very difficult aswe found there were few existing frameworks available that could help us. Weended up using STAF and STAX(available from,which have been flexible enough to do what we wanted. Even using these tools it took us fiveiterations before we got the infrastructure in place to be able to run an automated BVT and a further five iterations before we managed an automated multisystemFVT.
  • Communication is absolutely key to the success of iterations and the product– Make sure that you communicate with the developers to ensure that you understand what the product is supposed to do, reviewing the designs as soon as they are produced and before implementation starts. Challenge them if you have differing thoughts. Also ensure that you validate the requirements with what the stakeholders actually want by talking with them.
  • Test early and test of then– Testing as soon as you can is good:testing the developed code directly after the development team has coded it finds bugs early and while the developers still have the code they wrote fresh in their minds,makes finding the problems easier.Additionally,testing the small units of function that are developed makes the scope of what needs to be tested clearer. Getting early drops of testable function in an iteration is good in that it allows us to test earlier and eases off some of the pressure from the last few days of the iteration, but it can sometimes allow regressions to slip past if no automated regression tests are written.
  • Ensure the GUI is stable before using automated GUI test tools – It was decided not to attempt to perform automated GUI testing. Our understanding of the automated GUI testing tools was that they are useful only if the GUI is fairly stable.With a brand new product being developed from prototypes and adding new functions frequently, we decide not to spend time trying to automate the testing of the GUI. This has turned out to be a good thing in that it forces us to get real people looking at the GUI, trying out different things and finding usability and accessibility issues that would not have been discovered by automated tests.
  • Select tools in haste,repent at leisure– Take time to choose your tools.We changed some of our tools several times, and the cost of changing whatever tool you are using is wasted effort. Automation frameworks,change management system,defect tracking systems, design document repository and so forth–get it right at the start because it is difficult to change halfway through and has a high cost in time and effort. This may seem anti-agile to spend lots of time deciding things up front, but I believe that the cost of spending additional time up front to get things right is worth it.

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

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

Agile Testing Topics