A Test Automation approach: Object Oriented frameworks - Part-III [ Design ]

In this post, I'll try to explain the design of the Object Oriented framework with an simple example.

For the benefit of explaining the process I'm describe a fictitious banking application. Assume the banking application has three modules 'Savings Bank module', 'Current Bank module', 'Loans module'. The banking application supports user actions such as 'Create an Savings bank', current account', 'create a loan account', ‘close account’, ‘credit cash to account’, ‘deposit a cheque’, ‘enquire balance’, ‘check transactions’, ‘debit an account’. Also the banking application has administrative modules such as login module, customer maintenance module etc.

In a traditional automation approach, design of the automation begins with identification of the user cases/test cases that requires to be automated. The next step will be to identify the GUI components associated with the user cases identified and coding for these flows. This code will perform user actions such as enter values in the text boxes, click on the buttons, reading values from the GUI etc. A simple test case for opening an account and depositing cash will look similar to the code below after automation. The code below is an example written in a tool/language independent format.

Login:

Enter BankEmployeeName :'user1'

Enter password :'*******'
Create Account:

Verify home page
Click on 'create account link'
Enter radio button: 'savings bank'
Enter account holder name: myCustomerName
Enter address: xxxxx .
...
....

Click Ok

Verify Account creation:

Click on 'Search account'
Enter account holder name: myCustomerName
Click Ok
Read account holder name
Compare value with 'myCustomerName'
Read account holder address value
Compare value with 'myCustomerName'
...
...

Deposit Cash:

Click 'Cash Deposit'
Enter account number: xxxxx
Enter amount: xxxxx
Click OK

Verify Cash Deposit:

Click Check Balance:
Read account balance value
Compare value with 'yyyyy'

As you may have noticed, the test case depends on detailed design of the GUI. Each step in the test case relies on individual components on the GUI. For the case of simplicity I've not included exception handling in the above code.
With the Object oriented approach, the design do not start with the set of test case/user cases that requires to be automated. The design of the framework will view the banking application in terms of how as an end user will perceive it. For the object oriented framework approach, the banking application will be a considered as objects with actions on these objects. For the sake of example, the following will be the objects and methods on these objects.
Class Login:

Method: Login(user_name, password)
Method: Logout

Class Account:

Method: InitAccountObject()
Method: CreateAccount(.....)
Method: DepositCash(amount)
Method; EnquireBalance() .
Method: CloseAccount()
Method: GetAccountDetails()
Method: TransferBalance(amount, otherAccountObject)
Method: VerifyAccount()

With this approach, the complexity of the GUI and the actual intricacies of the workflow are encapsulated in the business classes that are defined as part of the framework. With an object oriented framework approach, the above test case will look like below.

Class : TestCaseOne:

Method: InitAccountObject(accountType)

Method: TestSteps: employee = New Object Login('user1', '*******')

myAccount = New Object Account();

myAccount.CreateAccount(accountType.......)

myAccount.VerifyAccount()

integer myOldBalance = EnquireBalance()

myAccount.DepositCash(amount)

integer myNewBalance = EnquireBalance()

Verify myNewBalance == myOldBalance + amount

As you may notice, in the above test case, there's a very clear demarcation of the GUI components and the business components. All the intricacies of the GUI is hidden away inside the business classes/methods. The automated test case, in this case 'TestCaseOne' only deals with the business aspects of the test. With this approach, the automated test case is insulated from the details of the GUI. With any changes to the GUI, the test case will not have to be redesigned. This translates into very good maintainability of the test cases. The second and most important advantage of the Object oriented framework is the test case extensibility. We could 'extend' the above test case to test for various related tests. For example, we can extend this test case to test for SavingsBankAccount, CurrentAccount and Loan account as below

Class SavingsBankAccountTest extends TestCaseOne
Method: InitAccountObject('SavingsBankAccount')
Class SavingsBankAccountTest extends TestCaseOne
Method: InitAccountObject('CurrentAccount')
With this approach, manual and exploratory testers can automate regression tests cases without the technical knowledge of the automation tool. Testers however should have fundamental knowledge of object oriented concepts and knowledge of the programming language.
In my next post, I'll explain the real benefits out team has achieved by implementing this approach of automation and also delve into how we've been analysing and evaluating the results of the test executions.