Creating an Application Script

Overview

This section outlines how to prepare your Application scripts. Application scripting is straightforward, but getting the details right is essential for a smooth experience.

Begin by determining the order of Applications and the specific actions to be performed within each one. Additionally, consider the following factors before you start creating your Application scripts.

Scripting involves automating tasks within Applications, allowing for increased efficiency and consistency. By following best practices, you can ensure your scripts are effective and easy to maintain.

The article will discuss the following subjects:

• Creating an Application Priority List

  • Learn how to identify and rank Applications from most to least important.

• Defining the Workflow

  • Understand how to outline a workflow for each Application and what it should entail.

• Defining Measurements

  • Discover what metrics you need to track to gather accurate data.

• Defining Requirements

  • Determine the needs of Virtual Users to successfully complete the defined steps for each Application.

• Final review

  • Document everything thoroughly and conduct a manual verification to ensure accuracy.

Step 1. Creating an Application Priority List

The first step is to create an Application priority list. You can classify Applications into 3 categories: Business Critical, Productivity, and Bulk. Prioritize the Applications in the same order as indicated in the image below.

Business Critical

Business-critical Applications are those that a significant portion of your user base relies on. If these Applications fail to function correctly, it could result in substantial financial losses for the business. As such, they hold the highest priority for development and should undergo thorough measurement to collect critical performance data.

In a typical Virtual Appliance environment, the number of Business Critical Applications usually ranges from 1 to 10. These Applications are often integral to use cases such as Continuous Testing, Load Testing, and Application Testing within the Virtual Appliance.

Productivity

Productivity Applications are widely used but pose minimal risk if they do not perform as intended or become unavailable. For instance, Adobe Reader can be categorized here; while a slowdown may be inconvenient, it is not catastrophic. This category is the second-highest priority for development. Focus may be less intensive, concentrating instead on ensuring that specific, frequently used actions function properly.

These Applications are primarily utilized in Continuous Testing and Load Testing use cases, depending on their impact. However, it is recommended that they always be included in the Application Testing use case.

Bulk (Rest)

Bulk Applications are those that do not fall under the Core or Business Critical categories. Their impact is minimal to nonexistent, making them non-critical for business operations. Examples of such Applications include Notepad, Paint, and Calculator. If these Applications are unavailable for a day or two, it remains a manageable situation. However, it is still important to ensure they function at a basic level.

These Applications are primarily utilized in the Application Testing use cases, where the focus is on verifying that they can launch successfully after any changes have been made to the image.

How to gather this information

There are several ways to compile the lists mentioned above. The most common methods include:

• Management input

  • Consult management to identify what they consider mission-critical. Understanding their needs and goals will help you generate the appropriate reports.

• Monitoring tools

  • Utilize monitoring tools that can provide insights into the most frequently used Applications in your environment. This data can assist in classifying Applications as Core or Business Critical.

• Functional Testing teams

  • Functional Testing teams are responsible for testing Applications before their release. They often maintain a prioritized list of Applications, which can be valuable in your assessment.

• Application owners/teams

  • Application owners or teams are typically responsible for specific Applications. If an Application has a dedicated team, it likely indicates that it is a Core Application.

• Consulting Key-Users

  • Key users from various departments can offer valuable insights into which Applications are critical for their roles.

• Support/Service desks

  • Support or service desks can provide information on the most troublesome Applications based on the volume of support tickets received regarding those applications.

Step 2. Defining the Workflow

Now that you have identified the Applications to measure, it is crucial to determine the actions you will perform, and potentially measure, within each Application. A combination of actions for an Application is referred to as a workflow or click path.

The objective of this step is to create a detailed workflow or click path that accurately mimics real user activity and load. It is essential to be as detailed as possible, as the individual creating this workflow may not be the one developing the Application script.

Steps should be repeatable. Modifying data within any Application workflow could disrupt the actions being performed.

To illustrate, refer to the example below, which demonstrates a less effective approach, followed by an example that illustrates a more effective method. Notice the difference in detail between the two.

Wrong way

