Intro to Automation Using Perfecto's CQ Lab

Editor's Notes

• #2: Welcome the audience, the title of the webinar and introduce yourself Introduce myself Wed: TCS, Wipro, IBM & Accenture Thurs: Cognizant, Infosys, InfoStretch
• #3: Before we get started with the Agenda, just a quick housekeeping item…at the end we should have a few mins for Q&A. There is a panel in the webinar to submit questions during the webinar, so if you think of something, please ask. If we are unable to get to finish questions for any reason, then we will send out the info to all attendees. Here’s the agenda:
• #6: What if you want to build out a lab yourself (or your company wants to build one - what might that look like? As practices accelerate and expand, reliability increasingly requires a cloud based lab. It’s not easy to create!! Continuous Quality must be in the cloud! Clicks 1 - 7: here are some things to think about when deploying a local lab. The process begins with acquiring servers, then deploying software and adding devices. As different devices are added unique hardware is also required. Soon, real time and dollars are being spent on building out a local lab. Clicks 8 – 15: As the need for lab scalability increases, there is the need for additional services such as repository back ups, addressing security requirements (firewall policy, SSO integration, IT infrastructure support). As these requirements continue to play out, organizations are compelled to allocate more FTEs, invest more budget and increasingly put these requests in the IT queue resulting in project slow downs. Clicks 16 – 17: Real end user conditions are needed for testing. Simple functional testing is not enough! Special infrastructure is a required to enable the controlling of these varied user conditions. For some organizations, the answer will be no to building out the right environment to manage user conditions. For those who say yes, it means more headcount, budget and frequently extended delivery turn around times. For those who do not support these requirements, quality risk rises. Click 18: A subscription based cloud based lab offers a clear alternatives to the complexity of managing local labs, and that’s where Perfecto can help!
• #7: Mention our differentiators
• #8: Example of what the Automation tab look like in the Perfecto IDE. Mention each area briefly… We will be looking at this in more detail as we go today.
• #9: Mention each area briefly…
• #10: Before reviewing how to script, let’s review the Automation IDE Interface The Top Bar The Canvas The Devices The Commands
• #12: The Canvas has 2 modes – Edit View Running View Edit View: The EDIT view must be enabled to write an automation script. Commands are included by selecting or dragging them from the automation side bar and onto the script canvas. The command parameter details can be modified by double clicking on the function that is already on the script canvas, or by clicking on the EDIT icon or button located in the top bar or bottom of the script canvas. When running a script, the canvas will automatically switch to running view, disabling the ability to edit the script. To continue editing the script, click on view once the script run is completed. Running View: To Run a Script, click on the RUN icon located in the TOP BAR. The script canvas will automatically switch to the running view mode, disabling editing and displaying relevant information.
• #13: View a device while writing a script Simulate device actions while being automated Record directly onto the script for quick use - Actions on the device can be recorded using the record icon located in the top bar. Once the record is activated, touch commands/keys and type text are recorded as script lines in the script canvas. This is the quickest way to write a script. Activity is recorded as hard-coded touch coordinates. Although this is inaccurate, it is useful when device touch coordinates are required. For example when using the drag command. View devices while executing a script
• #14: 4 Areas to focus on: Common Functions – this tab enables the user to quickly include commonly used functions within a script Full List Functions - this tab includes all of the available functions, organized in categories. An enriched Function Reference is available in the Knowledge Base. User functions - this tab includes functions written by the user (this will be further explained later in the training) Scripts Repository - this tab include the scripts storage area
• #15: Six simple, logical steps in the forms of commands that will open a device, browse to a particular website, verify that it is on that website and then close the device. 1. Select Device – what devices do you want to run your test on? 2. Open device – if its on its Lock screen, this will open the device 3. Home - Sets the device to its Home Screen- if it is not on its HOME screen, this will put it there and now the device is now ready to take the next command 4. Browser Go To – this tells the device to open the browser and go to a specified website. 5. Text checkpoint - Verify that the device is on that website home page – this ensures the success of the test case 6. Close device – this ends the test case. Some of the steps in the script above require specific information (such as DUT, Website URL, etc). These are script variables and they reside in all scripts.
• #16: A special mention about Script Variables. Variables are 'containers for storing information So Script Variables are ‘containers’ for storing information needed in the script Image 1 Every script needs at least a Device Under Test (DUT) variable or a defined list of variables (like website URL) The SCRIPT VARIABLES icon, located in the top bar, enables users to manage the script variables. Image 2 Defined variables can be used within function parameters Image 3 For Example, device variables can be defined and then used as the OPEN Device function Device ID parameter value. NOTES: 1. When using the EXECUTE SCRIPT function to include a sub-script within a script, the script parameters must be entered in the same order and with the correct types as defined in the original script. 2. Runtime variables are selected by the user before the script execution.  The defined value will be the default.   Unselect the checkbox to explicitly define the variable. 3. Under type, URL is only used for legacy systems. It is not needed in current versions of the CQLab
• #17: Discuss steps
• #18: During Scripting: When writing a script with an open device, the easiest way to run the script is on that open device. SELECT DEVICE is not needed. This is a quick and handy way to validate the script while it is being built. Simply specify the open device as the DUT (Device Under Test) in your Script Variables. In Production: Once your script is ready for production, SELECT DEVICE makes it more powerful, by using 'any' device that meets your specifications, in the event that a particular device is not available at the precise time that it is required. This is essential for unattended testing.
• #19: We’ve selected our device and we’ve allocated it to our script. Let’s use the HOME command next. HOME ensures a successful run of the script by setting the device to its home screen – If it is not on its HOME screen, this will set it there Now the device is ready to take the next command, regardless of which device you use and which screen it was last left at, this will reset it to its ready starting point.
• #20: Browser GO To is one of the easiest commands to use, telling it to open its device specific browser and proceed to a specified website. (if the website is a script variable, you will simply set the USAGE to VARIABLE in the parameters, and then select the name of that set variable, as shown in the Parameters image above. **First time only – Perfecto Mobile installs Chrome on the device – this is done for additional security (installed from scratch) First time use – pop up agreements have to be accepted: Do You Accept Google’s T&Cs: Pop-Ups: (Yes / Yes) Afterwards, it works Despite limitation, it’s still the recommended option
• #21: What if proof is required that the script successfully made it to a specified website page? How do you prove this? A Checkpoint – a Text Checkpoint in this example – can be used. When the script run is complete, a text checkpoint will deliver a screen shot image of the actual value ‘seen’ on the screen at that moment in the script run. It verifies that the device is on that website page, ensuring the success of the test case.
• #22: Validations use the same mechanism as a click command, but do not perform any actions. They are useful for making scripts pass/fail (example: did the login succeed?) Some useful validations are: -SYNC -CHECK A useful validation parameter is: -TIMEOUT SYNC and CHECK are the same command. SYNC has a default timeout of 60 seconds and CHECK does not. TIMEOUT is the duration in which the system will search continually for the 'needle'. TIMEOUT is a parameter within SYNC and CHECK ------------------ One additional note about validations…they don’t perform any actions….they are verifications of a scripts success or failure only. There are two different types: - Sync and Check – virtually the same with one difference. (Sync has a default timeout of 60 seconds) Timeout works by continually searching for the needle. If the needle is not found, the system searches for it again and again, until the time set by the timeout expires. (For example, a timeout of zero means one attempt only. Higher values will provide multiple attempts. Note that the analysis takes a few seconds as it requires taking a fresh screenshot and then analyzing it, so the retries are NOT every millisecond.
• #23: The QUESTION MARK icon can be found within every command window. It links to the functions reference. Each image below contains the "Sample" script commands. Each of the image "?" links to full documentation of all parameters and usage for that specific command. Advanced Parameter [Show an example of a command, such as OPEN Device – without Advanced Parameters enabled and then with Advanced Parameters enabled to show the difference]
• #24: The repository is the storage area for your file including scripts, data tables and media. In addition, the repository is broken down into three areas – the SHARED Repository – known as PUBLIC is accessible by all users in the cloud…anything in this folder type can be seen and accessed by all. the GROUP Repository – known as GROUP is a bit more restricted – files within this area are accessible only to users within that specified group the PRIVATE repository – beginning with MY – is accessible only by that owner. Files cannot be seen by anyone except for that user. In a shared MCM such as the public cloud, it is not possible to save into the public repository to preserve security. Customers on a shared MCM can use the group repository to securely share information within their organization. In dedicated MCM’s the public and group are basically identical, providing access to all the users of the organization. It is not possible to edit a script written by another user, even if it is in a shared repository folder. It is possible to open the script and save it under another name, this will make you the owner of the script And allow editing. Running a script written by another user is possible. [Show the repository storage area]
• #25: Reports can be exported in many formats such as html, pdf, csv, xml. They each provide a Pass/Fail summary, device list that the test case was run on including a test case video on each device, an execution sequence as well as a breakdown of each step in the sequence, when it started, how long it took, the expected needle it was looking for, as well as the actual value found.