CONFIDENTIAL
Espire Infolabs Document Date
SILK TEST
This report is solely for the use of client personnel. No part of it may be circulated, quoted, or reproduced for distribution outside the client organization without prior written approval from McKinsey & Company. This material was used by McKinsey & Company during an oral presentation; it is not a complete record of the discussion.
Prepared By Pooja Sethi
SilkTest Unit of measure Architecture
* Footnote Source:Sources
2/7
SilkTest QA Methodology
Unit of measure
Plan Phase •Use SilkTest projects to store information about your testing process •Define specific tests and determine testing strategies •Create a test plan - Testplan Overview - Testplan Detail * Footnote Source:Sources
3/7
Capture Unit of measure Phase •Learn about the application •Visit each window •Build a frame file •Capture windows •Create application states Create Phase •Create automated testcases * Footnote Source:Sources
4/7
Run Phase
Unit of measure
•Select and execute specific tests •Generate results Report Phase •Summarize progress and defects •Produce a Pass/Fail report
* Footnote Source:Sources
5/7
Track Phase Unit of measure •Track defects •Perform regression testing
* Footnote Source:Sources
6/7
Unit of measure File Types SilkTest
* Footnote Source:Sources
7/7
SilkTest Unit of measure Projects •Can be created through File/New Project •Organize all the resources associated with a test set, such as testplans, scripts, data, options sets, .ini files, results and frame/include files •Store relevant information about your project, including configuration information, editor settings and data files for attributes and queries at the project level •Allow you to add appropriate files to your project
* Footnote Source:Sources
8/7
Project Explorer Unit of measure •Is used to view and access all the resources in a SilkTest project •Makes it easy to access files that have been added to the project •Allows you to open a file by double-clicking it •Presents the resources within each project visually, making them easier to see, work with and manage •Contains two tabs: Files and Global
* Footnote Source:Sources
9/7
Files Tab Unit of measure
•Lists all of the files included in the project •Allows you to view, edit, add and remove files from the project •Provides (via right-click) menu options for each of the file types, such as Record Testcase and Run Testcase for a file contained in the Script folder
Note:*You cannot move files within the Project Explorer. For example, you Footnote Source:Sources cannot drag a script file to another node 10/7
Global Tab Unit of measure
•Displays at a global level all the resources, for the open project, such as testcases, functions and classes •Allows you to double-click an object to open the file in which the object is defined and position the cursor at the beginning of the first line of the double-clicked object
* Footnote Source:Sources
11/7
The Basic Workflow Bar Unit of measure
•Allows you to create a new project or open an existing project •Helps you to automatically enable and test extension settings •Assists you in configuring the recovery system •Leads you through the process of recording a testcase •Allows you to run a testcase
* Footnote Source:Sources
12/7
Unit of measure Enable Extensions
Extensions enable SilkTest to recognize specific objects native to the environment in which the Application Under Test resides. Extensions must be set up prior to beginning the test development process
Recovery System Base State returns the application to its starting point before running a testcase, during a testcase, if an error occurs; and after testcase completion
Record Testcase •Displays the Record Testcase dialog which is used to create a testcase •Allows you to record the actions that you perform against the Application Under Test so that these can be played back at a later time •Stores recorded instructions in the specified script file * Footnote 13/7 Source:Sources
Unit of measure
Run Testcase •Displays the Run Testcase dialog •Is used to run any testcase in the active script file Note: You may also run all testcases by pressing F9 or the button located on the tool bar
Stopping a Testcase To stop a script or testcase from running: Select Run/Abort or press both shift keys simultaneously
* Footnote Source:Sources
14/7
The Frame File Unit of measure
•Is a central, global repository of information pertaining to your application, including: - data structures that support your test scripts, including window declarations, constants, variables - application states, as well as user-defined methods and functions •Can be viewed by double-clicking the file listed under the Include/Frame node in the Project Explorer window •Provides the means to create logical descriptions (identifiers) for all objects in an application •Is written in the 4Test scripting language and can be edited through use of the 4test Editor •Uses indentation to indicate relationships between objects * Footnote •Assigns distinct colors to the various15/7 types of editor items Source:Sources
Unit of measure
Note:* Only one frame file is needed for an Application Under Test Footnote Source:Sources
16/7
A Testcase Unit of measure
•Is a sequence of commands that simulate a user interacting with an application •Resides in a 4Test script (.t) file
* Footnote Source:Sources
17/7
Unit of measure Results File Testcase
•Is automatically generated by SilkTest •Has the same name as the executed script, frame or testplan, but with an .res extension •Provides information about the execution of the testcase, script or testplan: - Statistics at each level, including number of testcases run, number of errors and pass/fail ratio - Performance data, including start, stop and elapsed times - Clear identification of passed versus failed testcases - Information about any error(s) •Is a generation data set containing results history for script, frame or testplan - Default history size is 5 - History size can be modified through the Runtime Options * Footnote Source:Sources
18/7
Unit of measure Capturing States in an Application
Base State •Is the known, stable state that you expect the application to be in before each testcase is executed •Is typically the state that the application is in just after being started •Has two components: - Default Base State - User-Defined Base State Method
Note: The Default Base State will look for and automatically execute a User-Defined Base State Method. Note: Each application will have only one base state. * Footnote Source:Sources
19/7
Unit of measure Default Base State
•Is established when you create a new test fame to capture your application •Ensures that:
•Uses the value of the constant sLocation, as stored in the first (main) window declaration in the frame file, to determine which application window should be loaded * Footnote Source:Sources
20/7
Unit of measure
User-Defined Base State Method •Allows you to enhance your application's default base state •May be useful for: - Adding specific data to a field on the Default Base State page - Changing browser options such as memory and file cache to give you a fresh start at the beginning of each new test •Is an addition to the Default Base State; not a replacement for the Default Base State
* Footnote Source:Sources
21/7
Unit of measure
* Footnote Source:Sources
22/7
Unit of measure
An Application State •Is a state that you want your application to be in at the start of a given testcase •Is based on either Default Base State or another application state •Reduces redundant code in your 4Test script and makes the code easier to maintain •Makes a testcase easier to record •Ensures consistency in driving the application to the test state •Is normally defined in the frame file
Note: It is a good practice to test each application state as it is created. * Footnote Source:Sources
23/7
Unit of measure Allows you to reuse existing application states to:
- Save effort - Modularize your routines - Reduce maintenance
* Footnote Source:Sources
24/7
Unit of measure
Window Declarations •Describe a window and all of its child objects; recorded window declarations will capture all child objects •Separate the physical page (which may change with each new build) from its logical operation (which will generally remain unchanged) •Specify logical names for all objects on a page – these names (identifiers) will be used regardless of platform or browser •Are added to the active frame file Note: In general, all Web application pages and their respective objects should be declared before creating test scripts
* Footnote Source:Sources
25/7
Unit of measure Creating and Running Testcases
Record Testcase •Displays the Record Testcase dialog which is used to create a testcase •Allows you to record the actions you perform against the application under test so that these can be played back at a later time •Stores recorded instructions in the specified script file
* Footnote Source:Sources
26/7
Unit of measure A Testcase
•Is an automated test that tests one objective of a testplan •Drives an application to the state where the test will be performed •Verifies whether the application works as expected •Resides in a 4Test script file •Performs two fundamental tasks: - Drive the application to the state to be tested - Verify that the actual state matches the expected state
Note: Each test description in a testplan will be implemented by one testcase. Each testcase verifies one test objective Note: No script or testcase should rely on the successful completion of a previous script or testcase. Each testcase should be independent of * Footnote Source:Sources
27/7
Testcase Structure Unit of measure
* Footnote Source:Sources
28/7
Unit of measure
Record Testcase
* Footnote Source:Sources
29/7
Unit of measure
Note: Selecting Paste testcase and update window declaration(s) assures that any objects your testcase interacts with will be defined in the window declaration * Footnote Source:Sources
30/7
When a Testcase Fails Unit of measure
Testcase Failures Occur when: - The object you are testing does not meet verification requirements - The application has changed and the commands in the testcase are no longer valid for the application - A window or message box appeared that your testcase was not expecting
* Footnote Source:Sources
31/7
SilkTest Recovery System Unit of measure •Is designed to automatically restore the application to a known state after an unexpected error •Ensures that each testcase begins with the application in its base state before executing any application states •Supports automated, unattended tests so that tests can be run after hours •Makes sure that a failed testcase does not prevent subsequent testcases from running •Manages unexpected events in the application and aids in ensuring reliable results •Logs warnings and errors
* Footnote Source:Sources
32/7
Unit of measure
How SilkTest Handles Verification Failures 1. An error is raised by SilkTest 2. SilkTest stops running the testcase and passes control to the recovery system 3. The recovery system logs the error to the results file 4. SilkTest executes the next testcase
* Footnote Source:Sources
33/7
The Results File Unit of measure
* Footnote Source:Sources
34/7
Unit of measure
Extract Results
- Window displays the results in a SilkTest window - without Special characters such as and so on - File opens a Save dialog, allowing you to save the list to an ASCII (.TXT) file - Printer opens a Print dialog, allowing you to print the list to an installed printer * Footnote Source:Sources
35/7
Revisiting the Workflow Bar Unit of measure Open Project -
Open an existing project
-
Auto Generating a New Project
Enable Extensions
* Footnote Source:Sources
36/7
Unit of measure Data Driven Testcases
•Let you store data combinations in a list of items and invoke the testcase once for each item passing the data to the testcase as a parameter •Can be associated with an external data source such as a spreadsheet, file or database •Can be executed against a specified set of records in a data source •Are executable either from the script file or from a testplan •Are also referred to as generalized testcases •Can be created in one of two ways: - Standalone technique - Data Driven Workflow technique * Footnote Source:Sources
37/7
Unit of measure
Standalone Technique •Offers three methods for passing data to a data driven testcase - Run/Testcase Dialog Method: select Run/Testcase and type the record data into the Run Testcase dialog - Testplan Method: in a SilkTest testplan, insert the record data as a testcase statement - External File Method: if the data exists in an external file, write a data function to read the file and use a main function to run the data function
* Footnote Source:Sources
38/7
Unit of measure
External File Method •Uses the same testcase format as any record driven testcase •Uses data stored in an external file instead of from a testplan •Needs a data function to parse the data from an external file Note: Because the data is stored externally, a function may be created to read the data and run the testcase
* Footnote Source:Sources
39/7
Unit of measure A Standard Testcase
•Is limited in its usage as the data is coded directly into 4Test statements •Can be converted into a data driven testcase because it has data and data types which can be stored in a record format
A Record
•May contain any number of fields, which may be of different data types •Must be declared outside a function * Footnote Source:Sources
40/7
Unit of measure
Data Driven Testcase
•Is associated with an external data source such as a flat file, spreadsheet or database •Can be executed against a specified set of records in a data source * Footnote Source:Sources
41/7
Unit of measure
An External Data File
•Holds data that is stored in a record format •Contains the data to be read during the testing scenario * Footnote Source:Sources
42/7
Unit of measure A Data Function
•Is created to parse the data from an external file •Will be used within a five step process to: 1) Declare a variable for the external file 2) Declare a variable to hold an instance of a record in the file 3) Open the file 4) Read the file and run the testcase for each set of data 5) Close the file Note: FileReadValue returns a TRUE when it reads a record and returns a * Footnote FALSE when it encounters end of file 43/7 Source:Sources
Unit of measure Data Driven Workflow Technique
* Footnote Source:Sources
44/7
Unit of measure Error Handling
•The recovery system scripts are located in defaults.inc, which is in the directory where you installed SilkTest. •You can write functions that override some of the default behavior of the recovery system. •You may want to handle errors locally and log errors and warnings in the results file under script control. •When a testcase uses its own error handling logic that does not call the recovery system, it can pass, even though an error has occurred
* Footnote Source:Sources
45/7
Unit of measure
4Test statements used to handle or raise exceptions
* Footnote Source:Sources
46/7
Unit of measure Options Set
•Is a file that contains settings to run SilkTest •Must be opened in order to be used in your project •Can be identified as the one that is currently loaded when its name appears in the SilkTest title bar •Can be passed along to other team members to ensure consistency in the testing process
* Footnote Source:Sources
47/7
Unit of measure
Set Recovery System •Is used to identify the starting point (Base-State) of the application you are testing •Updates the Use Files field on the Runtime Options dialog with the path to the executable for the application
Note: The Recovery System will return your application to its BaseState, before running a testcase, during a testcase if an error occurs and after a testcase completes.
* Footnote Source:Sources
48/7
Unit of measure
The Frame File •Contains the path to the application's executable file for the SilkTest recovery system to use while running testcases •Will initially hold a window declaration only for the starting page/window
* Footnote Source:Sources
49/7
Unit of measure Help Topics
•Is used to get more information than the Library Browser provides •Allows you to copy and paste examples into your testcase
* Footnote Source:Sources
50/7
Unit of measure Looping Statements
* Footnote Source:Sources
51/7
Unit of measure
Branching Statements
* Footnote Source:Sources
52/7
Unit of measure
* Footnote Source:Sources
53/7
Unit of measure How To Handle A Login Window
•Record a window declaration for the login window •Record an Invoke method to handle the login window •Modify the Invoke method to include a derived keyword •Add the login widow's name to the wStartup constant in the Main Window's window declaration
* Footnote Source:Sources
54/7
Unit of measure
* Footnote Source:Sources
55/7