|
TRAMS BACK OFFICE TIPS & TRICKS
Release Cycle Internal Workflow
Linda Pannekeet, TRAMS Back Office Product Manager
As we wrap up our beta testing on TRAMS Back Office (TBO) 3.01
and begin work on version 3.02, I thought I would share our internal
workflow of a release cycle to help you all understand what is involved
and how that equates to the releases you receive.
First I’ll define the terminology we use internally:
- Product Management – That would be my role. As TBO Product Manager,
I prioritize the enhancements and new features that will be incorporated
in each release. I started to transition into this position January
2008 in conjunction with managing Client Relations.
- Product Development – This team is responsible for all of the technical programming.
- Specs – Layout and document specific details of a design to be incorporated into our applications. This helps us determine the amount of work that will be required.
- Code – The output of our Developers that changes how the applications function.
- QA (Quality Assurance) – Our Testing team is responsible for testing every build delivered by Development before releasing to beta testing.
- Builds – These are interim compilations of new code used to test new features, enhancements and fixes without affecting the current released version.
- Code Freeze – A phase in the release process where development is limited to code changes for fixes related to bugs flushed out in alpha testing.
- Alpha Testing – Testing that is done on builds delivered by development to our QA Department prior to Beta Testing releases.
- Regression Testing – Testing of previously fixed bugs to ensure the issue has not re-broken in later builds. Generally automated scripts are used to run regression test suites.
- Scripting – Automates testing by robotically performing various test scenarios in our applications to try to flush out any issues that need to be addressed prior to beta releases.
- Beta Testing – Testing that is performed by customers who have volunteered to be on our Beta Testing Team.
- General Release – The version that is announced and released
to all customers. Product Managers create target release dates
for each general release.
It takes an amazing amount of teamwork to make new releases happen.
We conduct Development meetings on a regular basis (generally weekly), where Product Management, Product Development and QA come together to discuss adding specific new features and enhancements (most of which are submitted by our customers), spec out new features and enhancements and clear up any road blocks that will infringe on our release time line adherence.
All enhancements, new features and fixes are maintained in a database and we use an application that allows us to track the workflow of each item. All departments involved with development and testing use this tool.
The workflow during a release cycle follows this course:
- New features and enhancements are discussed in development meetings.
- When items are approved, Product Managers update the database
with new features and enhancements and prioritize each item for
a specific release. The QA teams enter issues on existing features.
- Each item is assigned to a Developer.
- Each Developer creates new code for each item and checks in the completed items to a central repository.
- When QA is ready to test a new build, they submit a request to Development to compile the new code from the repository and post a new build.
- Development posts the new build, and QA downloads the new build and tests each item. Product Managers also test new features and enhancements to ensure they are working as designed.
- After all of the items scheduled for a particular release have
been completed, QA begins another cycle of testing where each
Tester runs routines across the entire application to try to flush
out additional issues that need to be addressed prior to beta
release. During this phase, development is in “code freeze”. If
new issues are discovered, only critical items get addressed and
QA tests the area around what got fixed.
- Scripts are also run at this time. They perform testing robotically and are generally geared around previous issues that were fixed to ensure they have not broken again in subsequent builds or releases.
- QA then asks development to compile update files. These files contain all of the components that come together to make the program function properly. These files also get tested to ensure the most recent versions of the components have been included.
- Once all testing has been completed, release notes are compiled to post with the beta release. These are the notes our Beta Testers read prior to downloading and installing new updates.
- We notify our Beta Testers who download and use the new beta version and report any issues they may find to our QA Department.
- QA enters the information into our tracking database and then assigns the item to that appropriate Developer.
- Development fixes the issue, posts a new build, QA tests to ensure it’s working properly. They test all around that fix to also ensure this fix didn’t break something else.
- QA requests new update files which are tested again and posted with the new release notes.
We are very conscious of turning out each subsequent beta release in a timely manner to try to minimize the impact of issues found by our Beta Testers. The contributions from our Beta Testers are highly valued throughout TRAMS, Inc.
The beta rounds take place until we have an interim where no more issues are being reported for a period of time. We then create setup files (full installation files) and post both the update and setup files and announce the General Release to all of our customers.
With the amount of effort and teamwork each release takes, we are very proud of our track record of releasing 2 to 3 releases every year.
We hope every customer reaps the benefits of our efforts through increased
efficiencies to aid in streamlining your day-to-day business. We appreciate
your business and will continue to strive to deliver cutting edge
technology to your business.
|
