4. Avoid using conditionals
Sometimes, the behavior of the environments in software testing services can be unpredictable. It seems wise to use a conditional in a test for such cases. But there is a number of problems with this method. One problem is the same as the problem that appears after using indexes in place of specific locators: so if the application under testing is exposed to changes, the automated test may occur completely unexpectedly, causing false failures (or worse, false positives) and making maintenance very hard. The test would never display that a bug had been entered if you encounter another problem. It is a problem when one branch of the conditional statement could (erroneously) vanish altogether.
5. Sort order must be examined with regular expressions
The correct order of the application’s appearing aspects is often significant to the user. It’s a good idea to use automated testing to make sure that the order of things is correct: whether it is text on the page itself, columns in tables, or elements in a list.
Let’s suppose there is a kit of things. These things should come in sight in an order called “first,” “second” and “third.” You can create automated tests that use some sort of permanent expression to check the order. Here is an example of exploiting a simplistic kind of permanent expression. Its name is “glob.” Such expression is available in automated test tools, and in particular in Selenium:
| getText | glob: first * second *three |
| click | sort_thing |
| getText | glob:three*two* first |
This is what the test’s first step examines, that the text “first “ is running before the text “two” and the text “two” is followed by the text “third.” The “*” character points that the test will permit any characters at all between “first,” “second,” and “third.” The test’s second step clicks somewhat to sort “first,” “second,” and “third” in reverse order. After this, the test’s third step examines that the sorting was definitely proper.
6. Want to make reusable random data? Use JavaScript!
Below there is a concrete example of a brilliant practice for specific kinds of test data, particularly using Fitnesse and Selenium. As you can see, the test needs to enter a Taxpayer Identification Number that is unique, then verify that TIN has in fact been entered into the application:
| type; | tin | javascript{RN =Math.floor(Math.random()*9999999);while (String(RN).length < 8 ) { RN=RN+’0′;}} |
| $TIN= | getValue | tin |
| click | link=Save |
| type; | search | $TIN |
| GET SEARCH RESULTS CONTAINING THE TIN |
JavaScript will be evaluated by Selenium in-line. The test’s first line types into a cell whose id value is “tin,”, an unexpected 9-digit number produced on the fly by using JavaScript as an argument to the type() action. Then the 9-digit number from the “tin” field in a variable called “$TIN” is stored by the second line, which uses a feature of FitNesse. Then a 9-digit number is typed into a field whose id value is “search.” This is a useful and elegant way within the test itself to process test data required to be unique. The same attitude should be available in any reasonable framework or test tool.
7. Stop repeating yourself
As it was already mentioned, looking forward to when an element in the application will appear is a useful habit. Fairly often, there is a case that once the element appears, the test will want to work with that element. It is a pretty good habit to abstract widely spread actions into their own approaches or modules, then to call those actions from the tests as required. Next, an example of abstracting the wait-for-and-click action is mentioned. The used syntax is FitNesse and Selenium:
!| scenario | Wait for and click | elementLocator |
| waitForElementPresent | @elementLocator |
| click | @elementLocator |
We need only put down from a test itself:
| open | www.foo.com |
| Wait for and click | link=Hello from Foo! |
Only one line of typing is saved in this example. Pay attention to the fact that if “Wait for and click” is performed dozens or hundreds of times in a test suite, this is a significant enhancement in readability and maintenance. Here are some other examples of actions to be abstracted to their own modules: might be selecting all the elements of a list, logging in, etc.
Possible challenges of functional automation testing
Like any testing or development activity, functional automation testing has several potential challenges companies can encounter. Here are the most common challenges your organization may face when doing automated functional testing:
- Insufficient technical knowledge. Automation testing is a challenge for teams or individuals without relevant experience. This issue can be overcome by allocating time for training and getting familiar with the project.
- Incomplete requirements. When starting to automate functional tests, teams often encounter the problem of lacking requirements and proper documentation, which leads to spending extra time formulating the guidelines.
- High initial costs. Even though automation is known to save money in the long run by automating repetitive tasks, many test automation projects start out as expensive. Doing automated testing takes setting up the automated functional testing process, especially when paid tools or additional hiring decisions are involved, which means automated functional testing requires extra resources.
Final thoughts: Improve your software quality by automating functional testing
Functional test automation is by no means a universal problem solver or a one-size-fits-all solution. Test maintenance takes time and effort, automated test scripts are not always powerful, and don’t deal well with certain types of testing like usability or user interface testing, which usually cannot be automated. Moreover, functional automated testing doesn’t always search for bugs effectively – these are the biggest complaints about it.
But well-designed automated tests are totally different. They are not difficult to maintain; they are strong in that they verify the state of the application being tested for aspects significant to the user and to the application itself, and well-designed automated tests can definitely find bugs and speed up the testing process while saving time and money for the whole team. So there is definitely a place for automated functional testing in Agile or any other methodology — but only as long as it’s used properly, and the decision to automate your functional tests will benefit your test cycle in one way or another.
Additionally, functional automation testing services can be a great alternative to performing quality assurance within the means of your own company. If you don’t already have a team experienced in automated functional testing and need to start the project quickly, a reliable tech partner can help you get the results sooner than you expect.
