The QA/Tester must definitely be part of the SCRUM Team. Given below are the reasons as to why I believe so:-
-QA in SCRUM is not an external entity. In traditional model, QA is someone who doesn't knows anything about the product, until he receives it for testing. And once he receives it for testing he is expected to read the (mostly incomplete) SRS/Requirements Document and then test the product against the same. In SCRUM, QA must breathe the stuff being developed along with the team. He is very much involved right from the requirement gathering, elicitation, and documentation. The programmers can walk up to him and clarify any of the doubts they might have, related to the current story/feature they are working on.
-QA helps developers in coming up with the list of Unit Test cases, which the developer can then automate. This relieves the QA from the burden of testing the routine or mundane test cases and instead concentrate on other forms of testing (Usability, Acceptance, Exploratory etc.), thereby ensuring the quality of the product.
-QA plays an active role in Product Backlog expansion and elaboration and is part of most of the meeting between ScrumMaster, and Product Owner.
SCRUM expects you to deliver potentially shippable code at the end of every sprint and this is primarily what is meant when the Team proclaims a story to be done. In other words, when the team proclaims the story to be done, then it means that story or feature is potentially shippable. IMHO, you can't achieve potentially shippable status unless and until its artifacts have been tested. I strongly believe that an external QA will never be able to keep pace with the speed of the SCRUM team. On the contrary, an external QA will negatively impact the velocity of the SCRUM team.
-QA participates in Daily SCRUM Meeting, Sprint Review, and Sprint Retrospective.
-QA in SCRUM is not an external entity. In traditional model, QA is someone who doesn't knows anything about the product, until he receives it for testing. And once he receives it for testing he is expected to read the (mostly incomplete) SRS/Requirements Document and then test the product against the same. In SCRUM, QA must breathe the stuff being developed along with the team. He is very much involved right from the requirement gathering, elicitation, and documentation. The programmers can walk up to him and clarify any of the doubts they might have, related to the current story/feature they are working on.
-QA helps developers in coming up with the list of Unit Test cases, which the developer can then automate. This relieves the QA from the burden of testing the routine or mundane test cases and instead concentrate on other forms of testing (Usability, Acceptance, Exploratory etc.), thereby ensuring the quality of the product.
-QA plays an active role in Product Backlog expansion and elaboration and is part of most of the meeting between ScrumMaster, and Product Owner.
SCRUM expects you to deliver potentially shippable code at the end of every sprint and this is primarily what is meant when the Team proclaims a story to be done. In other words, when the team proclaims the story to be done, then it means that story or feature is potentially shippable. IMHO, you can't achieve potentially shippable status unless and until its artifacts have been tested. I strongly believe that an external QA will never be able to keep pace with the speed of the SCRUM team. On the contrary, an external QA will negatively impact the velocity of the SCRUM team.
-QA participates in Daily SCRUM Meeting, Sprint Review, and Sprint Retrospective.
