The Agile School

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

Personally I feel that all in the team should understand all the stories which are going into the sprint. As soon as one task is finished he/she should take the next task in the backlog rather working on the “pet” or “my” areas. I usually hire developers who are willing to test also. If someone cannot understand the work done by the team even after repeated training then it is the job of HR and other functional managers to weed out such people. Testers are intelligent people.  It doesn’t helps if they are doing monkey testing of application or writing long test cases which even they don’t refer. IMHO they should be the business domain experts. They should provide value to the customers and business with their domain knowledge. Many times I have seen testers asking the developers about the requirements.  They limit their testing to the knowledge acquired in such a way. More than just ensuring that the features developed is bug free the team should strive for excellence by...