Zeenyx Software adds Loop Software & Testing Services as a North America Reseller & Implantation Partner

Plans in place to offer additional in-person training & onboarding opportunities

CAMBRIDGE, Mass. – Zeenyx is thrilled to announce Loop Software & Testing Services will be joining its global network of partners in the Software Testing space. Zeenyx has a long traditional of high-quality implementation partners & Loop will continue to add to this legacy. Over the coming months, Loop will offer additional onboarding, training, & engagement opportunities.

 Brian Le Suer –

 “We couldn’t be more excited about having Loop join our mission. We could not have achieved the board-based success AscentialTest has had without fantastic partners. We believe that Loop will not only be a value add to future customer organizations, but has plenty of value to offer the existing client base. Although it is certainly a trying time, our team could not be more excited about the future of Zeenyx & the opportunities to come.”

 Ben Fellows –

 “Loop has had the opportunities to work in many different testing platforms in service of our clients. We believe Zeenyx’s AscentialTest is head & shoulders above the rest in addressing the current challenges modern software testers face. With an emphasis on maintainability, reusability, & durability, we could not be more blown away by our experience so far. This product is truly one of a kind in the testing space & we are proud to be partnering with a company that has such a strong software testing lineage.

AscentialTest is a comprehensive software testing solution that provides test planning, test data management, manual and automated test development, test execution, defect tracking and reporting. Built around our patented ‘smart image’ technology, our users build test components by dragging and dropping from a series of application images not from fragile, difficult to maintain recordings.

 Loop offers a suite of managed services including automated testing, manual testing, test planning/designed, product documentation, & more.

 In recognition of the challenging economic time & in celebration of this partnership, Loop Software will be waiving its customary “set-up fee” and will be offering comprehensive automation suites when paired with maintenance contracts.

While it is not always necessary to name the selector when using it to select a row in a table, it is always good practice.  In the example below, the row is selected using the ‘customer id’:

The action to select the row uses the selector ‘SelectByCustomerId’, but it does not actually specify the selector. Instead only the value of the selector, represented by the variable ‘CustId’, is specified:

Because the name of the selector is specified, its relative order in the AppObjects definition will not affect the result.

That action only works because the seclector SelectByCustomerId is listed first under its corresponding row (see the right most arrow in the figure above). If the selector called ‘SelectByLastName’ were moved up one line so that it was the first listed selector, then the action would fail. A more robust way to define an action that uses a selector is to specify the name of the selector along with its value as in the updated example below:

Because the name of the selector is specified, its relative order in the AppObjects definition will not affect the result.

AscentialTest 9.5 is now available for download. Check out these new features:

AscentialTest 9.5 is in the works. Check out these upcoming features:

1. Results output now displays Step trace so that the user can easily determine the location of each test action.

2. New Profile wizard provides assistance for enabling extensions and setting up a new project.

3, AppState wizard now prompts for Login window.

4. AscentialTest will be localized in French, Japanese and Spanish.

5. PowerBuilder Bitmaps can now be defined through drag and drop.

6. PowerBuilder path generation options can now be prioritized.

7. User can now control the playback speed so that the test execution can be slowed down to assist debugging and demonstration.

Stay tuned .. more to come.

Check out the new features of AscentialTest 9.4

• Non-English keyboard runtime support.
• Support for Electron applications.
• Support for 64 bit PowerBuilder applications.
• Resizable dialog boxes in AscentialTest UI.
• Reorganized AscentialTest File menu.
• Drag and drop support for PowerBuilder toolbar definition.
• Ability to disable auto-scroll in Elements and App Object panels.
• RenderImage improvements.
• New Html5 attributes.
• Several AscentialTest UI Improvements.
• Close action added for MDIChild class

Many applications contain entities that must be unique. A common example is a customer or member identifier like email address. To prevent input errors, automated tests must be designed to ensure that these identifiers are unique. There are several techniques to achieve uniqueness, including appending date/time strings or a unique number to the entity name. This post describes the latter solution.

The image above displays source code for the Incrementer function. It takes as parameters the name, section and lValue of the .ini file that will be used to store the current value of the incrementer. It also takes a Boolean flag that specifies whether to increment the value on the current call. This is useful because some calls might want to get the current value of the incrementer without changing its value. The function outputs the current value of the incrementer as an out parameter of type integer. It also returns it as a string for convenience.

The function is quite simple. It opens the specified .ini file, gets the value of the incremeter specified by the IncrementerLValue parameter and converts it to an integer. If bIncrement is set to 'true', it increments the rValue and writes it back to the .ini file. Finally it sets the IncrementerValue and passes it to the calling function through both the out parameter and the return value.

The calling function can then append the retuned value to an entity name before inputting it to the target application.

If you have any questions about this approach or would like to obtain a copy of the function's source code, please contact Zeenyx Support.

Introduction

The ‘start’ and ‘finish’ phases are essential components of an automated testing project. The ‘start’ phase defines what occurs before a test is run. The finish phase defines what occurs after.

AscentialTest is designed so that each test automatically has a start and finish phase. The start phase is mostly generated for the user through the App State wizards. The finish phase is left to the user. Recently we’ve discovered that many users are unaware of mechanics of the finish phase, so we decided to communicate best practices around the topic. This paper explains our intentions in designing the ‘Test’ class and how we envision the ‘OnFinish’ to be configured.

 The Test Class

