SpiderTest: do-it-yourself self-tests

Quite often, among beginners (and not even very) testers, one has to hear: "if I could write autotests, I would ...". As a rule, these “if” guys are limited. To the question: “Why don’t you learn to write?” most often they answer: "Programming is not mine." Indeed, for those for whom programming is a dark forest, plunging into the world of autotests is quite difficult, because the script itself will not write. In this article, I would like to talk about how to become a cool autotester from a manual tester.

Rummaging around 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 else remembers something, please write in the comments).

When searching, various test 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 QF-test) turned out to be, in fact, an environment for development, 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 into a script, but such recorded tests do not lead to anything good (and indeed this is not solid). The tools themselves are not bad (for example, SilkTest), but they are absolutely unsuitable for a beginner autotester.
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 had a minus: a completely unattractive price (about 1200 euros).

Before weaning down completely, dropping my hands and continuing to use Selenium WebDriver together with Cucumber, I came across the application of Konstantin Trofimov (my colleague 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 intended for distribution, so it does not have a chic interface with fashionable pop-ups, licked forms and an advanced control panel, but the utility has powerful tools and a low entry threshold, 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 make up xpath, and even a housewife can teach this! (This article and this one are well-informed). Now the project has begun to develop 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 to test 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 compiled in accordance with the principles of xml.



Let us return to the main SpiderTest form: in the left window is a list of tests, and in the right window is a detailed description of the procedures performed in the test. Flags indicate the 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, click on the "Edit." (“Edit” author's note).



In the test edit form, select the sequential actions that the browser will take during the test.
The name of the columns clearly indicates their informational: the action that needs 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 text information) and, finally, the description of the steps for testing in human language ( this description falls into the main form).
The above list of actions seems to me to be exhaustive; in autotests on ruby ​​I used much less functionality.

• Go to page - open the specified page in the selected browser;
• Go to tab - switch to another tab. It is possible to indicate 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 the id / class / name / xpath of the link (but this only works for the tag);
• Enter text - the procedure for entering text into the specified element;
• Find element - search for an element on the page;
• Click on an element - imitation of a click with the left mouse button on a specified element;
• Hover over an element - imitation of hovering over an element;
• Pause - stop the test for the specified time (in milliseconds);
• Compare element values ​​- comparing 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 signs *;
• Check for the absence of an element - search for an element on the page (the waiting time for the element to appear on the page is 200 milliseconds), if the element is not found, then the step is considered completed;
• Comparison of attribute value - comparison of the value of the specified attribute of the element with the specified. The attribute should be specified as follows: attribute | value;
• Clear field - clears the specified field from the entered text;
• Compare the number of elements - search on the page for elements according to 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 which case unused columns will be unavailable 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 can arise in the preparation of tests is the definition of search criteria. The list contains 5 types of criteria: id , class , name , xpath and css . Criteria are ways to get to the attribute with which you need to perform an action, personally I choose xpathand I prescribe it in the “search parameters” column and do not fool, but many consider this a masochism when an element has an id , but then to each his own.

When editing the test is completed, you have to choose 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 by browser, but information about the behavior of the application in different browsers will be received.

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

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 that way, but it wasn’t here. The application is not as primitive as it seems at first glance.

Steps and Elements
The next interesting feature when creating an autotest is to create a list of commonly 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” field 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 “Change list / insert from list”, which can be accessed from the “Actions” menu.



Variables
Another "trick" can be considered the use of variables. Even a novice tester should know about the usability of variables in programming.







A variable is entered into the test structure using the $ variable $ signs.



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



It is worth noting that when the test is run in different browsers, the variables guid_once and random_once will generate their own in each browser.

There is one more feature of this application that I would like to talk about - it 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 who find something unnecessary, and something in their opinion will be missed. Share your thoughts on how SpiderTest can be improved in the comments, and I will contact the author and share your ideas.