Test architecture means the way you put together all those things you need in testing. Depending on what you test, where, and how, the test architecture may be simple or complex, ad-hoc or well-thought. Most often than not, test architectures are not thought of, they just emerge.
In test automation, a solid test architecture is a pre-requisite for long-term success. The bigger your test undertaking and the longer its life-span the more you should pay attention to your test architecture. A lion’s share of your future costs will depend on how you architected your testing.
The principle of separation of concerns means that separate things, such as test case and test data, should not be mixed but tied together through a well-defined dependency or interface.
Here are the top-few things you should at least consider in your test architecture.
- Test interfaces. There are typically two critical interfaces that separate concerns: the interface through which the test executor communicates with the system under test, and the interface through which test case is communicated to the test executor.
- Test cases. Many test automation people mix test case and test interface. Popular tools such as Selenium and Robot Framework enable clean separation of concepts but, too often, automation developers intertwine the test interface and the actual test case, creating a potential maintenance nightmare. This is a bit like having spoken words we use hard-coded in our throats to produce the speech.
- Test data. It is a common practice to to embed test data in the test scrips. As long as the data volume is small it doesn’t matter. But, if you have a wealth of data you’d better separate your test data (= input to the system to be tested) from your test case (= actions to be performed by the system to be tested).
If you haven't already, start your own test automation journey with free version of test automation platform Qentinel Pace!