Tag: Migration

Software Upgrade Testing

~ Danny Kwok ~ Leave a comment

In many software upgrade, 80% of the efforts should be spend on testing. This is because software upgrade testing can be tricky. You have to decide whether to test in depth or cover in breadth. For many project teams, the lack of application knowledge will be obvious in the execution of testing. How should you select and determine what are to be tested?

Set your Testing Objective

The key objective of testing during upgrade is to ensure all is well. Thus, there is a conflict on how much we should test. You can use objective to determine your testing coverage. I like to set my testing objective to ensure a smooth UAT (user acceptance testing). In order to achieve this overarching goal, I will need to focus on tests on common break points for software upgrading.

Agile Testing

A key issue of waterfall process is linear testing. This is the process of unit testing, system integration test (SIT) and UAT. I usually mitigate this approach by using Agile testing to raise user confidence. From experience, test are designed to passed within a set scripts and will fail during free style user testing. The duration to deploy fix during user testing will not meet the desired timeline for waterfall. Thus, I will choose to deploy knowledgeable support to role players as users to keep testing within an agile process.

The mindset of traditional testing in software upgrade aim to test for pass. This is why many issues surface during the user testing. You should allow knowledgeable support members to test to break the software. Following test scripts may not be useful in the agile world of today.

Advertisement

Oops! OTM Glog Not Backward Compatibility

~ Danny Kwok ~ Leave a comment

The major issue with upgrading and migration to Cloud is backward compatibility. This process is like an evolution where an entire species will be extinct unless you evolved. Take OTM upgrade as an example, the nonsensical troublemaker Glog XML is forever not backward compatibility. This creates a ripple effect to legacy systems who have to conform to this change. While we are lamenting this issue, what should be done?

Photo by Ethan
Where to Change?

When the product do not support backward compatibility, this raise the issue on where you are willing to invest on change. Usually, there are two areas of change that could be done. The standard approach is to make the change on your end to conform to the upgraded Glog. What happens when the change impact is huge and take a long time? The other approach is to seek the vendor help to raising a product change request to support the backward compatibility?

Transitional Application

You will be in a deadlock when both approaches have difficulty to meet the required change. Thankfully for Cloud, you can now easily create transitional application to connect and translates the changes for backward compatibility. This is a common interim solution to maintain the change impact to minimum. The transitional application will be transition in nature and allows migration or upgrade activities to proceed. It also helps you to conduct full change to the new Glog at a later stage.

In the bid to upgrade for cloud, many applications are not backward compatibility to older versions. This creates a dilemma on where to manage the change. You may want to consider building transitional application minimise the change impact of backward compatibility like OTM Glog.

Test Grouping Tips

~ Danny Kwok ~ Leave a comment

With the increased migration of Cloud or upgrading activities, testing efforts are increased exponentially. Full testing is often ideal but unrealistic and costly. Thus, you will need to strike a balance in your testing coverage. One method is to group your test cases to reduce the testing duration. However, there are ways to prepare for this approach.

Preparing for Test Group

The purpose of test group is to reduce cost and efforts. You can also maximise testing coverage with minimal test cases. However, you will require deep understanding of your test cases before you can conduct a proper grouping. There are many approaches to group your test cases. A common way is to group the application features. Other methods involves functional grouping or customer groupings. You can also group by user base or locations. While there is no right or wrong, the key is to obtain the most efficient grouping.

Agile your Test Grouping

There is a misconception that test grouping is fixed when testing is on-going. This statement is true for many waterfall projects. On the other hand, you are encouraged to iterate your test groups if you are running on Agile. The testing process will gauge the effectiveness of your test grouping. It is important to update your test grouping to maximise your test coverage. As opposed to waterfall mindset, test groups process will lead you to design a better testing approach for your next Agile sprint.

Testing is most efficient and effectively if you can group them properly. Preparation is a key part to start your test group on the right track. You should also be prepared to amend the groups accordingly for your next Agile sprint.

Sanity Test 101

~ Danny Kwok ~ Leave a comment

