A major contributor to success in test automation is test design. If tests have many unnecessary detailed steps and checks, even a skilled automation engineer will not be able to make the automation efficient and maintainable.
Action Based Testing (ABT) uses a modular keyword-driven approach. Tests are organized in test modules and are built up of sequences of actions. In our TestArchitect tool, we define these in a spreadsheet format that is easy to understand.
Well-defined test modules can provide a healthy framework for teams to work with, in particular if modules have a clear and unambiguous scope, the scope is well-differentiated from other test modules, and all test cases, actions, and checks within the test module reflect the scope.
A key differentiation is between business tests and interaction tests. Business tests have a business-oriented scope and should not contain UI details. Interaction tests focus on the interaction between the user (or another system) and the application.
Other than this fundamental distinction, various projects may come up with different ways to organize tests. I want to share a way that we have had good experience with. It is based on the observation that, for many applications, a lot of the tests can be well-organized into two main categories: business objects and business flows.
Business objects are the items that an application works with, such as customers, employees, orders, invoices, etc. Business flows are the (mostly) end-to-end processes that usually hit more than one business object. For example, processing an order can involve the order itself, articles, invoices, payments, etc. Most tests will fit in categories (folders) for business objects and business flows. What’s left over are various tests in categories, such as administration, interoperability, data, etc
Consider an e-commerce site. People can view and order items and buy them with a credit card. Such a site would have business objects: articles, customers, orders, payments, credit cards, etc. As an example business object, let’s assume that the site supports “promotions” in which discounts are given under certain conditions.
Promotions can:
- be a discount percentage or dollar amount
- be based on articles, article categories or comprehensive
- have a certain time period
- be rewards for volume or timely payment
- be regional or global
For example of a business level test – It creates two promotions that overlap each other.
To manage promotions, the site will have various UI functions, either web-based or regular. In the UI there might be specific behaviors to be tested, such as a date can only be in the future. Or, in the example below, a certain town in The Netherlands needs to exist in a list box with towns.
Carefully organizing and designing tests can be a great contribution to their quality, efficiency, and manageability. In particular, it can help make their automation more stable and maintainable. A business-oriented approach to the test design, for example, centered on business objects and business flows, can be a great start to obtaining a good and automation-friendly test design.
Subscribe to LogiGear Blog
Signup and never miss out on our latest news and updates!
He is a pioneer of the keyword approach for software testing organizations, and he assists clients in strategic implementation of the Action Based Testing™ method throughout their testing organizations. Hans is also the original architect of LogiGear’s TestArchitect™, the modular keyword-driven toolset for software test design, automation and management. Hans is an internationally recognized expert on test automation, test development and testing technology management. He is coauthor of Integrated Test Design and Automation (Addison Wesley, 2001), and speaks frequently at international testing conferences.