How-To

Continuous Integration Systems (CI-Systems) support the teams at their steady work on the various sub-steps of the software development process. The main objective being the improvement of software quality.

There‘s no way around using variables if a test suite has to to be flexible, reusable, and elegant. But where are variables set? Which value of the variable is used if I defined multiple ones at different positions? And how can I find out? This article aims to answer these questions.

If you are working with QF-Test scripting nodes, no matter whether you prefer Jython, Groovy or JavaScript, you will come across the QF module sooner or later. This module, accessible in all script nodes and script terminals via the variable qf, holds a bunch of helper methods designed to make the life of a script programmer easier.

You are working with QF-Test and something doesn’t work as expected? Then you can (as usually) search the Internet or do research at StackOverflow… A faster way is going on our channels …

Some days ago I had the pleasure to visit a Meetup Venue here in Leipzig, Germany. The topic was very interesting – “Experience with the introduction of Test Automation”. Many of the participants consider Web UI testing very fragile and cumbersome to keep in “Tests OK” status that’s why I I decided to write this series with the topic: No coordinates based Events and no Image based checks! QF-Test is smarter than that!

In order to simplify test suite editing it is possible to assign colored marks to nodes. This feature is especially (but not only) helpful in the context of complex find and replace operations – in this case, the color markers can for example be used to indicate that a node still needs revision or that a node was edited successfully.

QF-Test uses semi-hard events as default (based on web framework, browser and browser version, OS etc), but not all cases. There are three event types available.

In some cases it is helpful to disable nodes temporarily. Here is a short article how to do this.

While testing an application, one of the most important steps is to verify that the actual state of the application is correct.

In most cases we are dealing with more or less straight-forward UI components,such as buttons and text fields. Nevertheless we often have to deal with morecomplex UI components like trees, tables and lists too. These UI components have sub-items.

Sensitive information like passwords should be treated with care. However often tests need to fill out a login form and thus these tests require to know the password.

Via the run log QF-Test provides a detailed log about the actions it executed during a test run. The overall results of this run log can be summarized in other reports like the HTML/XML/Junit report.

Procedures (also called function or subroutine) may be used in order to solve often (re-)occurring challenges.

Even in early stages of development Capture & Replay offers a easy way to create tests. An early start of such regression tests and the assignment of unique names / IDs are the most important bases for efficient (due to stable recognition) test automation.

Sometimes it is necessary to perform mathematical calculations in QF-Test, e.g. in order to calculate the expected height of a UI element in dependence of the complete window size or the exact clicking position for a mouse click.

A high percentage of executed code indicates a little probability of undetected software bugs.