QA in a Sprint

Cross-skilling is the best way, so that any Development Team member (whether developer or tester) can go to where the work is and immediately stop bottlenecks from arising.

If developers and testers cannot be cross-skilled, at least make sure the developers are. Development should not be constrained to work silos as this will exasperate the problem.

It may be possible and advisable to train developers in test script execution (if not authoring) since the actual running of tests is often the choke point. Having small PBI's also helps because it reduces the risk of a serious bottleneck, and allows items to be staggered through development so they enter QA in a reasonably even flow.

Although there are ways to alleviate the QA bottleneck problem, it will remain a risk until
the team is fully cross-trained. A separate QA function is often symptomatic of waterscrumfall...a stage gated organization pretending to be agile. It can also imply weak product ownership and a questionable understanding of what "Done" means, in so far as PO's may not take acceptance seriously or view it as being their responsibility.

Focus on improving Unit Testing (including Automation) and later extending the Automation to Integration Testing will help each Developer deliver better quality code and reduce the need for adding additional “QA only” type of team members. The Development Team owns the “Quality” and QA should not be the one “signing-off”.

Moving towards creating an environment aligned to Continuous Integration/Deployment/Delivery and practices from areas in XP and (A)TDD are useful.

Developers may consider taking the PSD (or CSD) assessments as most of the basic skills required would be covered.

https://www.scrum.org/Courses/Professional-Scrum-Developer/PSD-Subject-…

--Bhuvan.

Deriving BDD scripts from the acceptance criteria is another approach that lends itself well to automation, and it can be done up-front in a test driven manner by developers.

The barrier to developer-owned QA is usually more political than technical. Testers often regard their trade as a discipline and role in its own right, and one that must be kept separate from development. Defects that are uncovered by non scripted exploratory tests are often used to evidence the value of this. From an agile perspective any such defects would indicate a quality gap and a questionable Definition of Done...not the justification of a skill silo that can result in bottlenecks and the batching of work. This political barrier is something to be challenged by cross training and a rigorously scripted, test-first approach to whatever is meant by words like "exploration".

Hi,

In Scrum everyone is a developer, including tester and everyone is responsible for Quality Assurance, not only programmer because the development team is cross-functional.

Here is a detailed explanation of why everyone in development team is a developer: http://blog.leanagile.in/post/72951466225/who-are-the-scrum-developers

My team lead, unfortunately, is very vocal about how developers shouldn't do testing. The rest of the team would not be averse to pitching in as necessary but are hesitant to voice this at times. That said, they do pitch in when necessary but the prevailing atmosphere is one of discontent. Also, they tend to pull in more stories in the middle of the sprint if the development work seems to be winding up. It doesn't help that the line manager the developers report to totally support the thinking that developers should under no circumstances be made to do QA.

It sounds as though your QA bottleneck will only be removed once the team become self-organizing. Where is your Scrum Master in this? He or she should be responsible for how Scrum is implemented and for how the team is coached. Why do a "team lead" and a "line manager" hold sway over what the development team do in their sprint? Neither of those are Scrum roles.

The organization is relatively new to scrum. Yes, there is line management, there is a team lead within each team whose task is to supposedly mentor the team and take care of some administrative tasks. Given the constraints, I'm working within, I'm trying to get the team to see that pair programming to knock off stories faster would help get it quicker to QA instead of each developer picking one story and finishing it close to the end of the sprint and overloading the tester. Also instead of bringing new stories into the sprint, closer to the end, to pick up on technical documentation, backlog refinement among the developers and of course, testing. In the meantime, I am working with the other scrum masters to bring about more organizational change but it's a slow process. Any other ideas?

Working with other Scrum Masters is fine at an operational level. However, for agile transformation this must be connected to an organizational strategy for improvement. In other words, there must be executive sponsorship for genuine change and not mere lip service to it. Without that, cultural inertia is likely to prevail. Is there such a sponsor in your case?

The management does seem to want to move toward a completely agile environment but it's a slow painful process.