Sanity testing is a simple test to check run through the system to ensure that the feature is deployed properly. The aim of sanity test is to probe for key known failure points from an activity such as migration, system upgrade or new enhancement deployment. The question is how should sanity test be conducted and what test coverage is sufficient.

Sanity Test Coverage

A good sanity test is a test that is quick and simple to determine if detailed testing is required. This test also provide confidence that the critical component of the application is working as expected. The sanity test is designed to cover a broad critical happy path of the application. E.g. if you are working on system upgrade, your sanity test needs to cover all the expected failure points due to upgrade rather than cherry picking of system modules or domains.

Automated Sanity Test

It is recommended to automate your sanity test if you are going to conduct sanity testing multiple times throughout the course of your system. For instance, system upgrade will require sanity testing at every upgrade. In addition, sanity test must be conducted within a day or two in order to decide if further testing can proceed. You will need to raise alarms when your sanity test takes more than two days. Thus, sanity test is usually automated for this reason

Sanity testing is a common activity for all major projects, upgrades or enhancements. The objective of sanity test is a fast and broad coverage of the functionality to be checked. Due to this reason, sanity test is becoming automated.

Upgrading Dilemma

~ Danny Kwok ~ Leave a comment

During upgrading of system, you will be face with dilemma. This is mostly due to outdated support of system components or architectural changes. How should you handle the dilemma faced? Will this be showstopper to your upgrading project?

Preemptive Upgrades

System upgrades will create known issues and fixes. Experienced upgrading team is able to preemptively plan and check for known issues. These known issues should come with standard resolution approach and fix. This preemptive strategy is to fix as much as possible on these known issues. In the process, you will encounter dilemma on some known issues that cannot be fixed.

Waiting Dilemma

One of the worst upgrading dilemma is waiting dependency. It usually happens when multiple parties or teams are working on the upgrading project. Each team have a dependency task on another. Deadlock may even occur when teams are waiting for one another. This dilemma is detrimental and results in delays.

Key challenges for upgrading dilemma impacts scope and timeline. It is advisable to get experienced upgrading team who faces these dilemmas. Dependencies must be clear and be avoided at all cost. Expected results of dilemmas results in showstopper and delays in the projects. Do be aware and plan for upgrading dilemmas with the best approach.

Upgrade or Migrate to Cloud

~ Danny Kwok ~ Leave a comment

With strategic change of many software companies to cloud, organisations have two options for their aging applications. One, you have to upgrade to the latest version to extend their support life. Two, you migrate your application to cloud version. What will be your rational for these options?

Upgrading Rationale

Cloud based products differs from their counterparts because of the ease of customisation. The extent of customisation and your comfort level to risk will determine how much you will opt for upgrading options. However, the major risk continues to exist due to the end of support for your application. Upgrading options only help to extend time needed for your preparation to cloud.

Cloud Migration

Cloud migration should be the default choose because the end of support is real. Regardless of the option taken, the end game is cloud migration. However, cloud migration involves entire redesign of your architecture. There are also refactoring done to existing codes. The key difference with upgrading rationale is the higher risk. The risk includes the architectural changes and code changes that will impact your customised product.

The option to upgrade or migrate to cloud differs in the duration or risk management. The end point will remain as migration to cloud. Upgrading are able to provide you extra time to lower your risk to cloud.

Cloud Assessment Approach

~ Danny Kwok ~ Leave a comment

One of the most common Cloud Challenges are customisation on premise application. Many assessment done to existing on premise will reveal these reasons why you should not move to Cloud. However, the assessment approach has been done incorrectly. Instead, it should be telling you on how you need to move to Cloud.

We find what we want to see

A good cloud assessment approach will not be one sided. It should have a balanced data and strategy to give the reader the right materials to make a decision. This is to prevent the bias of “finding what we want to see”. It is common to reason that heavily customised application to remain on premise instead of moving to Cloud. Vice versa, findings often point that Cloud should only handle lightly customised application.

Strategy to Cloud

As products move to SaaS, users will be forced to move customised applications to Cloud. It is important to provide strategy on how to migrate the customised applications. Many Cloud assessment will use Big Bang approach to review if the application can move to Cloud. You should also request for other strategy to be included in your Cloud assessment approach like phase transition or pilot migration.

Cloud assessment approach is often bias and skewed towards Big Bang migration approach. You should consider for other migration strategy when you are conducting your Cloud assessment. Thus, this will provide you a better picture to decide if you can migrate to Cloud.

Cloud Expectations

~ Danny Kwok ~ Leave a comment

Cloud expectations is a requirement that is often missed out. Unlike on premise, we often forgotten that Cloud is a product with constraints. Before you embark on a major cloud migration, it is recommended that you conducted a review of your existing architecture and expectations.

Understanding your Customisation

The common challenge with Cloud migration is customisation of existing on premise product. These customisation are often lost in translation over the years for legacy reason. Some of these customisation would even be uncovered during the cloud migration. Thus, it is important to do a deep analysis of your customisation. One guideline is called CEMLI (Configuration, Extension, Modification, Localization, and Integration) framework by Oracle.

Prepare your Cloud Expectations

Cloud expectations requirement must be translated to your critical success factors. These expectations will determine the effectiveness of your cloud migration. It is common to realise these expectations are missing. The user expectations will also mitigate the risks from Cloud migration. One such cloud expectation will be business continuity and minimum disruptions to operation.

There is a relationship of customisation and cloud expectations. Cloud is a product and will have larger gap for heavily customised on premise application. Thus, you will need to set clear cloud expectations to mitigate these risks. One common way is removal of customisation in preparation for cloud migration.

The Good and Bad of Waterfall Migration

~ Danny Kwok ~ Leave a comment

Waterfall migration is the mainstay for on premise application. In recent years, migration is adapting to Agile with Cloud. However, it is common to see conservatives conduct waterfall migration with Cloud. What are the good and bad of waterfall migration?

The Good and Bad of Waterfall

The good parts of using waterfall migration are:

  • Traditional approach with fixed scope.
  • Increased redundancy with development and testing environment.
  • Increased testing and issue management.
  • Tight control of changes from one environment to another.

By using waterfall approach, you need to anticipate these bad situations that will arise:

  • Increased duration from additional environment setup.
  • Increase cost of maintaining and licence costs.
  • Unable to react to scope creep.
  • High reliance to critical path.

While waterfall migration is a tried and tested method, be prepared for longer duration and higher costs due to the environment redundancy.

OTM Dilemma

~ Danny Kwok ~ Leave a comment

OTM (Oracle Transportation Management) can be a big dilemma if we are moving to cloud or upgrading. It is a configurable system that allows customisation from small degree of change to major one. A major part would be your decision to upgrade or migrate to cloud from the amount of configuration or customisation done to OTM.

Photo by Ethan Kwok
Cloud Dilemma

Many organisations would prefer to migrate to cloud for future support and upgrades. separate the customisation Cloud, like its name, really is cloud. You cannot foresee what will happen in Cloud until you are in Cloud. Your risk appetite will need to be high if you have done a lot of customisation on OTM. Prior your move to Cloud, a major task is to separate the customisation into REST services. How much time and effort will you invest? Should you forgo your customisation instead?

Upgrading Dilemma

Upgrading OTM major version can be quite a slow painful experience. The 6.4.3 is the last available version that is non Cloud based. The decision not to move to Cloud usually lies with the amount of customisation done. The biggest changes from old version to 6.4.3 version are architectural, user interface (UI) and report server. The dilemma comes in the sequence of upgrade you want to take. Report server is now mandatory after the removal of embedded reports. Should you move your embedded report first or do together with upgrade? How much training period should you allow for the new UI? How much time will it take to fix your customisation during the upgrade?

OTM upgrade or migration to cloud is a painful dilemma. There is always a temptation to status quo the version due to the massive efforts to factor risk and change management. In many cases, you need lots of patience and alternate plans while you are upgrading or migrating.