When the vendor provides their annual release, the organization probably goes through formal testing. But what about patches and bug fixes? Do you not always do formal testing cycles, gambling with the testing roulette wheel?
Testing is a critical step in the implementation process to ensure that the software functions as intended, meet requirements, and delivers the desired outcomes. It helps to identify any errors or defects that may impact the systemâs functionality, reliability, or performance. The testing effort involved will vary depending on the type and size of the change.
Types Of Testing
There are several different types of testing to customize and meet your needs. Some different testing types are:
1. Regression Testing â testing to ensure that the change hasnât negatively impacted any existing features or functionality.
2. Negative Testing â intentional testing for invalid inputs to verify that the software recognizes and processes the error.
3. Integration Testing â tests the different modules to ensure they integrate and work together properly.
4. Security Testing â includes tests like penetration testing to identify vulnerabilities in security.
5. Compatibility Testing â to verify that the software works across different devices, browsers, and operating systems.
6. Documentation Testing â to test the accuracy of the documentation. Gather feedback from the users about the usefulness of the documentation.
7. Accessibility Testing â tests accessibility for users with disabilities to ensure the software meets applicable accessibility standards.
Testing Best Practices
An organization may not test because they âtrustâ the vendor, or they underestimate the potential risks and consequences of not testing. But with everyone so busy with competing priorities, another rationale is resource constraints. They donât think they have adequate resources (e.g., skilled personnel, time, or budget) to test. Whatever the reason, they may assume that the risks of not testing are minimal or manageable and may not prioritize testing.
There are best practices for testing technology. First are the people resources. Make sure you involve IT as well as the relevant business users to make sure all testing aspects are adequately assessed. There is a relevant quote: âMany hands make light work.â The next best practice is to have a separate test environment (so that youâre not testing in production).
When testing, create comprehensive test plans/scripts to provide a roadmap for the testing process. Define the testing scope, resources, and scenarios using real-life scenarios to test functionality, security, and performance in a more realistic setting. Document the test results comparing the actual outcomes against the expected outcomes. If the test doesnât pass, track the defects using an issue-tracking system. This will allow you to capture, prioritize, and track issues to resolution.
Unlike a big birthday/anniversary party, nobody likes big surprises (aka a major issue) after implementing a seemingly minor patch into production. If you properly test and there are issues, you can decide to accept the risk of moving forward and temporarily creating a workaround.
If you install the software (even a patch or bug fix) without testing, then you introduce the risk of having unintended results/consequences. Does the risk of not testing outweigh the time savings of not testing? If you follow the best practices, you can make the testing process more efficient.
For more information on the value of testing, follow me on LinkedIn!
