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.
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.
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.
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
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.
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.
- Start Date, End Date and Description of the Version
- Number of Issues
- Issues done
- Issues in progress
- 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.
2 Replies to “Don’t mess with your releases – Do Plan (Endha…”
Interesting 👍🏻 Innovative too 👌🏻
Yeah! Nice read ! Congrates for the Major change done gingerly 🙂