Software Testing Approach Only Hours Instead of Days Available

Imagine that you only have hours left instead of days that you were initially allocated for testing. Does this sound familiar? No matter how well we have planned for the resources, estimating testing efforts, prepared the test scripts and test scenarios, it would be useless if we don't have a testable system. There are so many factors can contribute to the delay but how do you approach the situation so that critical functionality is tested or at least business risks can be identified?

Before we start discussing what can be done in this situation, I would like to emphasize that software testing is a process of finding defects to ensure that the system under test meets the business requirements. Thorough planning test efforts and monitoring test progress should not be taken lightly. The time component in software testing is generally divided into components:

Test to pass against requirements. This is about executing test cases and scenarios you have prepared during coding/development stage. During this stage a lot of the test cases need updating especially testing in Agile or SCRUM projects where the specification documentations might change (scope creep). I normally added new test cases as the result of better understanding of the system. During this period I normally find the obvious defects which can be easily verify against the requirements.

Finding defects. Once High and Medium priority test cases (priority is classification for requirements) have been tested I shift my focus from verifying the requirement to failing the system. At this stage I would have better understanding of the system and am able to create more specific and detailed scenarios.

This seems to be a good strategy if you have days to complete my testing. How should we approach the situation differently if we only have hours remaining? i.e. 1 day to complete instead of 3 � 5 working days from initial plan?

There is no right or wrong answer to this but we can start regression and/or exploratory testing using UAT Checklist. This will ensure that the main functionality for the business users are working. I also postpone all administration work such as updating test cases and recording test results until after UAT when I have appropriate time to go through detailed testing. I would normally recommend business users and/or stakeholder not to release to production until proper testing is complete but it is entirely up to the business owner to accept the risk only after they have reviewed the known defects and aware of any limitations.

In summary, going through UAT checklist and System Testing before component and Integration Testing is not recommended and should be avoided at all cost. However, things are not always as planned and different organizations or system have different acceptance level. It is a best practice to complete a proper testing rather that rushing into Production but we cannot expect everyone to understand and follow this. The next best thing is to make users and stakeholders aware of the risk by providing the defect list and test report status.