Today’s modern application testing matrix is full of rising complexities. In order to save time and money and to assure the success of a developed application, test automation teams have to start with the basics. A strong tower requires strong foundations. In this case, one of the most important parts of that foundation is the development of test framework. In order to ascertain that your product can bear the weight of all of today’s demands – those of both users and technology – all framework has to be flexible and robust. We develop test architectures in a modular, data-driven, and event-driven fashion that includes rich-logic. The main goal of test architecture is to achieve full testing with less test artifacts, meaning that we will have less maintenance of said architecture down the line. As Test Architects, our main goal is to preferably design one test case per one functional area, which can be achieved through framework modularity.
When designing modular test architecture, one can define two classes of test cases: Test Components and Business Processes. Test Components are usually smaller, reusable test cases that represent a particular functional area, while Business Processes are more procedural test cases oriented to test application business processes. Let’s take a look at a basic example of a common application to illustrate the above methods – a travel portal. The main purpose of this app is to help a user create their own itinerary for a trip. First, we will set the functional areas as “login”, “book hotel”, and “book rental car”. In order to develop test coverage based on these principles, we will develop test components separately for each of these areas.
Data-driven testing is carried out with a simplified principle of input and output parameters, meaning that our test cases should not have any static input and output values (when this is possible and logical). The advantage of data-driven testing is the ease of driving test scenarios though input and output data within a single test artifact. Later, we will incorporate all of these into a single “book itinerary” business case. Once we develop the business component, we can address the principles of data driving. Our goal is to create an artifact that will take any input and output values into testing procedures. Therefore, we will parameterize every input and output value such as the “user name” text field, etc.
Another important characteristic of a modern test framework is event-driven testing. Event-driven architecture is an script pattern promoting the production, detection, consumption of, and reaction to events in the script. Every test case should end with a triggered event and present validation criteria in the scenario. Building applications and systems around an event-driven architecture promotes validation of test case expected results that each test step has to have by definition. For example, when designing a Login Test Component we will create two test steps: Invoke AUT and Login (typing user name, password and clicking Login button), at the end of each step this test case will be triggering event in AUT presetting validation, i.e. Login dialog invoked, or Welcome page appears (including output data from the previous input step).
Last but not least on our list of foundations is rich-logic. This element allows testing teams to incorporate all business requirements. This includes applying conditional statement into the expected results area. For example, when there are multiple user groups in the application under test, we can create a conditional statement to validate which user of the group is logged in and outline subsequent steps for the user to proceed test in a certain way. Such framework can be executed either manually or in an automated fashion across any platform. With this method in place, we can take our business case of booking an itinerary and use it anywhere (Windows, Mac, Unix,Mobile etc.) without any further modification.
This approach allows better collaboration for team members, like application SME and Automation Specialists or new colleagues. It improves change management and reduces maintenance of test artifacts, therefore increasing testing ROI.
In conclusion, designing your framework in the most efficient way from the very beginning is the ultimate test strategy. In order to achieve a rapid pace of modern software development and offer proper test coverage, the foundations for an application’s script must be strong. Once the foundations are built with care and focus, the tower will stand tall and unwavering even in the strongest of winds.