Lessons Learned in Agile Special Tactics: Soa Projects Agile Testing

Succeeding in applying software development process requires continually learning and improving. These are a few lessons learned that are worth sharing:

  • Keep an eye on whether everyone is playing by the rules. Sometimes you need to make sure that other process participants are playing by the rules. Does the code being produced meet the design specifications? Are specifications complete? It’s no use having a group of suppliers sign up to a process, only to then go ahead and completely ignore the process. I’ve worked on a project where this has happened as the other supplier felt under pressure to say that they were following the process. They had a requirements team writing use cases and a design team working on design. At the same time, though, they had a large development team ploughing ahead, writing code before specifications were even in place. The net result was that the project nearly ground to a halt when they had to spend a lot of time reworking the solution, and solution quality took a hit as software was delivered to the test team late, which placed them under a lot of pressure.
  • Watch the defect count! One of the advantages of using iterations is that it allows you to learn from your mistakes. If iteration 1 testing has a 90% failure rate on its use case plays, it doesn’t help if iteration implementation is focusing all of its effort on releasing another set of use cases instead of addressing the current problems. Delivering loads of new use cases when the ones that you’ve already delivered are full of bugs is a strategy that is going to end in tears. While it might look like the team is making progress, having a big backlog of defects is just asking for trouble.
  • UAT is not QA. There is often a temptation to go ahead and start user acceptance testing(UAT) for a solution before QA has signed off that all the defects have been fixed. This is likely to cause delays in UAT as this phase of testing is not meant to root out defects in the code but rather to check that the solution does its job in the hands of test end users. Rather it would be better to arrange another time box to sort out the remaining defects before starting UAT.
  • Increased automation. It would be useful to make use of increased automation to check things such as whether the code matches the design or to check whether the design adheres to the design patterns.

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

Agile Testing Topics