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

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?

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.

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.

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!

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.

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

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

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.

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.