Search

Application Script Creation Guide

For more information refer to this blog: Creating Workloads Using Login Enterprise Application XRay

This guide will tell you how to prepare your application scripts. Application scripting is very straightforward but to make your life easier it is important to get the details right. It is best-practice to prepare your application script by deciding which application goes first, and which actions are going to be done within each application. But on top of that, there are many other things you need to think off before you can start creating application scripts. 

This guide will discuss the following subjects:

  1. Creating an application priority list. We are going to define what is the most important and least important application, and how to do this.
  2. Defining the workflow. How do you define a workflow for an application and how should it look like?
  3. Defining measurements. Find out what exactly you want to measure to get the right data
  4. Defining requirements. What do the virtual users need in order to fulfill the steps defined for each application.
  5. Done (?). Make sure to write everything down and verify it manually.

1. Creating an application priority list

The first thing that needs to be done is to create an application priority list. You can classify the applications in to three sections, Business Critical, Productivity, and Bulk, you prioritize the applications in the same order as the image below suggests. 

blobid0.jpg

Business Critical

Business Critical apps are applications which either a large portion of your userbase is using. Or if it fails to work correctly it can cost the business a lot of money. These have the highest priority to be created and should have the most in-depth measurements done to collect critical performance data. On average in any Enterprise environment the amount of these Business Critical applications range between 1-10 different applications.

The Business Critical applications tend to be the ones that are used within the Continuous Testing, Load Testing and Application Testing use-cases of Login Enterprise.

Productivity

Productivity apps are applications that are used a lot but if they are not performing as intended, or they are not working at all, there is no big risk involved. You can add, for example, Adobe Reader to this list, if it is slower than usual it is an inconvenience but not a disaster. This list has the second-highest priority to create and might be decided on to not go very deep in to this application but rather to find out if specific (most used) actions are working as intended.

These applications are mostly used in the Continuous testing and Load testing use-cases depending on their impact, but are suggested to always be included in the Application Testing use-case. 

Bulk (rest)

The bulk applications are the remainder applications that are not flagged as Core or Business. These applications are not critical at all as the impact is minimal to none. Examples of these kind of applications are, Notepad, Paint, Calculator, etc. If they do not work for a day or even two, it is still a manageable situation. But you still want to make sure that it functions on a basic level.

These applications tend to be used only in the Application Testing use-cases where they are checked if they can simply start after a change has been made to the image.

How to get this information

There are numerous ways to get the lists mentioned above. The most common ones are shown below:

  • Management
    • What is deemed mission critical from their perspective. Understanding their needs and goals will assist you in generating the right kind of reports.
  • Make use of monitoring tools
    • Some monitoring tools can show you the most used applications in your environment. This could allow you to classify the most used-applications as Core or Business.
  • Functional Testing teams
    • Functional Testing teams are the ones responsible for testing the applications before release, they tend to have a list of applications and most-likely have them prioritized also.
  • Application owners / teams
    • Application owners or Application teams tend to be responsible for specific or all applications. If there is an application team for a specific application, that should already tell you its a core app.
  • Asking Key-Users
    • Key users of different departments can also guide you in the right direction of finding out which applications are critical for their job.
  • Support / Service desks
    • A support / service desk should be able to tell you what the most troublesome applications are, depending on the ticket influx they have been receiving about this application. 

2. Defining the workflow

Now that we have a list of which applications we want to measure, it is important to know which actions we are going to perform and maybe measure within each application. A combination of actions for an application is what we call a "workflow" or a "click path". The goal of this step is to create a workflow or click path of an application that is described step by step and mimics real user activity and load. This should be as detailed as possible, since it is very likely that the person creating this workflow will not be the one creating the application script. 

Remember steps need to be repeatable, modifying data in any application workflow, could interrupt the actions.

To make things more clear see the example below as a wrong way and the example below that as a right way. Notice the difference in the details.

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 user password
    3. Select environment
    4. Click on Login
  3. Wait for the main window to appear
  4. Click on the search button at top of 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 data set to load
    2. Browse through the dataset
    3. Close the dataset
  7. Close the  application

The example above is mostly used for the Core applications, the lower on the priority list the less detailed the actions will need to be. For example the Bulk applications workflows could simply be the start and stop of the app. 

How to get this information

There are numerous ways to get the workflow mentioned above. The most common ones are shown below:

  • Asking Key-Users
    • Key users of different departments can also guide you in the right direction of finding out which actions are critical for their job or are most problematic (performance-wise).
  • Support / Service desks
      • A support / service desk should be able to tell you what the most troublesome actions within applications are, by looking at the tickets they have been receiving about this application. 
  • Include Functional Testing teams
    • Functional Testing teams are the ones responsible for testing the applications before release, they tend to have a detailed workflow for the most important applications you can filter out actions that you want to measure.
  • Application owners
    • Application owners or Application teams tend to be responsible for specific or all applications. They should know the most used actions in an app or most problematic (performance-wise).

3. Defining measurements

We now have the applications, and their respective workflows. The next step is to decide which action needs to be measured and checked for performance. Automating the applications is one thing, and Login Enterprise will notify you if an application breaks or can not fulfill its actions, however measuring performance is where Login Enterprise shines.

Challenge your measurements

What is very important to know is that with every measurement you add, make sure that you know why you want this action to be measured. What do you hope to gain from this measurement, or even if it is not performing as intended what does this tell you?

Common Measurements

The most common actions that we measure are actions on which you have to wait for results these are also the most likely to be impacted by performance the most. The rule of thumb is that the longer the action takes to complete the more it is impacted by performance degradation. Some examples below:

  • 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 choosing steps in your process which have other dependencies and can impact performance. e.g. performing a search means looking up a database. This action can then tell you a lot about the health of your database. The slowness you record in the application script can be the sign that tells you the database may not be optimized or is reaching its maximum capacity.

4. Defining the requirements

For each different application and action within the application workflow there could be requirements to make them possible. These requirements need to be defined so the application script can be created and the script can run successfully. 

These requirements can range from, providing licenses to the test user to providing data sets to search for in the application. A few examples are shown below.

  • Login information (username and Password)
    • Application-specific logons / licenses or access
  • Licenses
    • Office 365 license or Application licenses
  • Files that need to be opened
    • Provide the files like .docx and .pdf that need to be used in the workflow
  • Define save file locations
  • Create Test data in data-sensitive applications / databases
    • Create a test patient in a healthcare record system to mitigate data mutation in live data.

5. Done (?)

Once all of the above mentioned information is collected it is best to write them down in a word file or excel file so you can describe each step to make sure that it results in a working application script.