Skip to main content

How to perform QA in agile scrum sprints? How does testing happens when developers are developing on last day of sprint?

Last post 06:16 pm July 16, 2020 by Jack Daniel Morilla
8 replies
02:25 am June 8, 2020

Looking to adapt agile scrum for a small software development team. Needs some clarification on the overall process. If we decide to go with 2 weeks sprint 10 working days. 8 hours per day per resource

For designer we plan to keep them one sprint ahead so developers have everything they need from design side when they start their sprint. Now their time is divided between R&D, Meetings, Development and Unit testing. Roughly 5-6 hours daily for development. and rest for meetings and unit testing as needed.

How does QA operates? Is is necessary to have nightly builds and pass that on to QA? if not whats recommended? How are bugs handled? should we set aside time withing the same sprint for bugs or handle them in next sprint? Now if developers are developing daily, how does testing happens for stuff developed on the last day of sprint or no development should happen on last day? does testing carry over to next sprint? How to do the release plan? it is usual practice to release right after sprint or release work ahead 1-2 sprints? Where does documentation fits in? Is it part of the sprint or next sprint for items developed and tested in previous sprint?

Initial thoughts are to design 1-2 sprint ahead, develop and test within sprint, carry over untested stuff (not sure how to track the sprint KPI then), take next sprint to test and do documentation and then do the release once all ready? Is this right approach?


07:14 pm June 8, 2020

Have you read the Scrum Guide? What are your thoughts about limiting work-in-progress, so work is planned, designed, tested, and brought to release standard each and every Sprint?


07:15 pm June 8, 2020

Do you specifically need QA to be able to deliver something that works? Or would it suffice that some team members would have QA skills needed to assure the right quality of the increment?

Also from a product owner/economic perspective it might be good to have a good look at how the design works together with doing it 1-2 sprints ahead. Look into Professional Scrum with UX for instance.

I understand that this might be a annoying answer, but you'll learn so much more if you look into these topics without getting an answer from this forum. Not in the last place because this situation is much more of a consultancy kind of thing as there is not a single simple answer to your case.


09:24 pm June 8, 2020

There's no one way for QA to operate.

For independent quality assurance teams, I've had the most success moving them outside of the context of a Sprint. In this situation, the Development Team is responsible for ensuring that the work is of sufficient quality. At the end of the Sprint, the Product Owner can make the decision on if the work is to be released to independent QA. If it is released, they can work independently to perform formal verification and produce the associated documentation per their processes. Ideally, this is a formality. The independent QA process exists to reduce risks or to satisfy compliance requirements and they do not often find defects. When they do find defects, they tend to be minor and the release can go forward with known issues that can be prioritized for the Development Team to correct in an upcoming Sprint.

If you don't need independent quality assurance, then the Development Team is responsible for everything. You may have a QA specialist, but they reside on the Development Team and help the team design test cases, execute manual tests, perform exploratory tests, automate tests, and so on. In this case, the Development Team is responsible for planning their Sprint in a way that lets them get the work to Done within the Sprint's timebox. Work that is not done is handled like any other work - it goes back on the Product Backlog and is evaluated for upcoming Sprints.

In both cases, the Definition of Done should reflect what the expectation is for individual work items as well as the Increment at the end of the Sprint.

Documentation fits in much like QA. It can be done by an independent team after the Sprint or by the Development Team within a Sprint. Once again, the Definition of Done is used to define the expectations and aid in Sprint Planning activities.


09:40 pm June 8, 2020

Thanks everyone for your responses.

WRT the documentation, I have asked bcoz no scrum documentation clearly specifies this process at least I did not came across one yet. As for limiting WIP it came back to the same question if any development should happen on last day or not to accommodate QA and documentation reducing the Sprint time.

 

@Thomas,

So in my case the QA is in-house and considered part of the engineering team. I cannot expect my developers to do that QA but I can have dedicated QA resources within the sprint to perform QA tasks. So what you are suggesting that if any of the User Stories are not completed (tested/documented) by end of the sprint we move them back to the product backlog. Final question, so if we continue development till the last day of the sprint we will always have incomplete user stories at the end that will go back to product backlog or handled on a rolling basis!

 

 

 

 


12:57 am June 9, 2020

So in my case the QA is in-house and considered part of the engineering team. I cannot expect my developers to do that QA but I can have dedicated QA resources within the sprint to perform QA tasks. So what you are suggesting that if any of the User Stories are not completed (tested/documented) by end of the sprint we move them back to the product backlog. Final question, so if we continue development till the last day of the sprint we will always have incomplete user stories at the end that will go back to product backlog or handled on a rolling basis!

What you're describing is not consistent with Scrum. It appears that your Development Team has sub-teams, one of which is responsible for development and another responsible for QA. This is going to make planning Sprints difficult since you're effectively planning two sets of work at once, and a delay in one is going to ripple to others.

I'd want to know why you cannot expect developers to do QA.


08:11 am June 9, 2020

Maybe take a look into what you define as "team". 

And can we please move away from calling people resources?:)


04:44 pm June 9, 2020

You keep coming back to how to deal with testing something when the developers are finishing it on the last day of the Sprint.  This is not going to be the answer you want but to deal with that try having developers not writing code on the last day of the Sprint. Quit trying to justify the action of developers that can not plan their work appropriately and solve the actual problem. 

 I have asked bcoz no scrum documentation clearly specifies this process at least I did not came across one yet.

That is because Scrum is not a process.  Scrum is a framework that allows a team to work together to identify and solve opportunities. Those opportunities can be product enhancements or team cohesion.  It is a framework that provides a set of guiding principles, roles, events and artifacts that have been proven to help teams self-organize to be efficient and effective. Scrum is not going to give you a step-by-step list of things to do when every possible situation arises. The team has to be able to identify that there is an issue and work to resolve it together. 

The "process" you are trying to find documented is waterfall so you are looking in the wrong places.  You are looking for a process where work is passed between different groups of people/teams so that their work can be done in isolation from all others. Scrum, and agile in general, is about incrementally doing all work needed at the time the work is needed and is most efficient to accomplish.

This is the opening paragraph from the Scrum Guide section that describes the Scrum Team:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.

Notice there is no mention of a team of developers and another team of testers. There is only mention of a team of cross functional indviduals that are capable of doing all the work needed to accomplish the goals of the Scrum Team. 

You will not find what you are looking for in Scrum.  You can use some of the principles, events, roles and artifacts in what ever process you decide to do and find benefits.  But as the Scrum Guide says in the Closing Notes section:

Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.


06:16 pm July 16, 2020

These are my input about doing QA work in a Scrum Sprints:

- While Dev Team are working on the Potential Shippable Product.

- Testers will do Test Planning in parallel. (Ensuring that test planning is completed prior executing the scripts)

- Everytime there is a User Story that has been completed (means done Unit Test by Dev.)

- Testers will verify it, If bugs found during the testing, testers will create a task in jira/TFS and assign to the developer.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.