In my third part of building a scalable test framework, I’m talking about the importance of modularity in the design of your framework. This is perhaps the easiest category for many software developers to understand as it forms part of your typical software development best practices in designing any application that is easily maintainable and robust in design. For many testers, however, it gets a little complicated because it makes the actual design and readability of the tests a little more difficult.
Understanding the benefits of modularity is not difficult though, it’s knowing what level of modularity is required and the truthful answer is as much as possible. Yes, it might take you longer to get started with your test design because you need to build every little object, test element and action it on a completely separate object on its own, but once it’s done, it makes it much easier to reproduce and reuse your objects as required across multiple tests. Much the same way you would expect to build your applications that need to be tested following the same principles.
*A basic example of a high-level test framework architecture.
Treat your framework as you would any other product
However, that does lead me to one of the key things to realise when building your test framework – you are engineering a product. We expect software testers to have a different mindset from developers, but yet when it comes to building your actual framework, you need to treat it like you would any other product – ensure it has a clear, specified design, well architectured and engineered around software development best practices. You should even unit test your own framework where possible to ensure any future code changes don’t break other tests.
Companies are failing to build scalable and work test automation largely because they are getting a bunch of software testers who specialize in automation to build it rather than getting a bunch of actual software engineers to code it. A good test framework will require a good grasp of development methodologies and best practices to work effectively and its important companies make a concerted effort to build it in such a way. Companies are moving away from big monolithic software programs to object-oriented micro-services because it is simply easier to maintain and your test framework should ideally follow the same design principles.
Build with performance in mind
Another aspect which is often not always considered in the design of the automation framework is performance throughput. How fast does your framework actually execute the tests it is required to do. Again, a lot of this points towards ensuring the code is writing in an optimal manner that increases processing efficiency and executes quickly. It might not seem as important as what you would need for your actual applications because it’s unlikely your framework will ever require the load or stress that any production application would, but still, the faster it executes, the better it can scale to your organizational needs.
All things need to be maintained
Lastly, but perhaps most importantly. You wouldn’t want to leave production code unmaintained and so you need to look after your test framework long term. It too will need to change and evolve over time and while your modular framework certainly reduces maintenance considerably, ensure that engineering hours are provisioned to keep all your tests executing as expected.
Don’t take designing your test automation framework for granted. It requires careful planning, a proper software model with classes and methods and the same level of focus you would give to building any other application. The most successful frameworks are those that adhere to the principles of sound software development
Comments