Another Ascential Difference

Test frameworks are costly to build and maintain. Unlike keyword-driven testing, the step-based approach does not require the development of a test framework. Instead of requiring testing teams to create layers of spreadsheets to define tests and keywords along with supporting files of functions that need to be either recorded or scripted, the step-based approach builds relationships between application objects, test actions and test data so that the test framework can be automatically generated and maintained.

 

More Reasons Why

 

Supported Platforms

  • Windows Clients
  • SWT
  • Internet Explorer
  • Firefox, Chrome
  • Java - Swing
  • DotNet - Winforms & WPF
  • Terminals (iSeries)
  • Powerbuilder 6x -12.x
  • Siebel

 

 

 

 

AscentialTest now provides testing support for PowerBuilder 6x -12x

 

Test Planning

Test Data Management

Manual Testing

Automated Testing

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The Game Changer: AscentialTest 6

AscentialTest 6.0 is a game changer. It gives the power to create durable automated tests back to the domain experts who know what needs to be tested.

For too long, power and ease of use have been mutually exclusive in test automation. This dichotomy has left organizations without a solution that everyone on the testing team can utilize. Tools that produce robust, maintainable tests have had a steep learning curve. Access to powerful features typically requires use of a scripting language, which leaves some members of the testing team out. Companies have been forced to hire programmers to create automated tests, but the results are often less than satisfactory because the folks that understand what needs to be tested are not able to participate. They do their best to communicate requirements to the automation engineers, but misunderstandings are frequent and the process becomes inefficient and expensive. When manual testers don't understand what is covered by the automated tests, they often execute the same tests manually, so the organization loses the benefits of test automation. Furthermore, when the original test authors are gone, tests are abandoned because they are too difficult to maintain.

On the other hand, tools that provide traditional recorders are easy to use, but when the target application changes, it becomes expensive and inefficient to modify the tests. Sometimes organizations record them again, but when they do, they've lost the benefits of automation entirely. Those tests are intended to ensure that the application features continue to work as the application is changed. If they need to be re-recorded, the organization is left with a record of how the application behaves, not a test that verifies that it is working properly.

AscentialTest 6.0 provides a testing solution that marries the usability of a recorder with the strength of script-based testing. AscentialTest is intuitive enough for domain experts to use, but produces tests that can be maintained in a cost effective way. We developed the step-based approach to increase productivity and reduce the cost of test maintenance. Tests are built by combining reusable steps in a drag and drop environment. When the target application is modified, maintenance is isolated to the related steps. All of the tests that implement those steps are automatically updated.

Until now, only simple steps could be created using drag and drop. AscentialTest 6.0 changes that in a significant way. Using our snapshot technology, users can now drag and drop object/actions to build sophisticated reusable steps effortlessly. A complex series of actions that might be considered in the realm of the programmer, like condition and iteration, are now attainable using just the mouse. Domain experts with no scripting experience can easily create steps that rival those created by team members with programming experience.

Action Panel

The Step displayed above was created entirely through drag and drop. It includes several non-trivial actions. The first action makes a decision based on whether the ‘Categories’ page displays a single field or a table.  If the field referred to as ‘Categories.Name’ exists, the first category is added.  The conditional statement was dragged from a list of available actions like the one pictured below:

ActionsExplorer

The example Step also includes an action on a table row. When it was dragged from the snapshot, a field was automatically generated to provide a way for the user to specify the row that should be selected at runtime. In this example, the value ‘last’ was inserted so that the category would be added to the last row in the table.

Automated Test

The image above displays the Test Editor with a group of steps like the one described above. The reusable steps included in this test were dragged from the Step View displayed on the left. Those steps might be used in tens or hundreds of tests. A change in the target application may require that a step be changed. Once it has been modified, all of the tests that implement that step are automatically updated. That’s just one of the ways that AscentialTest makes it easy to maintain automated tests.

  Click here to download the AscentialTest brochure