Blog
One of the most frequently asked questions about software testing automation is "where should I start learnig an automation tool?". In this blog post we will try to give an answer to this question without using a concrete tool.
One of the most serious problem of automated tests ( especially GUI level tests ) is synchronization between test execution and application under test work. In other words, all actions being performed by the automated test have to be executed exactly at the moment when application under test is on the correct state allowing to perform required actions. Otherwise we are at risk to come across the situation when test tries to click on some object, enter some text while the form to perform these operations on is simply not available. As the result, our test goes by its fixed steps but the results and system behavior is unpredictable. And if at the same time there are no recovery scenarios the whole test set execution may be failed at once.
Every so often during tests automation we may encounter steps description like "Repeat steps 1-12" or even more interesting like instructions to repeat all steps using some specific settings. It means that we have to duplicate some code during automated tests development. But excessive code duplication may cause a number of maintainance problems. Any changes have to be made in all repetitive code occurences. And this makes additional time loss. It can be avoided in the following ways:
From time to time while reading different publications we may find the opinion that any "heavy-weight big vendor" automated testing tool ( actual tool names are usually omitted ) is associated with such thing as unmaintainable tests. But at the same moment any hand-made solution or even simple library is positioned as something flexible and easy adaptable. Of course, I also prefer taking something little and simple and using it effectively rather than taking something heavy-weight and thinking hard about how to bind it to my processes.
During development of automated tests as well as any other program components we have to make our code satisfy the following characteristics:
- Readability
- Extensibility
- Transportability
- Optimality
- Correspondence to requirements
- Maintenability
- Others ( some project-specific features )
Test automation success highly depends on the way the tests are designed. Design defines how fast automated tests can be developed, how these tests are suitable to read and understand the concept, how they can localize the problem and how they can reveal problems at all. All these points are highly depend on tests structure. It means that test design takes essential part in test automation. It is test scenario or test workflow description which is basis for automated test implementation. That's why direct impact on test design stage may highly improve test automation process. Well, in order to improve test automation any test scenario requires the following:
JScript operator is used for getting type of the variable. There are six possible values that typeof returns: "number," "string," "boolean," "object," "function," and "undefined".
In this post we will improve typeof operator so that it can also return "date" and "array" values for corresponding data types.
There are undocumented features in any computer program. Some of them are added specially (e.g. Easter Eggs), other can be programmers' mistakes, and some of them are just unimplemented features.
In this article we will describe one of the SilkTest's undocumented features, the 2nd argument for LogError function.
In this post you will find an example of the function, which delays script execution and displays the time left for execution in the TestComplete Indicator.
Automated Testing Service Group wishes you a Happy New Year!
May all your dreams come true in 2008!
ListPrint(lsOut)
However, this event will work only if unexpected window prevents TestComplete to work with application. In case of non-modal windows, or if the window doesn’t affect tested application, this event will not occur and TestComplete will continue working.
There are several ways of the opening different files in SilkTest. In this blog post we'll describe 3 ways and when it is better to use them.
A strange behavior of TestComplete was encountered when trying to work with standard IE File Download window. This window appears when user tries to download a file from Internet.
The problem was that TestComplete logged about successful clicking on the Open button, however no expected result happened and window just stayed as though no action was done.
When recording actions in TestComplete, it uses ClickButton() method for clicking standard push buttons.
For example,
var w = Sys.Process("WindowsApplication3"). WinFormsObject("Form1");
w.WinFormsObject("button1").ClickButton();
It is recommended to replace it with method Click() because standard button can be replaced with own-drawn one, or with some third-party control with the same name. In this case ClickButton() method won't work properly.