In this blog, we take a close look at the process and preparation that go into the testing of changes to new or existing IT systems.
What you will find is that testing of your developed code or configuration serves as much to confirm your understanding of the business requirements as it does to resolve code or configuration errors.
So, let’s explore the different phases of testing:
1. Test approach document – and a common error
This will generally be in the form of a document that outlines:
- What is within the scope of testing
- Test process
- Level of testing unit, UAT, regression etc.
- Testing tools to be used such as HP’s Application Lifecycle Management (ALM)
- Roles and responsibilities of the testing team
- How defects will be logged, tracked and managed
- Change process in terms of how any fixes are managed
- Details of the test environments and what they will be used for
- Testing sign off process
- Test entry and exit criteria.
One common error to make is to write the document, get it signed off and never refer to it again. Mistake! It’s essential to keep referring back to the document as you move through the testing phases. This will ensure you adhere to the signed off approach.
2. Test Plan
It’s important to plan out the testing phases and include in the plan the activities, dependencies and timelines required to successfully complete testing. The plan will also include the number of testing cycles that will be required.
3. Script Writing
In order to successfully test the system in both Unit and UAT phases, test scripts will need to be written so that they take the tester methodically through the test.
Typically, the scripts are written in Excel with steps guiding the tester to the positive or negative outcomes depending on the nature of the test.
4. Requirement traceability
An important element of documentation within testing is ensuring that all requirements are covered within the test scripts. The most effective way of ensuring their traceability is to link the tests back to the initial requirements using a matrix.
5. Script prioritisation
Due to project time pressures, or because of the vast number of test scenarios, sometimes not all tests can be covered. At this point it’s important that a risk-based approach is adopted and that tests that are likely to fail or could potentially cause major issues are prioritised over more cosmetic type tests.
6. Incident management
Tracking and logging of any testing outcome that does not match with the expected test outcome needs to be logged as an incident. These can be logged utilising a tool such as ALM or QC or even just in Excel if these tools are unavailable.
Not all incidents, however, will necessarily be turned into a defect. You may find that a particular item of functionality is meant to work that way, in which case the test script is incorrect and needs to be changed.
Incidents should be tracked from inception to conclusion, so in order to manage them successfully an incident management process and classification should be introduced including severity status.
7. Closure report – and you’re done!
Importantly, testing will not find every single bug in any system. This document is key in giving confidence to key stakeholders that the testing has completed sufficient coverage for an implementation decision, as they will be ultimately responsible for ensuring the successful deployment of the application or amendments to it.
The closure report should include all the data from the completed test activities and statistics and an essential consideration is that it should confirm that all test exit criteria have been met.
Need any help?
While these are some of the key elements that you must consider when entering the testing phase of any project, this blog really just scrapes the surface. Arum can provide expertise on any testing phase of a project as we have many years of working on major projects in this space and have experienced both the pitfalls and best practice first hand. If we can help you on any aspect of testing, please contact us.