SpiderTest: DIY AutoTests

Quite often among beginning (and even not so) testers one has to hear: “If I could write auto tests, I would ...”. As a rule, these “if” guys are limited. The question: "Why do not you learn to write?" Most often answer: "Programming is not mine." Indeed, for those who are programming a dark forest, it is rather difficult to dive into the world of autotests, because the script will not write itself. In this article I would like to talk about how to become a cool auto tester from a manual tester.



Having rummaged on the Internet, I found the most popular tools for automated testing of interfaces:

• SilkTest;

• HP QuickTest Pro;

• QF-Test;

• Rational Robot;

• TestComplete;

• TestPartner;

• (who remembers something else, please write in the comments).



When searching, various testing frameworks, such as Selenium, Cucumber, Watir, Behave, were deliberately ignored, I was interested in ready-made tools.

However, all the utilities presented above (with the exception of the QF-test) turned out to be, in fact, a development environment, i.e. they suggested using their “simple” scripting language to create autotests. As a simplification, it was possible to record actions, and they would be formed in the script, but such recorded tests do not lead to anything good (and in general it is not solid). The tools themselves are not bad (for example, SilkTest), but they are absolutely unsuitable for the novice auto-tester.

The QF-test turned out to be an attractive workhorse, capable of testing both web interfaces and desktop applications. Using it, you do not need to write scripts and, in general, the work in it is built conveniently. But this utility has a minus: a completely unattractive price (about 1,200 euros).

')

Before you finally feel sad, give up and continue using Selenium WebDriver for a couple with Cucumber, I came across an application by Konstantin Trofimov (my colleague, a QA engineer), which I found incredibly promising. It is called SpiderTest, you can download and familiarize yourself with it here .



The application was originally created for its own use and was not supposed to be distributed, so it does not have a smart interface with fashionable pop-up windows, licked forms and a developed control panel, but the utility has powerful tools and a low threshold of entry, and most importantly does not use scripts. All operations performed by the user are in the list of actions. To create an autotest you only need to be able to compile xpath, and even a housewife can be trained in this! (This is an article and this one is well brought up to date). Now the project has been developing intensively and we hope that SpiderTest will become a common and useful tool in the arsenal of any QA engineer.



Application interface

Acquaintance with SpiderTest begins with the main form in which it is supposed to create a test kit - a set of tests for testing certain functionality. The test suite is saved as a single file in the .sff extension.

If you open the completed test suite file with some text editor, such as notepad ++, you can see that its structure is composed in accordance with the principles of xml.







Let's return to the main form SpiderTest: in the left window a list of tests, and in the right window - a detailed description of the procedures performed in the test. Flags mark tests to be performed.







Having come up with a name for the first test and saving it, we get the opportunity to go into the form of its creation. To do this, you need to click on the "Ed." Button.







In the test editing form, select the sequential actions that the browser will perform during the test.

The name of the columns clearly indicates their informational: the action to be performed, the search parameters of the object to perform the action, the value of the parameter (where necessary, for example, going to the website or comparing textual information) and, finally, a description of the testing steps in human language ( this description falls into the main form).

The above list of actions seems to me to be exhaustive; in ruby ​​autotests, I used much less functionality.



• Go to page - opens the specified page in the selected browser;

• Go to tab - switch to another tab. It is possible to specify the serial number of the tab, or you can specify the Title;

• Run jscript - execute the specified jscript;

• Take a screenshot - create a screenshot;

• Open in a new tab - open the desired page in a new tab: you can specify the address in the "Value" field, or specify id / class / name / xpath links (but this only works for the tag);

• Enter text - the procedure for entering text into the specified element;

• Find item - search for an item on the page;

• Click on an element - imitation of a left-click on the specified element;

• Hover over an element - imitation of mouse over an element;

• Pause - stop the test for a specified time (in milliseconds);

• Compare values ​​of elements - comparison of the values ​​of all found elements with the specified one; if at least one value is not equal, then the step is considered failed; it is possible to compare the value partially, for this it is necessary to place the value between the characters *;

• Check for missing element - search for an element on the page (the time it takes for an element to appear on a page is 200 milliseconds), if the element is not found, the step is considered to be passed;

• Comparison of attribute value - comparison of the value of the specified attribute of the element with the specified one. The attribute should be specified as follows: attribute | value;

• Clear field - clears the specified field from the entered text;

• Compare the number of items - search for items on the page by the specified criteria, and then compare their number with the specified;



Some actions do not need to fill in certain columns (search parameters or values), in this case, unused columns will be inaccessible for editing and marked in gray - this, by the way, makes life easier when you confuse what and where to enter.



The only difficulty that may arise in the preparation of tests is the definition of the search criteria. There are 5 types of criteria in the list: id , class , name , xpath and css . Criteria are ways to get to the attribute with which you need to perform an action, I personally choose xpath and prescribe it in the “search options” column and don’t get fooled, but many consider it masochism when the element has id , but there’s a different one for you.



When the test has been edited, you must select the browser in which the tests will be run. One of the great features of the application is that you can run the test in 4 browsers! True tests will be performed sequentially, i.e. browser behind the browser, but information about the behavior of the application in different browsers will be obtained.



It is worth noting that before using all browsers except firefox, you need to register the drivers in the system variables, or throw these drivers in the folder with the application.



After all the above procedures, click on the "Run" button and enjoy, the program does the work for us. This could be finished, because everything is already working, but it was not there. The application is not as primitive as it seems at first glance.



Steps and elements

The next interesting feature when creating an auto test is to create a list of frequently used steps and elements. This list is needed to simplify the writing of the script.







Suppose there is an action that is regularly performed (go to the main page of the application), it is reasonable to add this action to the list of frequently used ones and not to prescribe it in the future, but simply call from this list (optimization!). The list of steps can be edited (however, only the “value” and “description” fields can be edited, all other parameters are not available).



The list of frequently used elements, similar to the list of steps, is needed for quick access to the elements used regularly. Unlike steps, all fields of an element can be edited.



To edit lists there is a special form “Edit List / Paste from List”, which can be accessed from the “Actions” menu.







Variables

Another use of variables can be considered one more thing. Even a novice tester should know about the convenience of using variables in programming.















The variable is entered into the test structure using the $ variable $ signs







Variables, by the way, are different. You can choose one of 7 presented methods.







It should be noted that when running the test in different browsers, the variables guid_once and random_once will generate their own in each browser.



There is another feature of this application that I would like to talk about - this is interaction with CI servers (in other words, with continuous integration servers), but this is already a rather complicated topic and I plan to talk about it in the next article.

PS There will always be people to whom something will seem superfluous, but something in their opinion will be missed. Share in the comments your thoughts on how to improve SpiderTest, and I will contact the author and share your ideas.