I am a QA/Test manager in my organization and until today I verified the quality of the software (tests written and executed and bugs fixed). Who will verify this in Scrum? How do I know that the team wrote and executed all the right tests? On the other hand I'm afraid that if I continue to do the verification the team will not feel empowered enough. But I need some verification process that "Done" is indeed "Done". What do you suggest?
One major idea in Scrum is that the team should agree on a "definition of done". Ideally, this is something like a set of objective criteria that anyone can verify by going through a checklist.
But to reduce the chance of something slipping through, it makes perfect sense to have a rule that verifying "done" most be performed by someone other than the person who implemented an item - or a designated QA guy like you (but that risks making you a bottleneck).
If in doubt, discuss is with the team and the Scrum Master and decide together.
I think there is an implicit assumption in the question. There is a difference between "accepted", when a Product Owner declares a backlog item or task has satisfied the Product Owner, and "done" meaning all work associated with the backlog item is complete.
However, there is regularly more to a task than that visible to the Product Owner, usually someone semi-technical at best, including (automated and manual) testing, documentation and review. The Product Owner is rarely in a position to know the technical aspects, let alone whether they are completed.
Therefore, it is ultimately up the team to determine what "done" means. The organization may have standards and different stakeholders will have their own requirements. The scrum master or relevant managers usually are responsible for collating and enforcing the list.
In your example, as the QA/Test manager, you are the one who says whether tests are complete. However, you may not be the best person to say whether the code has been reviewed, security requirements are met, the product is internationalized, documentation is complete or whatever else constitutes "done".
The only concept of "done" is whether or not a story as a whole is completed. The team should have created a definition of done that says when they feel a story is finished or not. This will typically include things such as "code has been reviewed", "nightly tests have been run", "all acceptance criteria have been met", etc. When these things have been accomplished, the team can feel confident they've done everything expected of them to finish a story.
During a sprint, if you're trying to determine if one of those items in the definition of done has been accomplished, just ask. Scrum and agile is all about open communication. If you are part of the team, ask your teammates if anyone has written the tests, or run them, or created the nightly job, etc. If you are a stakeholder, ask the scrum master.
If you sit outside the team but still must review the tests, have the team add "tests must be reviewed by user user3251930" as part of the definition of done. If that's what it takes for a story to be done, be honest about it and make it part of the process. The whole point of the "definition of done" is so that the team can know with certainty that they have done what is required to deliver quality software. If part of that is an external review, so be it.
Ultimately, it is the product owner who signs off on a particular story, so at the end of the day he or she has the final decision as to whether a story as a whole is done or not.
First Question you should ask yourself
Are you the Scrum Master? if yes.
In scrum processes are controlled and managed by the Scrum Master.
How do you do it:
In the requirement phase you can use the user stories for each there is a test that needs to be verified.
In each Sprint The work items are pulled from the product backlog and directed by the product owner.each of them will have verification criteria as well.
Now in Scrum requirements dont change after the sprint has started .At the end of the Sprint you can analyze the verification according to the criteria for each item done.
If its done can only be found by the response of the Product owner.
Remember in Agile you "Embrace the change" even late into the development phase
Agree that this is something the development/test team needs to define, depending on your own practices. Some projects run so agile that they're willing to risk releasing bugs to their alpha stream; some consider any bug which gets outside the development group a process failure.
The project I'm working on requires peer review of code changes, and requires that whoever wrote the code either provide/update regression tests or explain why it isn't possible to do so. (They and their reviewer(s) also have to certify that they've checked for known bad practices. We're generally Much Happier if they can show that they ran the full test suite and have gotten a clean result (or clean modulo known open issues, at least) The code then has to survive intensive automated unit and functional testing on multiple platforms to demonstrate that it doesn't cause any regressions against those, and it gets further checked for common antipatterns by an automated code analysis system. Only then do we accept it into the main development stream and mark the work item complete. Note that completing one work item may only be one step toward completing a larger-scale task or story.
That obviously doesn't guarantee that nobody finds a new way to fail, but it reduces the risk to an acceptable level without greatly impeding speed of development.