Background

This was a medium sized project, mainly related to file management and developed with Java J2EE.

From a functional point of view, the application is not particularly difficult (except maybe the typical automation problems such as Excel exports and email alerts). This application worked together with another Java application that was completely available to use and that we could control.

The main challenge lay here was the use of SmartGWT as a framework for the presentation layer.

The test plan was entirely managed by the Testlink tool.

Technical environment

The development environment was fairly standard: Windows 7, Eclipse, Oracle XE, Java 1.6.

The integration environment and the test environment were hosted on Ubuntu servers. For integration, Jenkins was the tool used to run the tests on different platforms (Windows, Linux, Firefox, IE).

Although still in beta when the project started, the 2.0 version of Selenium was used.

Setup phase

The setup phase needed some special efforts on two points: SmartGWT and Jenkins.

For Jenkins, the configuration of certain specific plugins, some with bugs, took more time than planned. It was particularly the reassembly of test results in Testlink that was a challenge (in order to maintain, at all times, an overview of the entire test campaign implementation, both the manual part and the automatic part).

For SmartGWT, the identifiers of the graphic components are dynamically generated, which is a problem to test automation. Workarounds are provided with the SmartGWT framework, but in practice, a lot of it remained difficult, sometimes undoable.

Results

Despite the various challenges encountered (not counting the issues related to the interfaces with outside web elements), we were able to automate 65% of the tests.

The tests, developed mainly in Eclipse (not systematically through Selenium IDE), are mostly simple to maintain, although some Selenium functions had to be overloaded to support SmartGWT.

The development of automated tests also had an impact on the development of the application itself: some coding rules were put in place to facilitate test automation.

The post Selenium and SmartGWT first appeared on Progideo.

Background

As part of an important project (> 3000 man/days) developed in ASP.Net and interfaced with the Autonomy search tool, our goal was to automate regression tests.

The application contained many very specific screens and rich graphical components (mostly from the Telerik libraries, from same software editor as Test Studio).

The application also needed to handle many external files, mostly PDF, Word and Excel files. The application was also based on a set of shared databases with existing applications, to which we had no access for privacy reasons.

Technical environment

This was essentially a Microsoft environment with developers running Windows 7, Visual Studio 2010 and SQL Server 2008.

The test servers and integration servers were virtual servers, composed of several servers for application, database and search engine Autonomy. These servers also simulated the customer environment with a dedicated AD.

The tests were run on Internet Explorer 7.0.

Continuous integration was managed by CruiseControl.NET.

Setup phase

The tools setup did not cause any particular problem, as all were managed from within Visual Studio.

The Test Studio tool was still in its infancy, but the Telerik support enabled us to quickly resolve or work around the issues.

We mainly had to find ways to manage the many technical interfaces.

Results

Automation was particularly difficult because of the large number of interfaces to databases (not always directly available) or external files. We had to put in place “stubs” and find tricks to validate the correct operation of the system.

The test coverage was satisfactory for the user interface portion, but incomplete for certain processes that are not directly accessible to the user.

Running the regression tests therefore still leaves a large part that needs human intervention, mostly however to check the results in files or by email.

The post Test Studio and ASP.Net first appeared on Progideo.

Background

This project’s objective was to develop a set of automated functional tests for a web application developed using the PHP Yii framework.

The application mostly consists of “CRUD” type screens for data creation, modification and visualization.

The tests were developed together with the code. Each delivery of a module or screen was accompanied by a set of functional tests, especially for validating the business rules associated with the creation or modification of the data.

The tests were thus used to validate the developments at a unitary level and for regression testing.

Technical environment

The development environment uses the Ubuntu OS, NetBeans IDE and MySQL Workbench modeling tool.

The integration server is a Ubuntu virtualized server, acting as an SVN server and a continuous integration server through phpUnderControl (later migrated to Jenkins).

For the execution of functional tests, dedicated virtual machines were installed, with different OS (Ubuntu, Windows XP, Windows 7) and different browsers (IE6, IE8, Firefox, Safari, Chrome, Opera).

It uses the version 1.0 of Selenium.

Setup phase

The Yii framework natively integrates the ability to create functional tests with Selenium.

The implementation of test automation is relatively simple and standard.

Moreover, the application is very uniform and it was therefore simple to factor the test procedures in order to expedite the drafting of tests and facilitate maintainability.

However, we had to overcome some technical difficulties, particularly for the implementation of the continuous integration server and the use of PHPUnit to run the functional tests.

Results

In the maintenance phase, functional tests are performed at each change of the code.

The regressions are detected immediately, and the update of functional tests, in the context of this project, are very inexpensive (whether for correction or evolution).

The risk linked to maintenance is extremely low. Whatever the impact of the change, regardless of the person who performs the automated functional testing, there is a guarantee that the quality of the application will be maintained.

However, we must ensure that the tests are well maintained, together with the code. If the test of new features is not automated, or if the tests that fail are simply removed, the system can quickly lose its effectiveness and the cost of maintenance will increase sharply.

The post Selenium and Yii first appeared on Progideo.