Test it, don’t just try!

The model-based approach and the keyword-driven test cases make our solution technically independent from the tested applications, which eliminates the requirement of extensive coding skills.

The test code only contains the test logic, this ensures readability, transparency and maintainability. The technical independence ensures that those without IT qualification can access the test automation tasks.

Testing and test automation problems can vary based on the various use cases of the organisation. The capabilities and services of the ACE toolkit make it useful primarily in the following use cases.

• Development support: documented verification of the quality conformity of the end products, reproducing the errors of the intermediate states,
• Support for client-side UAT and delivery: creating the tests and reports of the functions and modules in the quality control process,
• Operational support: support for the execution of the performance, durability and similar test from the non-functional requirements of operation, besides the functional, integration and end-to-end tests, to ensure conformity with SLA or other requirements.

The tool can be flexibly integrated into the cooperation process between the typical participants of the use case.

The test automation workflows can be separated into phases, and based on these the work can be assigned to various roles.

The test planning, preparation, automation, evaluation, and supervision tasks can be divided between clearly separated roles: business analyst, technical preparer, implementer and test manager.

The roles can be further divided or joined among the personnel performing the various roles.

The test laboratory design supports the group work of the different roles.

We have ready-made interface solutions for many technology platforms present in the enterprise environment, and we have utilised them in many successful test projects and in our clients’ technology pilot projects.

These include web, web2, AJAX, and fat clients: Java Swing, Java SWT, Java Eclipse RCP, Win32, Accessibility, .NET, SAPGUI, but in extreme cases we have also used image analysis and OCR technologies.

This list is ever expanding, we are well versed in creating new technology interfaces.

As with any project, test automation can only work properly and deliver dependable and predictable results, if the proper prerequisites are guaranteed and the work is carefully prepared. Preparing the test automation usually includes meeting the following conditions:

• correctly selected toolkit (just like ACE),
• staff prepared for the use of the tool,
• prepared environment (test laboratory and application test instance),
• test cases, test scenarios are designed with verification conditions,
• knowledge about the use or creation of test tasks,
• (the knowledge of the business rules of application logic can be helpful).

Selecting the correct goals contributes to the success of a well prepared project, we recommend taking into account the following:

• Select those processes and functions for automation that are frequently tested. For the quickest return on the invested work replace as many of the existing tasks as possible.
• The execution of a process or function also includes its preparation. When selecting the tasks, take into account how you can ensure that the prerequisites are met (navigation, test data, application state).
• The coverage goals are an integral part of rating the test suite (how many and what kind of tests are required for reaching the desired results).

Here are a few more things to take into account when planning:

• Don’t forget that the automated test must include an appropriate number of testing conditions, otherwise only the process automation will be valid, and not the test results.
• We design the test suites for the version of the application that is current when creating the test suite. Avoid the testing of development instances, work on a separate test instance, with controlled version tracking. Follow the changes of the test instance with the planned maintenance processes.
• Carefully determine the conditions of the automatic evaluation, “false negative” and “false positive” values are misleading, and can severely compromise the success of the testing.
• You have to regularly run and evaluate the test suite to keep it up-to-date and operational. The project must also include the running and verification of the tests. Only a correct test instance can provide real validation, sadly test can also contain bugs, these must be found and corrected.

This list could go on and on, but this will be enough for this Q and A format. We are happy to answer any further questions, and we hope we can welcome you as one of our clients soon.

If we were looking for employees, we would post a job advertisement like this:

“We are looking for test automation workers. The ideal applicant is a good learner, able to work individually, can solve problems quickly, happy to work in a team, performs their tasks precisely and carefully, and likes to solve logic problems. A higher education qualification is an advantage.”

IT qualification is naturally advantageous, but it’s not a required. Our clients have successfully assembled test automation teams from non-IT personnel.

All applications are built on easy to identify patterns, and their parts contain a lot of similarities. Well thought out tests created for the testing of the application follow the identified patterns.

With an appropriate level of granularity, there is no need to implement the recurring test codes again and again, you can use them in different cases, so these become reusable.

You can build new test logic from existing components that are built from already well tested and properly working parts.

Reusability improves effectiveness, helps to ensure maintainability and transparency, and produces an easier to read test code.

The verification of the correct operation based on the business rules and specifications is a complex task. The business, testing and test methodology knowledge necessary for creating well working automated tests and to create the test code the personnel must acquire the knowledge and practice connected to the tools, even the correct evaluation of the executed tests and the utilization of the results requires knowledge and experience.

For effective and successful test automation all the required knowledge shouldn’t be the sole responsibility of a single person, the system must allow for separating the tasks when working as a team and it must be able to assign different roles.

Business knowledge is usually possessed by the most expensive and rarest of personnel, the business experts. In many cases they are also responsible for testing the applications, so the extent of the testing is limited by how much time and effort these persons can direct to the task. 

Test specification must of course include business knowledge, but the creation of the automated tests can be carried out by persons specialised for this task.

Therefore the most effective way to perform work split between separate roles based on the different working phases, to record the business plans, to prepare, design, create, implement and evaluate the tests is the teamwork with divided roles.