Automated Testing

Introduction

This document presents the basics about Test Automation as is planned for Openbravo ERP testing.

Background

References

Totally Data-Driven Automated Testing.

Daily build execution

The automation is executed on a daily basis. See more details.

Testing OpenbravoERP

Current automation test cases are managed in Testlink. You need to register in order to view the Smoke Test.

Scripting Guidelines

In order to have useful and robust scripts, and to extend script's life among QA cycles, there are a list of best practices.

Branches and Versions

Every new version of the ERP will make some tests to fail, due to fixes and modifications done on the application.

We must keep automated testing repository synchronized with development, so we can execute tests on current stable application, on the nightly build and on the previously published version.

Thus, there will be three branches:

• main
• 2.3x
• 2.40

Base URL

The whole test suite should have a centralized way to change target URL. I should can change it once and that would make all scripts to point to new URL.

Example:I have to test a 2.40 release located at http://127.0.0.1:8180/openbravo240 a 2.50 project located at developers machine http://192.168.0.1:8880/openbravo and a daily build smoke test at http://192.168.114.1/openbravo_postgres

So, script should not have hardcoded URLs:

Script 1 (Wrong)

browser = new DefaultSelenium("localhost", 4444, 
	"*chrome", 
	"http://127.0.0.1:8180/");

Script 2 (Wrong)

browser = new DefaultSelenium("localhost", 4444, 
	"*chrome", 
	"http://127.0.0.1:8180/");

Instead of that, a config file should be created:

Config file

baseURL = "http://127.0.0.1:8180/"

Script 1 (Correct)

browser = new DefaultSelenium("localhost", 4444, 
	"*chrome", 
	baseURL);

Script 2 (Correct)

browser = new DefaultSelenium("localhost", 4444, 
	"*chrome", 
	baseURL);

Browser

The same as above, if I have to repeat the same test on Firefox 2, Firefox 3 and Internet Explorer, the "*chrome" should be also a parameter.

Avoid duplicated code

Scripts are usually recorded following user's steps. That means that recorded scripts will repeat code if the same task is needed in different scripts.

To avoid this problem, after recording a new script, it should be analysed to factor code onto functions or sub classes.

The most relevant example is Login. If I have

browser.type("user", "userA");
// enter the password
browser.type("password", "userA");
// click login button
browser.click("buttonOK");

on every page, and something change on Login page (for example, buttonOK name is changed to loginButton) a full search and replace will be needed.

Instead of that, a single function will make the change trivial and also the main script will keep cleaner

Before factoring

...some selenium code...
browser.type("user", "userA");
// enter the password
browser.type("password", "userA");
// click login button
browser.click("buttonOK");
...more selenium code...

After factoring

...some selenium code...

doLogin("userA", "userA");

...more selenium code...

Use assertions

Assertions are the basis for deciding if a script executed correctly or not. This are the must have assertions for all scripts:

• The initial step of the script was executed
• The last step of the script was executed
• All the Process completed messages appears.
• The Issues to verify section of testcase scenarios.

Example: Consider this test case:

• Steps for Import language:
  • Login as Openbravo/openbravo
  • Go to General setup->Import/Export translations
  • Select Italian(Italy) language
  • Click on Import button
  • Compile the application and restart tomcat

• Issues to verify:
  • Login as Openbravo/openbravo, change on Role Information the language into italian and verify main menú and other windows are shown in correct language

In this case, a sub script should be added at the end of the main script:

...some Selenium code...
...launch of compiling process
selenium.assert(doVerifyLanguage());
...more Selenium code...

boolean doVerifyLanguage() {
   doLogin("Openbravo","openbravo");
   doChangeRoleAndLanguage("SampleClientAdmin","italian");
   //Verify a menu entry
   selenium.assert(cell(254,2),"Ciclo Ativo")
   //Verify a Sales Order field
   selenium.click(cell(269,2));
   selenium.click(cell(289,2));
   selenium.click(cell(291,2));
   selenium.assert(paramDate.label,"Data")
}

Element referencing

It is very important to use absolute references, such ID and Name, so changes on interface layout will not affect execution. Avoid using DOM references like

table[@id='grid_table']/tbody/tr[1]/td[2]

unless is the only way to get a reference.

Proper logging

In case of an error, the exact point of the error should be logged, so the QA team could easily verify error's origin.

• Sometimes the error is a bug that should be reported.
• Sometimes the application changed and the script should be updated.
• Sometimes is a environment issue.