Don’t mess with your releases – Do Plan (Endha oru Vishyathayum plan panni pananum okay!)

karthikeyan S

1 min read

Recently we had a major version upgrade in our Healthcare project built using Ruby on Rails, We migrated from Rails 4.1.8 to 5.2.3 version, which is considered to be a major version upgrade and our application is 5 years old baby, you know with loads of fantastic well matured features.

I would like to share how we managed this version upgrade from QA perspective with a planned and nice(I and our team believe) process in our project.

Creeping

Created the google sheet and divide the functionality into 6 phases with the name of DarkHorse, MR. Spy, DropStone, SofaKing, TakeAway, Thrasher

Wondering what these names are ? Nothing fancy, We came up with these different names just to make it interesting (you know our scrum master really liked it and some did not), and we fixed the internal release date for every phase. End of every phase a new build will be pushed to the test environment.

Crawling

Jira is one of our primary Project Management and Bug tracking tool. The first thing we did is created an Epic with the name of Rails upgrade.

After Epic, need to create the Version for tracking the issues, it will help us for Releases.

Pulling up

Create an individual Ticket for each function and mention the Version, Label and Link with Epic it is easy for us to track. Filter the issues using the Label

We use Zephyr for managing all the Test cases.

  • Create the New Test Cycle and mention the version name
  • Create a Cycle(I named it as Regression Testing)
  • Pull the Test cases into the Cycle
  • Add to the parent case

Once the functionality is ready for testing, open the Test case and execute it step by step, In case of any bugs found change the execution status to FAIL.

Create a Bug -> Add to parent case -> Link it with the current version -> Add Epic -> Add Label

Walking

Once functionality is working fine and verified by the QA team, move the ticket to user acceptance testing, on approval by UAT team move to done. Now the ticket is ready for production deployment , prepare a checklist for the ticket.

Cruising

We have a column called Release to track the entire tickets relates to an epic based on the version with the below listed information. Which will give a very nice insight about the release.

  1. Start Date, End Date and Description of the Version
  2. Number of Issues
  3. Issues done
  4. Issues in progress
  5. Issues to do

So far we have discussed on how to walk, will explain more on how to run in my next blog.
Please do share the process you follow in your projects as comments.

Related posts:

2 Replies to “Don’t mess with your releases – Do Plan (Endha…”

Leave a Reply

Your email address will not be published. Required fields are marked *