Executing a Test Plan
Now that you have described a foundation for building a test plan the next step is considering how to execute that plan and manage your test resources. There are three components that you should strongly consider:
- Measurement and reporting
- Resource Management
With IPv6 vendor code today, it is almost certain that you will find bugs or performance problems in your systems and you'll be submitting them to vendor support. When the vendor responds with the patch you will need to repeat the test for the bug itself, but also to test that no other bugs have been introduced (it happens far too often, right?). So make sure that you have built a test bed and management system that can repeat the test easily, and lets you compare the results with confidence.
For example, testing systems such as QualiSystems TestShell build a single software environment that can configure, deploy and execute the Test Plan. It has a drag/drop editor for building tests and live topology diagrams during execution.
For complex testing, you are likely to have many testing tools present such as IXIA, Spirent, Breaking Point, or even Java scripts and a test management platform that ensures that the test can be recalled from a program store, configured exactly the same parameters and perform the tests again. In effect, a testing suite for your network devices is being built.
Measurement and Report
If you are testing for performance of various devices, you need to compare and analyze the results of each product and each test run. But using many different tools, e.g., Traffic Generators, SNMP for device status, and scripts in Perl or TcL, means that reports will come from many platforms. Test systems like the QualiSystems TestShell framework can solve that by bringing the device reports into a single summary report that can be compared for all test runs and store it for future checking and validation.
A final consideration in larger organizations is the sharing of test resources. Traffic Generators and Test Servers aren't cheap to purchase, support or to keep the power on. Therefore the ability to share and manage those resources within a team needs more than sticky notes on a whiteboard or a spreadsheet on a shared drive.
Remote users should be able to run tests around the clock to increase utilization and allow test engineers to access resources remotely. Project teams need to book access to resources in advance while Test Managers resolve scheduling conflicts.
Again, a test system can be extended to provide a lifecycle management of the test lab – switches, servers, generators can scheduled and managed from a simple user interface.
Testing works best with Management Tools
The process of validating and testing can look complex and time consuming but the solution lies in automating the testing process. An automated testing process can be repeated quickly and easily. Testing for IPv6 compliance and stability isn't done once, it needs to be repeated until the products are stable and vendors have reached low defect levels and your confidence is high.
Testing should be performed during the procurement cycle to validate vendor claims and then repeated during the operational lifecycle to validate that the vendor software is meeting performance and quality targets. This will provide hard data and facts that can be used to improve your network and improve vendor value.
An automated testing environment provides tools that can make it possible to build test plans and then execute them from a single tool. It should combine test reports from multiple devices, and store them for future reference so that the validation process can be repeated in the future. Testing doesn't have to be hard if you can do it smart.
About the author
Assaf Lev is Director of Account Managemen at QualiSystems. QualiSystems is a leading provider of enterprise software solutions for lab management, device provisioning and test automation.