Every test created in AscentialTest derives from a class called ‘Test’ as shown below:

Because the ‘Test’ class is pretty much invisible, we all tend to take it for granted. When we click on the ‘Run’ icon in AscentialTest, we expect a test to run and it does because of the ‘Run’ method that is built into the class. But it isn’t just the body of the test that is being run. Every time a test is executed, the start and finish actions are also run.

Here is a brief explanation: When a test is executed in AscentialTest, the ‘Run’ method is called. The ‘Run’ method starts a timer and then calls another built-in method called ‘OnStart’. Most users are familiar with ‘OnStart’ because it is automatically generated by the App State wizards. In most cases, ‘OnStart’ includes the actions that launch and, if applicable, log in to the target application. Next the ‘Main’ gets called. The ‘Main’ includes all the steps and actions that make up the body of the test:

If an exception is raised during the ‘Main’, another method called ‘OnException’ gets called. Its job is to report the exception to the Results Output. Whether or not there is an exception, the ‘OnFinish’ method finally gets called. We expect the user to configure ‘OnFinish’ to return the target application to a known state that we refer to as the ‘base state’. It’s typically the state of the application when it is first invoked, after any login has been completed.

‘OnFinish’ is accessed by using the dropdown located above the steps/actions area in the App State Editor:

By default, ‘OnFinish’ is empty. That’s because the actions to return an application to its base state vary widely from application to application. It is not something that Zeenyx can provide universally. However we can offer guidelines and provide a function to help get you started.

 OnFinish

To ensure that tests run reliably, it’s important that they are independent of each other and that each test starts and stops at the base state as defined above. A well-designed test includes steps that return the target application to the ‘base state’, which usually entails closing dialogs that were opened during the test. When a test fails and an exception is raised, there is often a break in the flow of the test. Control is passed to ‘OnException’ to raise the error and the application is often left in a state where the current test transaction is incomplete. This is where ‘OnFinish’ is called upon to return the target application to the ‘base state’.

To make it easier for users to configure the ‘OnFinish’, we’ve created a new function called ‘CloseActiveWindows’ partially pictured below:

‘CloseActiveWindows’ checks the state of the target application to determine if the application’s main window is active. If any dialogs or windows are opened, it attempts to close them. The built-in ‘Close’ action is called for each active window found. ‘Close’ attempts to click on the CloseBox (The ‘X’ in the upper right corner of a dialog) if it exists. Otherwise it types the <ALT-F4> keys. If the window is not successfully closed, ‘CloseActiveWindows’ takes additional steps to attempt to close it.

 A call to ‘CloseActiveWindows’ should be placed in the ‘OnFinish’ method of your App State as pictured below:

The first parameter is the App Object name of the target application’s main window. The second parameter specifies the number of attempts that should be made to attempt to close any active dialogs.

 We recognize that many applications will require further action to return the target application to the ‘base state’. The recommended approach is to create a custom ‘Close’ action for each dialog or window that requires addition steps. If a ‘Close’ action is defined for an App Object, it is that custom action that will be called by ‘CloseActiveWindows’ instead of the built-in Close action. A simple ‘Close’ actions may require a click on an ‘OK’ button. A more complex ‘Close’ action might entail the actions required to complete the current transaction. The amount of ‘statefulness’ in a given application determines the complexity of the ‘Close’ actions that will be required.

 If you are reading this document, chances are that you already have ‘CloseActiveWindows’ in your possession.  If you do not, please contact us at support@zeenyx.com to obtain a copy. We are happy to discuss the finish phase requirements for your target application and will assist you with designing effective ‘Close’ methods.

We're looking foward to participating in Appeon's PowerBuilder user conference, Elevate 2018, to be held in Philadelphia November 5 - 7. We'll be showing off AscentialTest's support for the latest version of PowerBuilder and we'll also be reminding PB users why AscentialTest offers a powerful solution for building automated tests in the PB environment.

AscentialTest provides testing support for PowerBuilder applications from PB v6.x right up to the most current version of Appeon PowerBuilder.  The Datawindow is recognized regardless of its presentation style (Form, Grid, Group, Tabular, etc.). The image below displays a Datawindow in the form of what we call a PbTable. It has rows and columns that can contain any number of control types (checkbox, popuplist, textfield, etc.). AscentialTest provides a special feature called a ‘selector’ which makes it easy to locate a row in a table based on a target value. In the picture below, the selector has located the third row in the table because it contains the test value ‘Table Management’:

AscentialTest also recognizes the Datawindow in the form of what we call ‘PbForm’. Notice that the PbForm displayed below contains many different types of application objects including PbText, PbTextField, PbRadioGroup and PbCheckBox. These are only some of the control types that can be included on a form.

Most PowerBuilder applications include tool bars with icons that represent application tasks. AscentialTest provides special recognition for those tool bar icons to make it easy to select them:

AscentialTest provides special object recognition features for the PowerBuilder objects including:

• PbCheckBox
• PbComboList
• PbComboTable
• PbCompute
• PbDataWindow
• PbPopupList
• PbPopupTable
• PbRadioGroup
• PbText
• PbTextField

 We hope that you will join us at Elevate this year.