1. Start Application x

2. Login

3. Search for DATAXXXX

4. Close Application

Right way

1. Start Application X

2. Wait for the login window to appear

   1. Type user name 

   2. Type the user password

   3. Select environment

   4. Click on Login

3. Wait for the main window to appear

4. Click on the search button at the top of the window

   1. Wait for the search window to appear

   2. Type DATAXXXX in the search field

   3. Enable Checkbox Filter

   4. Click on search

5. Wait for the search result to appear

6. Click on the top result called DATAXXXX

   1. Wait for the dataset to load

   2. Browse through the dataset

   3. Close the dataset

7. Close the Application

The example above primarily applies to Core Applications. As you move lower on the priority list, the level of detail required for the actions decreases. For instance, workflows for Bulk Applications may be as simple as starting and stopping the Application.

How to gather this information

There are several methods to gather the workflows mentioned above. The most common approaches include:

• Consulting key users

  • Key users from various departments can provide insights into which actions are critical for their roles or identify actions that are most problematic from a performance standpoint.

• Support/service desks

  • Support or service desks can help identify the most troublesome actions within Applications by reviewing the tickets they receive related to those Applications.

• Involving Functional Testing teams

  • Functional Testing teams are responsible for testing Applications before release. They typically maintain detailed workflows for the most important Applications, from which you can filter the actions you want to measure.

• Engaging Application owners

  • Application owners or teams are responsible for specific Applications and should be knowledgeable about the most frequently used actions or those that are most problematic in terms of performance.

Step 3. Defining Measurements

Now that you have identified the Applications and their respective workflows, the next step is to determine which actions need to be measured for performance. While automating the Applications is essential, and Login Enterprise will notify you if an Application fails to complete its actions, measuring performance is where Login Enterprise truly excels.

Challenge your measurements

It is crucial to understand the purpose behind each measurement you add. Ask yourself: Why do you want this action measured? What insights do you hope to gain from this measurement? If the action is not performing as intended, what implications does this have?

Common measurements

The most common actions measured are those that require waiting for results, as these are typically the most affected by performance issues. A useful rule of thumb is that the longer an action takes to complete, the more it is likely to be impacted by performance degradation. Below are some examples:

• Logging in to an Application

• Searching for data

• Clicking on links

• Opening a report/data

• Loading Calendar overview

• Saving a file on a share

We also recommend selecting steps in your process that have dependencies and can impact overall performance. For example, performing a search involves querying a database. Measuring this action can provide valuable insights into the health of your database. Any slowness recorded in the Application script may indicate that the database is not optimized or is reaching its maximum capacity.

Step 4. Defining Requirements

Each Application and its associated actions within the workflow may have specific requirements that must be met for the successful execution of the Application script. These requirements need to be clearly defined to ensure the script can run smoothly.

Requirements can vary widely and may include providing licenses for test users or specifying datasets to be used within the Application. Below are a few examples:

• Login information

  • Username and password for accessing the Application.

• Application-specific Logins/Licenses

  • Any necessary logins or access credentials specific to the Application.

• Licenses

  • Office 365 licenses or other Application-specific licenses required for operation.

• Files to be opened

  • Provide necessary files, such as .docx and .pdf documents, that will be used in the workflow.

• Define Save File Locations

  • Specify where files should be saved during the workflow process.

• Create Test Data in Data-Sensitive Applications/Databases

  • For example, create a test patient record in a healthcare system to prevent data mutation in live datasets.

Step 5. Final Review

Once all the information mentioned above has been collected, it is advisable to document it in a Word or Excel file. This allows you to describe each step clearly, ensuring that it leads to a functioning Application script.

Additional Resources

• To learn about Application scripting considerations, see Difficult Applications.

• For information on the Application X-Ray, see Using the Application X-Ray.

• For creating workloads using the Application X-Ray, see Creating Workloads Using the Application X-Ray.

• For more details on the Script Editor, its benefits, use cases, and more, see Using the Script Editor.

• To learn more about the Script Recorder, see Using the Script Recorder.