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.
