| || |
Process for small upgrade projects
I am recently been assigned a project , which basically targets on developing upgrades for software and launches in the market in a small time frame (within a month). The upgrade is basically for versions that is already deployed in some environment.
To be specific , if handset say, S, is launched in Korea, and the main focus of the team is to share a tweak or upgrade from GB to JB , or higher android version with small add-on enhancement in a small time frame. Also, as part of testing there is both in-house and onsite testing for better stability of the version post enhancement
I need to know what kind of a Process can be established in here. what all can be the kind of Quality Control activity that can be deployed in here.
A perfect example for this would be "Cyanogenmod". If any one can help me on understanding what is the process followed by them.
Awaiting Response from experts
I have no idea what Cyanogenmodormedore-brickabracka is but this is all going to depend on your development process and how quick, or Agile, you can be in getting the fixes into your test environment. Is there a schedule you are on to get the fixes? Is QA involved in setting the schedule so you can have time to test the fix, and any regression items that occur? This is what will be more important for you in trying to get your work done, if you are involved in the development, understand the changes and know or have input into the schedule, rather than just copying some other company's process. Not every company works the same, so you cannot just take a process from another place into yours and expect it to work.
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
Now wasting blog space at QAForums Blogs - The Lookout
2-4 Week Sprints
I have worked in similar environments, in terms of the release cycle. In those environments we followed an Agile approach with 10 day sprints.
Initially the work requirements for the Sprint would be documented as 'Stories' in a suitable Project Management tool (we used Jira).
The work items (Stories) would be split into new Features (enhancements) or Defects.
From there you can split the work into 'tasks', some development, some QA\testing etc. so that each story becomes a mini Project.
For the whole Sprint you need to set milestones to determine if the whole Sprint is on Track.
Each Story follows the milestones by setting a Status, for example "Dev Complete", or "Testing Complete".
The key to this approach is 'cut overs', that is at what point do you move the Dev changes into a QA testing environment.
This is an admin task and will vary depending on which source revision control systems you use and how many environments you have (i.e. Dev. QA and Pre-Production).
There is no one answer to your question but 10-15 day Sprints with a complementary release process would be my suggestion.
Basically when its about upgrading something there is always a need of doing better,Till the time what our need is something which works correctly at the moment a way or a tool that help us with learning and at the same time improving.