A Test Automation Architecture Proposal for Big Organizations
In big organizations where there are lots of different applications to automate, test automation should be coordinated by a central team and actual development teams should make the test automation themselves. This is because the test automation in such a big organization is too big to be done by a single team. There are lots of different application domains and applications, thousands of test scripts to maintain, too specialized business cases to automate.
In such a big organization, it is important to abstract rest of the organization from technical details of test automation technology and give it a simple, useful, customizable and extensible automation framework.
In Akbank, we implemented a test automation framework which can be summarized as the image below:
This framework includes Keyword Driven Tests at top. Please see my article Granular Keyword Driven Testing for details. This layer provides the organization the simplicity and usefulness needed in test automation.
Code behind the keywords are divided into 2 layers:
Let me elaborate these layers in detail:
Test Implementation Layer
This layer is supposed to implement test automation logic and uses Driver Layer for all operations related to test automation tool being used.
As I mentioned before, test automation effort is too hard to be done by a single team in big organizations and instead should be implemented by all the development teams. These development teams have lots of other things to do, so making test automation should be as simple as possible.
To provide this simplicity, it is a good practice to hide technical details of test automation and the tool being used for it. Therefore, Test Implementation Layer lets all development teams write their own test automation code without learning too much detail on test automation and its tool.
Another advantage is an abstraction from test automation tool. This makes it a lot easier to change the tool being used. In case of using another test automation tool, only Driver Layer should be coded again, leaving Keyword Driven Tests and Test Implementation Layer intact.
Yet another advantage of this approach is to be able to use multiple test automation tools simultaleously, in order to gain the advantages of each tool when needed. For instance a simple run time parameter can be used to switch between the test automation tools. One tool can be good at reporting and the other at performance. When running tests in bulks, the tool with the better performance can be used. When it comes to see why a single test fails, it can be run with the tool with better reports, to make it easier to see the case of the failure.
To sum up, Test Implementation Layer provides these benefits:
领英推荐
Let me give a sample code from our Test Implementation Layer:
//Inputs text into the control with the given label.
public void InputText(string label, string text)
{
? ? var driver = new HtmlDriver();
? ? var inputXpath = GetInputXpath(label);
? ? driver.clickElement(inputXpath);
? ? driver.typeKeys(text);
}
So the Test Implementation Layer uses an HtmlDriver instance to make operations such as clicking on a GUI element or entering text. How these operations are implemented are abstracted from the test implementation. So if the test automation tool behind the scenes is replaced with another one, only HtmlDriver code will be rewritten.
One last paragraph here can be written about this magic getInputXpath method. As you'll notice, it is not an HtmlDriver method. It tries to predict the xpath of the text box whose label is specified by the tester. So it is up to the Test Implementation Layer to detect the GUI element to work with. Once the xpath is known, Driver Layer will make the operations on it. This prediction is further explained in my article Granular Keyword Driven Testing.
Driver Layer
This layer is responsible for matching the GUI operations specified by the Test Implementation Layer with the API of test automation tool being used. Let's start with an example:
? ? public class HtmlDriver
? ? {
? ? ? ? protected BrowserWindow browserWindow;
? ? ? ? public HtmlDriver()
? ? ? ? {
? ? ? ? ? ? var browserWindows = Agent.Desktop.BrowserApplication("https://BrowserApplication").FindAll<BrowserWindow>("https://BrowserWindow");
? ? ? ? ? ? //Run on the last browser window open:
? ? ? ? ? ? browserWindow = browserWindows[browserWindows.Count - 1];
? ? ? ? ? ? //Bring window to front:
? ? ? ? ? ? getBrowserApplication().SetActive();
? ? ? ? }
? ? ? ? public void clickElement(string xpath)
? ? ? ? {
? ? ? ? ? ? //Allow partial xpath as property=value:
? ? ? ? ? ? if (!xpath.Contains("/"))
? ? ? ? ? ? ? ? xpath = "https://*[@" + xpath + "]";
? ? ? ? ? ? browserWindow.DomElement(xpath).Click();
? ? ? ? }
? ? }
This class implements the clickElement method for web applications. It is an excerpt from our code, which uses SilkTest product behind the scenes. This magic Agent class comes from SilkTest API.
So the programmer writing his/her own test automation code does not deal with magic Agent class etc. He/she is only responsible for determining the xpath of the GUI object to work on. He/she is even able to specify this object using a single property such as "id=txtUserCode".
This class also does test automation tricks such as bringing the browser to the front or handling multiple browser windows, which are quite a detail for domain programmers in development teams.
Summary
In big organizations, there are hundreds even thousands of tests to be written and maintain, which will require too much domain expertise. A single test automation team cannot do this task alone.
So it seems to be a better approach to help domain teams write their own test automation by providing them a simple to use test automation framework. This article proposes one such framework.