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.
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.