Release team working process

This is the way the release team is supposed to work.

Overview

The release team process consists of the following activities:

• Opening
• Testing
• Reviews
• Release assembly
• Bugfixing

Opening

This are the first things that the team should do after the official sprint opening:

• Create a branch from the trunk. The name should be further determined(perhaps something like release01 or release01-pre-alpha-2)
• Create a wiki page for the release. This will be ITERATION_<it_number>/Release
• Select tasks for testing. Sort them by their testability and importance
• Merge back valuable changes done on the previous release branch into the trunk
• Disable nonworking functionality that is not supposed to be available and is messing the other code.

Testing

This refers to the last phase of a task's revision lifecycle.

It includes the following:

• Writing user documentation for each user related task
  • User documents are something like help
  • They describe what Sophie 2.0 features are available and the way the user can use them
• Writing release documentation where applicable
  • It describes shortly the released features
  • Describes non-user features
• Making manual test cases in our TestLink instance.
  • Each feature should have at least one new test case each revision.
    • Compulsory demo test case that test usual user behavior. The idea is to check the task requirements (perhaps using the "How to demo" section).
    • One or more test cases for special situations.
  • Related test cases should be found and listed.
• Executing test cases
  • Execute newly created test case
  • Execute related test cases
• Reporting bugs that were found during the tests
  • Bugs will be new tickets in our Trac environment but with a different workflow.
  • They should have a description and a link to the test case in testlink that found them.
• Have a look at related bugs - this means look if there are new bugs in the related tests.

Reviews

• We should do reviews on implementations done by functional teams
• It this is needed we could help with design reviews

Release Assembly

• Final bugfixes
• Find workarounds for those bugs that cannot be fixed but
• Disable things that cannot be fixed or worked around
• Make the download page
• Make the downloadables

Bugfixing

• Choose bugs to fix from the opened ones in Trac
• Take the bug ticket
• Research for a bugfix
• If a fix is available its result must be described in the ticket
• Change the status of the ticket

Iteration schedule

• The iteration begins with the general sprint opening - 1d
• Do release team opening as described above - 2d
• Start testing and bugfixing.
• Start making reviews. We should always keep the tasks pending for a review as less as possible.
• As the iteration progresses the less effort is spent on testing and more on reviewing.
• Do the release assembly - 4d
• Do the demo and the sprint closing

You can also look at the attached photos.

Comments