Testing policy in SCRUM

• The first 2 stories already exist and have been delivered in previous releases.
• Story number 3 and 4 is new stories and is a deliverable in the current release.
• Story 1 and 2 is related to stories 3 and 4.
• Internal testing includes: stories, story tests, unit tests, functional test packs, regression test packs
• All testing artifacts are stored in subversion.
• Stories, story tests and unit tests are stored with the code.
• Functional test packs, regression test packs are stored in a testing project in subversion.
• Working internal test packs are stored under the relevant business context: “Testing/Context/Context1”
• If an internal test pack is used during a release, test results are recorded and stored under a “Release” directory in subversion.
• The Tester and the Product Owner sign off the last version of an internal test pack internally. The Tester then scans the signed off pack in and upload to subversion under a “Release”.
• The Delivery team prepares the Acceptance Test Packs. This is handed over to the Client, together with the
• The Product Owner, Client Side Representative and Client sign off Acceptance Test Packs. The signed copies are scanned in and send to the Tester. The Tester stores the signed off copy in subversion under a “Release”.

Definitions

Functional testing: quality assurance within the delivery team, focused on testing user stories delivered during the current release.

Regression testing: quality assurance within the delivery team, focused on testing user stories that are related to stories delivered during the current release cycle. It also focused on grey box and black box testing. Examples: 1. From UI down to database; 2. Across infrastructure software: ftp => application server  => application server =>; message queue => message queue database

Acceptance testing: is conducted by the Product Owner, Client Side Representative and the Client to verify that the stories delivered during the release, meets expressed requirements.

Sprint Retrospective

• Timebox: 2 hrs for 2 week sprint.
• Should be done before the next sprint planning session.
• Evaluate: 1. what worked 2. what did not work.
• Each team member has a stack of post-its and write down items of 1 & 2 above.
• Items relating to 1 & 2 is then put up in different corners of the room.
• This process continues till everyone has written down everything that comes to mind.
• 1 person in the team picks a item to start with and it is discussed amongst the team.
• Actions are identified for each item.
• These items are added to the product backlog for the next sprint with a story point value, so that the team gets time to work on the improvements.
• On 2 items: also focus on how do we continue to make this work. Write down some ideas.
• When evaluating items think about: people, relationships, process and tools. Some examples as per the scrum guide: team composition, meeting arrangements, tools, definition of "done," methods of communication, and processes for turning Product Backlog items into something "done."