Testing methodology

By following four basic guidelines, you can incorporate Rational® Integration Tester into your testing methodology. These guidelines drive efficient and expedient integration testing, and they can be applied to your testing process and infrastructure requirements.

Do not wait for the UI to automate your tests: IBM® Rational Test Workbench tools are designed for integration testing. They do not require a user interface to be in place on your system under test (SUT). Often, by the time a UI is in place, it is far more costly to test.
Test early and often: Testing earlier in the lifecycle means that defects are less expensive to resolve. Because integration tests run much faster than normal automated UI tests, you can plan to run regression test cycles as often as is necessary. Rational Integration Tester is designed to work with most of the popular continuous integration tools, such as Jenkins.
Evolve your tests and stubs as you progress through the lifecycle: You can use Rational Integration Tester for initial testing and begin by creating very simple tests and stubs. These test assets (test, stubs, and data) can be passed along to teams further down the lifecycle who can enhance the basic tests to ensure that they reflect live environments. This process ensures consistency and efficiency in the automation test cycle. Use test assets to create test suites, performance tests, templates, and stubs.
Plan for flexibility by stubbing strategically: The virtualization (stubbing) capabilities mean that testers and test managers can think differently about their approaches. They can plan to mitigate the unavailability of interfaces to test against. For example, if the risk of environment unavailability for a particular interface is high, you can plan to stub the interface before the environment becomes unavailable. This means that when the inevitable happens, testing can continue. Efficient planning with stubs promotes test environment agility.

Note: The best approach to testing is risk-based, and this is no different when using Test Workbench tools. You cannot hope to test every permutation of data, functionality, and interface. Therefore, your test manager must decide on the most important path to cover for your project. Is it more important to test every interface with a shallow set of data or are there critical paths through the system that must be validated by using a wide breadth of data? These decisions guide the focus of test cases created with Test Workbench tools.

Feedback