Shirly Ronen - rapid release flow and agile testing-as


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Shirly Ronen - rapid release flow and agile testing-as

  1. 1. Rapid agile release flow and the agile testing Shirly Ronen-Harel Aug 2010
  2. 2. • The following presentation will describe a short flow of daily uploads to production environment while the sum of those daily uploads results with a business and customer release, While The testing in this case is manual regression tests, no automation tests exists yet.• This is an agile team solution for dealing with on going releases to production of PSP’s while at the same time not released to an end customer.
  3. 3. • This may fit companies working with internet products which PSP’s must be released on a short period of time basis and autometion regression tests having a low coverage of product functionality.• Some of the rapid release flow may fit to an internal customer tools development or any product development.• We are distinguishing between a daily upload of PSP (potentially shippable product) and a final release to customer use.
  4. 4. Production change request Business release Station- Customer release
  5. 5. The company holds three types of release :1. CR :Production change request of user stories group: Release from development to production environment:• This is a process that is managed on a day to day basis where potentially shippable products (PSP’s) are integrated into the code main trunk and uploaded into the production environment• It does not mean that they are released or open to users use yet• These small releases allow continues functional integration into the production environment without overload users or internal customers with new frequent changes.• Each production upload is managed as a production change request as a part of the change management process in the organization1. A business Release• Milestone (sometime periodical sets of milestones) where the product organization decides to issue a business release containing the PSP’s (potentially shippable product) that were uploaded to production so far.• From this point on , no new features will enter into the customer release..• Internal customer acceptance tests can begin .1. Station - Customer release• a frequent small release to customer , that has a name and a number , , which was developed for few iterations(1-3) and has a millstone and ETA for release to customer/users use.• It is usually part of a bigger version release.• This release is prepared for some time , including relevant marketing materials and training for users .
  6. 6. R – business release takes the entire CR’s so far uploaded to production and close them to a release not yet release to customer. Development and upload of CR continues but will be integrated to the next R. Customer related tests /pilot may begin at this stage.CR – (user stories group) Agile development S - Customer release:team uploads PSP’s to production , sometimes The product is release to customer includingon a daily basis. This process is managed as documentations and all preparations the businesschange request process of production change needed to do in order to be able to prepare customercontrol. for a quality release. Uploads of PSP to production demands the architecture ability to split between production and customer releases.
  7. 7. Release/CR/StationsNo customer releases (s) is allowed between stations (s).There can be many CR’s released during the iteration (with a qualitydefinition of done)Sometimes there are delays in delivery of business features to the Rmilestone.Once an agile team miss those R milestones ,with features to bereleased , those features will be moved to the next R station.
  8. 8. User stories (US) FreezeUS freeze US freeze US freeze Business release Customer releaseNo new user stories can enter (unless major exception is required) a Sprint/Iterationafter the planning session is set and team commits to sprint goals andartifacts.
  9. 9. Code Freeze US freeze US freeze US freeze Code freeze is set before any CR or PSP
  10. 10. Backlog user stories Freeze and code Freeze Top 3 (n) user stories freezeAccording to team WIP Team should work on top n` user stories only. ,Other user stories , that are in the backlog ,are not yet coded . Theyare Only elaborated and acceptance criteria are defined.
  11. 11. 1 Working on top user stories Once a user story is developed (and done) , the team is allowed to pick up the next user story and code2 it (obviously- including testing). The next in line user story , ready with acceptance criteria is entering the list of top n worked user stories.
  12. 12. User Story Code Freeze Just before a user story is done, team freeze code , and regression tests starts(Manual tests).
  13. 13. User Stories Quality Tests Each user story is tested for its tasks, its functionality and with other user stories for a group regression tests, As part of a mini hardening tests phase.
  14. 14. Release End Game TestsUS freeze US freeze Business release Business release FreezeBefore business release (R) the team will perform the end game tests ,packaging and final quality verifications.
  15. 15. R&R •Product manger is Responsible for the product plan. •PO : Product owner preparing release and sprint backlog. •Scrum team : ‘Development and testing’ is responsible for quality. •Code freeze is a mutual decision between Po and scrum team. •Upload to Staging environment is a mutual decision between PO, Release manager and scrum team. •Upload to production environment is a mutual decision between PO, product manager and Release manger . •Business release is a decision for product release to make.
  16. 16. The company mature agile operation performs thisflow in a days<->weeks time farms. and it works!