The Agile School

Agile teams work in iterations. During this period, they are supposed to work on product increments which can be “delivered” at the end of iteration. But how you know that the correct product was delivered? Many teams have different kinds of acceptance criteria and Definition of Done (DoD). But in many cases, this “done” is not the real “done” there might be some testing pending, some integration or review pending or anything else which prevents the actual use of the product increment. Many of these teams will need additional iterations to finish hardening their products. Many teams will implement different types of “gates” or approval steps to move to next stage. The free flow of product will be interrupted. They might end up doing mini waterfall within their agile process. Many don’t even realize this. This results in poor quality and requires additional effort to “harden” the product. Potentially Shippable Product increment The acceptance criteria and DoD should be modified...

User Acceptance when done properly is very effective.  But in most cases i have seen companies taking this to the extreme especially in companies who were following traditional waterfall process People are used to do certain things in certain way for long. It is difficult for them to change. Moreover there is a trust factor. They don't (or wont) trust the quality of the software unless they verify it. The result is complex long UAT period where someone from "UAT testing" team as to test  and approve before the product can be released to production. They even refuse to share their test cases with others. And in many cases i have seen that this testing might not find real bugs or is even related to user acceptance. This is the remnant of old way of doing things and this should change in modern Agile  DevOps delivery. Ideally the UAT period should be very small and if possible eliminate this stage completely. The Agile Coaches and scrum masters will have to "train...

In traditional software development model QA/testers were actively involved in only certain phases of the project. After development finishes the coding the entire project was handed over to QA. In many cases QA and developer wouldn’t even know each other. All the communication will be through email or bug tracking system. I remember one instance when my project manager relocated the entire QA team to another building!!! He didn’t want the QA and development team to communicate face to face. We had different competency centers for QA and development teams with different career objectives and career ladder.   The QA team had a separate identity, a feeling of ownership over an entire phase of product. They were called the gatekeepers of quality. Don’t fear the change But in scrum apart from the sprint cycles there are no definite phases. In scrum there is a big change in the way team operates and interacts. In scrum there is no differentiation between a QA and developer. ...

The NFR’s and technical requirements should be part of the user story. These can be added as constraints to the story or along with the definition of “done”. Most of these NFR’s can be tested with unit test framework or automated test scripts. Sometimes the process cannot be tested directly. Suppose software requires triple encryption of bank transactions or such things then it will be very difficult to check the state in between. You will have to test the results to verify the process. The ticket generation or the account balance after the transaction will give a correct picture. Performance testing can be integrated with Continuous integrations build or nightly builds.