TestArchitect™ – Automation Toolset

TestArchitect TM is the name we have given to our automation toolset. It reflects the vision that automated testing requires a well-designed architectural plan allowing technical and non-technical elements to work fluidly in their capacity. It also addresses the continual missing link of all test automation tools of how to design tests. In TestArchitect the test design is located in the center column flanked by the test automation execution engine and test management.

What is often misunderstood is that automated testing is not the same as automating manual testing. For automated testing to be successful, tests need to be designed with their automation already in place. In my experience it is this simple missing factor that is the source, of many test automation failures.

To tackle automated testing we have come up with a vision that consists of three elements:

  • an effective keyword-driven method for test design and automation called Action Based Testing
  • a toolset to support―TestArchitect―that has all the features commonly found in test tools including a shared repository organization and flexible web-based “dashboards” for managing test projects. However, this article will only focus on Action Based Testing aspects
  • a set of guidelines and best practices that can be found at our website, www.logigear.com/hans/

Action Based Testing method was a concept devised 16 years ago as a complex yet very critical project that is now widely used in software testing. The tests are clustered in “test modules”, and are described as a series of “actions’”varying from inputting a value, clicking a button or capturing and verifying a value. The actions are named with “action keywords” or “action words” and have arguments for the input and expected output values. Part of a test module is also a set of “test objectives” that detail the goals of the test. Action Based Testing contains many directions on how to determine the test modules and the test objectives, but that falls beyond the scope of this article.

A key concept in Action Based Testing is that the automation efforts don’t focus on the tests but solely on the actions as named by their action words. In most projects a relatively small set of actions can be used to describe a large set of tests. The result is that the tests are readable for humans and at the same time are fully automated. The automation is very maintainable, since in the case of a change in the system under testing generally only the implementation of one or more actions has to be modified; most of the tests can be left alone.

Do you need TestArchitect to do Action Based Testing? Not necessarily. In fact, a simple interpreter written in the scripting language of a test playback tool can do the job quite well. The outline of such an interpreter would consist of:

repeat

read a test line
look up the keyword
execute the function mapped to the keyword
write results in the result file

until no more test lines

TestArchitect, however, was developed to facilitate Action Based Testing test development. It organizes the test modules and the actions, and has tools similar to a test editor to quickly create the action based tests. Also popular is the feature of ’action definitions’, where existing actions can be used to create new ones without additional programming.

An added feature allows actions to be shared across test projects by having a project “subscribe” to another “supplier’” project. The subscriber can then use all actions of the supplier project freely and any project the supplier itself subscribes to are automatically available to the subscribing project. Subscriptions can be recursive and mutual: a supplier can subscribe to yet another project, in which case those actions are available for its subscribers as well, and even a supplier project can subscribe to one or more of its own subscribers.

The underlying concept in Action Based Testing is to design tests explicitly and to not rely on recording of tests. However, for practical reasons TestArchitect does come with a recording tool called the “Action Recorder”. Instead of generating scripts this tool produces action lines that can be inserted anywhere in a test module or action definition.

Another important aspect of TestArchitect is test result management. After a test run, results are initially stored locally. The user must take an explicit action to store them in the repository visible to others and later have an impact on metrics and reports. This process prevents repositories cluttered with results of the numerous ad hoc dry-runs users supervise during testing or automation development.

Once in the repository, results are further organized with proper naming or storage placement. Lastly, results are linked to the test modules and test cases they have tested.

Automation in TestArchitect is organized as a set of libraries that work completely separate from the test management and test design components allowing you to program the actions in virtually any programming language. It is also possible to execute the tests in a third party playback tool using its scripting language to program the actions.

All in all, TestArchitect is an ecosystem for testers to design, automate, and manage tests grounded in its core design of Action Based Testing. Without this method, I believe it’s just another playback similar to its counterparts. It’s my firm belief that TestArchitect serves to improve the quality and implementation of tests. This to me is at the very core of our primary objectives as testers: to write great tests that find meaningful bugs and help improve overall application quality.

Hans Buwalda

Hans leads LogiGear’s research and development of test automation solutions, and the delivery of advanced test automation consulting and engineering services. 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.

Hans holds a Master of Science in Computer Science from Free University, Amsterdam.

Hans Buwalda
Hans Buwalda, CTO of LogiGear, is a pioneer of the Action Based and Soap Opera methodologies of testing and automation, and lead developer of TestArchitect, LogiGear’s keyword-based toolset for software test design, automation and management. He is co-author of Integrated Test Design and Automation, and a frequent speaker at test conferences.

The Related Post

Developers of large data-intensive software often notice an interesting — though not surprising — phenomenon: When usage of an application jumps dramatically, components that have operated for months without trouble suddenly develop previously undetected errors. For example, the application may have been installed on a different OS-hardware-DBMS-networking platform, or newly added customers may have account ...
Identifying which tests to begin with when starting automation is key to driving testing cycle times down and coverage up. So there you are. You’ve done a little research and made the business case to upper management regarding test automation and they bit on the proposal. Surprisingly, they supported you all the way and are extremely ...
From cross-device testing, to regression testing, to load testing, to data-driven testing, check out the types of testing that are suitable for Test Automation. Scene: Interior QA Department. Engineering is preparing for a final product launch with a deadline that is 12 weeks away. In 6 weeks, there will be a 1 week quality gate, ...
We’ve scoured the internet to search for videos that provide a wealth of knowledge about Test Automation. We curated this short-list of videos that cover everything from the basics, to the more advanced, and why Test Automation should be part of part of any software development organization. Automation Testing Tutorial for Beginners This tutorial introduces ...
The Cloud demands that we be as nimble as possible, delivering features and fixes in almost real-time fashion. Both customer and provider rely on software development that can maintain quality while being light on its feet and constantly moving. In addition, Cloud-oriented systems tend to be highly complex and dynamic in structure — more than ...
When automated tests are well-organized and written with the necessary detail, they can be very efficient and maintainable. But designing automated tests that deal with data can be challenging if you have a lot of data combinations. For example, let’s say we want to simulate a series of 20 customers, along with the number of ...
An Overview of Four Methods for Systematic Test Design Strategy Many people test, but few people use the well-known black-box and white-box test design techniques. The technique most used, however, seems to be testing randomly chosen valid values, followed by error guessing, exploratory testing and the like. Could it be that the more systematic test ...
Are you frustrated with vendors of test automation tools that do not tell you the whole story about what it takes to automate testing? Are you tired of trying to implement test automation without breaking the bank and without overloading yourself with work? I experienced first-hand why people find test automation difficult, and I developed ...
In order to make the right choices among tools, you must be able to classify them. Otherwise, any choice would be at best haphazard. Without functioning classification, you would not be able to understand new tools fast, nor come up with ideas of using, or creating new tools.
When configured with a Python harness, TestArchitect can be used to automate testing on software for custom hardware Unlike other proprietary and open source tools, that are able to automate only desktop, or mobile, TestArchitect (TA Test) has the ability to test the software that runs on hardware in the following ways: 1. TA can ...
Having the right Test Automation plan helps bridge gaps and fragmentations in the complex mobile environment. Figuring out the best Test Automation plan is one of the biggest frustrations for today’s digital teams. Organizations struggle to develop cross-platform Test Automation that can fit with their Continuous Integration cadence, their regression cycles and other elements of ...
Two dominant manual testing approaches to the software testing game are scripted and exploratory testing. In the test automation space, we have other approaches. I look at three main contexts for test automation: 1. Code context – e.g. unit testing. 2. System context – e.g. protocol or message level testing. 3. Social context – e.g. ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe