Académique Documents
Professionnel Documents
Culture Documents
Certified
Professional
SURVEY
Tricentis Certified Professional
Student Exercise Workbook
Version 2015_03_Cross Browser Test Automation
Designed to be used with Tricentis Tosca Testsuite v.8.3.1
Legal Notice
Tricentis GmbH
Leonard-Bernstein-Straße 10
1220 Vienna
Austria
TABLE OF CONTENTS
1
PREFACE
1 PREFACE
About this workbook
You will learn how to professionally create and execute manual and automated test
cases in Tosca Testsuite.
The workbook aims to guide you through each individual step of the workflow so
that you can maximize your efficiency when working on your test project.
2
PREFACE
Presentations
The presentations can be downloaded from your account in our Learning
Management System. Please use the link below to download the
presentations:
https://getcertified.tricentis.com/
Solution videos
Tricentis offers a solution video for each exercise which is most beneficial for
self-paced learning.
In addition to guiding you through each exercise, each video includes valuable
best practice tips.
The sample solution videos are accessible on our Learning Management
System.
Online exams
All certification exams are offered as online certification exams. Please use the
link below to log on to the Tricentis Learning Management System:
https://getcertified.tricentis.com/
Exercise structure
Instructions
Step-by-step guide which explains what needs to be done.
3
PREFACE
Terminology
Important note
Some terms within the workbook seem to be misspelled, but they are not!
Please note that these terms refer directly to the actual naming convention used for
elements within and relating to Tosca Testsuite.
To graphically indicate that the elements in question is a Tosca elements, the
element’s name will be displayed in bold type.
Examples: Module, TestCase, ExecutionList
4
PROJECT ESSENTIALS
PROJECT ESSENTIALS
2 PROJECT ESSENTIALS
Table of Contents
Introduction ............................................................................................................... 6
Exercise 1 | Creation of a Multiuser Environment ................................................ 7
Exercise 2 | Creation of Users ................................................................................. 8
Exercise 3 | Creation of User groups ...................................................................... 9
Exercise 4 | Creation of passwords....................................................................... 10
Exercise 5 | Connect to an existing Common Repository .................................. 11
Summary .................................................................................................................. 12
Notes ......................................................................................................................... 13
Introduction
Project Essentials exercises give you all the information you require to begin your
work with the Tosca Testsuite.
You will learn
How to access the Tosca Testsuite once a license has been purchased
How to install the Tosca Testsuite and activate your license
The first steps in creating a project as well as best practice tips
Please note that the Project Essentials module is only available as self-paced
training.
It is necessary to watch the videos before completing the below exercises.
Please also download the Project Essentials presentation as a reference.
6
PROJECT ESSENTIALS
Objective
¾ Creation of a training multiuser environment using Tosca Testsuite.
Instructions
1. Start Tosca Commander. Start the Tosca Commander (either by double
clicking the shortcut on the desktop, or by selecting it from the Windows Start
menu).
2. Open the New workspace window.
3. Create a new Common Repository and a new workspace using the following
parameters:
Hints
¾ Use the paths that have been predefined as storage locations (where possible).
¾ Storing a workspace on a shared network drive is never recommended.
7
PROJECT ESSENTIALS
Objective
¾ Creation of four (4) additional Users.
Instructions
1. Open the Project window by selecting the menu entry “Window” and then
clicking on “Project”.
3. Right-click on “All Users” and select “Create>User” and create four Users with
unique employee IDs:
¾ JSmith90
¾ MRamirez72
¾ MSDoni81
¾ VWilliams80
4. Save your changes.
Hints
¾ Each User name must be unique.
¾ Use existing employee IDs, where available.
8
PROJECT ESSENTIALS
Objective
¾ Creation of two (2) different User groups.
Instructions
1. Open the Project window by selecting the menu entry “Window” and then
clicking on “Project”.
5. Rename the first group “Test Analysts” and the second one “Testers”.
6. Assign the Users to the appropriate User groups using drag & drop as follows:
Hints
¾ Each User group name must be unique.
9
PROJECT ESSENTIALS
Objective
¾ Passwords are assigned for each User.
Instructions
1. Open the Project window by selecting the menu entry “Window” and then
clicking on “Project”.
3. Right-click on one of the Users and choose “Set password” from the context
menu.
5. Click on “Ok”.
Hints
¾ The admin user informs the users of their specific passwords.
¾ It is also possible to use the Active Directory service (AD or else LDAP) for the
user management system in Tosca.
10
PROJECT ESSENTIALS
Objective
¾ Connect to existing Common Repository as the newly created User JSmith90.
Instructions
11
PROJECT ESSENTIALS
Summary
Objectives achieved
What’s next?
1. Test your knowledge by taking the Project Essentials online exam.
2. Continue with the exercises for Risk Priority Assessment.
12
PROJECT ESSENTIALS
Notes
13
PROJECT ESSENTIALS
14
RISK PRIORITY ASSESSMENT
RISK PRIORITY ASSESSMENT
Introduction
Risk Priority Assessment exercises will allow you to familiarize yourself with the
Requirements section in Tosca Commander.
You will learn
How to create and weight a Requirement structure
How to create a Requirement structure specifically for a sample web shop
application
How to carry out a risk priority assessment for Requirements
The “First steps” exercises give a short introduction to the most important elements
of the Requirement section. Here you will create your first simple Requirements
structure.
The following exercises will build on this knowledge using a real world example.
16
RISK PRIORITY ASSESSMENT
Objective
¾ Creation of a single user workspace.
Instructions
1. Start the Tosca Commander (either by double clicking the shortcut on the
desktop, or by selecting it from the Windows Start menu).
3. The field Select type of Repository should be set to None (creates single user
workspace) to create a single user workspace.
Hints
¾ You will now see the default view of a Tosca Commander Workspace, which
comprises of 5 open tabs (windows), which you are free to customize as you see
fit.
¾ Each window represents a different section in Tosca Commander and contains
a single element known as a root folder.
¾ In this training module, the focus is on the Requirements window (yellow
themed area).
17
RISK PRIORITY ASSESSMENT
Objective
¾ Creation of a basic RequirementSet in the Requirements section.
Instructions
4. Right-click the newly created Requirements folder Computer and choose the
command Create >> Folder in the context menu.
Hints
¾ A RequirementSet is a structural element in the Requirements section which is
used to organize your Requirements structure
¾ There are various methods to create elements in Tosca. The most common is to
right-click an element and choose the command Create from the top of the
context menu.
¾ If the command Create is not present in the context menu, this could mean that
it is not possible to create a sub-element there.
18
RISK PRIORITY ASSESSMENT
Objective
¾ Creation of a basic Requirements structure using key elements of the
Requirements section.
Instructions
1. Copy the folder Exercise 2 and paste it into the folder “Computer”.
You now have a folder named Exercise 3 containing the already existing
structure. (This procedure will be followed for each exercise to increase the
traceability of the exercises.)
Hints
¾ Please consult the notes in the corresponding presentation for more
information required to complete this exercise.
¾ While selecting Create >> Requirement from the context menu, please note
Ctrl+N, Ctrl+R listed next to the word Requirement.
¾ These are keyboard shortcuts, which if entered in the combination shown, will
also create a Requirement, just like selecting the option from the context menu.
¾ Shortcuts enable you to work more efficiently.
19
RISK PRIORITY ASSESSMENT
20
RISK PRIORITY ASSESSMENT
Objective
¾ Basic weighting of Requirements (risk priority assessment), considering the
importance of single Requirements when buying a computer.
Instructions
1. Copy the folder Exercise 3 and paste it into the folder “Computer”.
You now have a new folder named Exercise 4, containing the already existing
structure.
2. At the top of the Requirements window, you can find the column headers for
Name, Weight, and so on. These are the column headers in the Detail tab.
3. Remove the Required TestCases column, by clicking and dragging the column
downwards from the column headers, until an “X” icon appears, and then
releasing it.
4. Right click on the column headers and select the Column Chooser from the
context menu.
6. Enter the following values in the Weight column for each Requirement:
Requirement Weight
Price 1
Design 2
Technical details 3
CPU 1
RAM 3
HDD 2
7. Observe the changes in the Relative Weight and the Contribution columns.
We will focus on these columns in subsequent exercises.
21
RISK PRIORITY ASSESSMENT
Hints
¾ By entering values in the Weight column, each Requirement is weighted in the
context of all other requirements.
¾ In this example we can see that Technical Details, with a Weight of 3, is 3 times
more important to us than the Price requirement (weighted at 1).
¾ The Column Chooser can be accessed by right-clicking the column headers in
the Details tab of your open Requirements window.
¾ In the Column Chooser, you can select entries by double clicking on them, or
alternatively dragging an entry towards the column headers in the detail tab,
and dropping them in the position you wish to place them.
22
RISK PRIORITY ASSESSMENT
Objective
¾ Creation of a suggested folder structure for the requirements in a risk-based
testing project.
Instructions
4. Create two (2) new folders within the “Web shop” folder.
5. Name one folder “Overall system” and the other folder “Release candidates”.
Hints
¾ Having two (2) separate folders for the overall system and the individual
release candidates allows you to quickly keep track of which requirements were
added in which version.
¾ It is important to consider how the entire project should be structured.
¾ Tricentis recommends the use of the folder structure as outlined here, for other
projects as well.
¾ The structure used in the Requirements section can also be used in the other
sections (TestCase Design, TestCases etc.).
23
RISK PRIORITY ASSESSMENT
Objective
¾ Creation of a complete and functional Requirements structure for the sample
web shop application.
Instructions
“Webshop | Frontend”
“Webshop | Backend”
“Webshop | Non-functional”
Business context
This document contains an overview of the functional volume of the sample web shop
application.
This data comes from the Business Analysts and contains all necessary information
required to weight the requirements.
The description is divided into three (3) parts: the backend functionality - which is used for
customers -, the frontend functionality which is only available for administrators and the
non-functional requirements.
Backend functionality
¾ Manage promotional packages
¾ Generate reports
¾ Administration
Frontend functionality
¾ Customer
The customer can perform the following tasks:
24
RISK PRIORITY ASSESSMENT
¾ Login
¾ Register
¾ Modify customer data
¾ Product
A user is able to order, search and compare products.
¾ Shopping cart
The user is able to manage his/her shopping cart.
Non-functional requirements
¾ User Interface
¾ The colors of the interface should match the visual corporate identity of
the company
¾ It should be possible to select different languages
¾ It should be possible to modify the view
¾ Different browsers should be supported
¾ The performance must adhere to the guidelines in the company’s software
performance document (not part of the training material)
Hints
¾ It is important to have a consistent and reasonable Requirement structure.
¾ Use short descriptive names for Requirements.
¾ A non-functional requirement is a requirement that specifies criteria that can be
used to judge the operation of a system, rather than specific behaviors (e.g.
performance, compliance, reliability…). This should be contrasted with
functional requirements that define specific behaviors or functions.
¾ Tricentis recommends to set up and uphold the Requirement structure in
collaboration with the appropriate business unit, if available.
¾ This structure can be reused in other sections of Tosca (TestCase Design,
TestCases etc.).
25
RISK PRIORITY ASSESSMENT
Objective
¾ Appropriately weighted Requirements.
Instructions
3. Use the information given in the Business context below and transfer the
specified risk assessment to the corresponding Requirement.
5. Observe the changes in the Contribution and the Relative Weight columns.
Business context
The Business Analysts have provided the following information:
Backend
Requirement Damage Frequency
Promotional packages Very low Very rarely used
Reports Low Rarely used
Administration High Frequently used
Frontend
Requirement Damage Frequency
Customer High Frequently used
Product Very high Very frequently used
Shopping Cart Very high Very frequently used
Customer
Requirement Damage Frequency
Login process High Very frequently used
Register process High Occasionally used
Modify customer data Low Occasionally used
Product
Requirement Damage Frequency
26
RISK PRIORITY ASSESSMENT
Non-functional requirements
Requirement Damage Frequency
GUI Very high Very frequently used
Browser support Low Frequently used
Performance Very low Rarely used
GUI
Requirement Damage Frequency
Colors Very low Frequently used
Languages Medium Frequently used
View Very high Frequently used
Hints
¾ Enter positive whole numbers, between one (1) and five (5) as values in the
Damage Class and Frequency Class columns, with 1 being the lowest and 5
being the highest.
¾ Weighting is usually done top down. Begin comparing Requirements on the
highest level. Then assign weights on the lower levels.
¾ The Relative Weight is the weight of one Requirement when compared to
another Requirement on the same hierarchical level.
¾ The Contribution is the weight of one Requirement in the context of the entire
RequirementSet.
27
RISK PRIORITY ASSESSMENT
Summary
Objectives achieved
¾ Structuring of elements in the Requirement section.
What’s next?
1. Test your knowledge by taking the Risk Priority Assessment online exam.
2. Continue with the exercises for Test Case Design.
28
RISK PRIORITY ASSESSMENT
Notes
29
RISK PRIORITY ASSESSMENT
30
RISK PRIORITY ASSESSMENT
TESTCASE DESIGN
31
TESTCASE DESIGN
4 TESTCASE DESIGN
Table of Contents
Introduction ............................................................................................................. 32
Exercise 1 | First steps – creating a TestSheet ..................................................... 33
Exercise 2 | First steps – creating Attributes ........................................................ 35
Exercise 3 | First steps – creating Instances ........................................................ 37
Exercise 4 | Purchasing in the web shop.............................................................. 39
Exercise 5 | Structure from base elements.......................................................... 40
Exercise 6 | Preconditions...................................................................................... 41
Exercise 7 | Equivalence classes............................................................................ 43
Exercise 8 | Combinatorics .................................................................................... 45
Exercise 9 | Combination level .............................................................................. 47
Exercise 10 | Verifications ...................................................................................... 48
Exercise 11 | Combinatorial generation on TestSheet level .............................. 50
Exercise 12 | Integration of new Attributes ......................................................... 51
Exercise 13 | TestCase Substitute Links ............................................................... 53
Summary .................................................................................................................. 54
Notes ......................................................................................................................... 55
Introduction
The Test Case Design exercises will guide you through the process of creating a test
case design for a sample web shop application.
You will learn
How to create and maintain a TestCase Design structure
How to use and understand different combinatorial methods
How to utilize TestCase Design to create an optimized framework for the test
cases you will need in your test project
The “First steps” exercises give a short introduction to the most important elements
in the TestCase Design section. Here you will create your first simple TestCase
Design structure.
The following exercises will build on this knowledge using a real world example.
32
TESTCASE DESIGN
Objective
¾ Creation of a TestSheet.
Instructions
1. Open the workspace “TCP_Training_Modules” created in the Risk Priority
Assessment training module exercises.
2. Ensure that the Default view is active (menu item Window >> Perspectives >>
Default).
3. Navigate to the (open) TestCase Design section (red themed area) in the
workspace.
4. Right-click the TestCase Design root folder and choose the command Create
>> Folder in the context menu.
6. Right-click the newly created TestCase Design folder Computer and again
choose the command Create >> Folder in the context menu.
8. Right-click the folder Exercise 1 and choose the command Create >> TestSheet
in the context menu.
Hints
¾ A TestSheet is a fundamental element of the TestCase Design section.
¾ Tricentis recommends that one TestSheet covers one Requirement.
¾ The Default window layout is the five (5) open tabs that you initially see, when
creating a workspace.
33
TESTCASE DESIGN
34
TESTCASE DESIGN
Objective
¾ Creation of three (3) Attributes in a TestSheet.
Instructions
1. Copy the folder Exercise 1 and paste it into the folder “Computer”.
You now have a folder named Exercise 2 containing the already existing
structure. (This procedure will be followed for each exercise to increase the
traceability of the exercises.)
5. Repeat this procedure to create two (2) further Attributes according to the
information given in the Business context below.
Business context
In order to assemble a computer, several computer parts (e.g. processor, memory, hard
disk, video card, etc.) are available with different characteristics to offer a large number of
configurations.
The three (3) most important parts are:
¾ CPU (processor)
¾ Memory
¾ Hard Drive
Hints
¾ An Attribute is a structural element which represents different characteristics of
a specific object.
¾ Hair color is an example of such an element (see TCD presentation).
35
TESTCASE DESIGN
36
TESTCASE DESIGN
Objective
¾ Creation of Instances for the newly created Attributes.
Instructions
1. Copy the folder Exercise 2 and paste it into the folder “Computer”.
You now have a folder named Exercise 3 containing the already existing
structure.
3. Create a new Instance element, by right clicking on the Attribute, and selecting
Create >> Instance from the context menu.
6. Name these Instances “3.2 GHz Quad-core” and “3.4 GHz Quad-core”.
7. Repeat this procedure to create additional Instances for the final two (2)
Attributes using the information given in the Business context below.
8. Save your changes.
Business context
In order to assemble a computer several computer parts (e.g. processor, memory, hard
disk, video card, etc.) are available with different characteristics to offer a large number of
configurations.
The three (3) available variants for each computer part are:
¾ CPU (processor)
¾ 2.9 GHz Quad-core
¾ 3.2 GHz Quad-core
¾ 3.4 GHz Quad-core
¾ Memory
¾ 8 GB
¾ 16 GB
¾ 32 GB
37
TESTCASE DESIGN
¾ Hard Drive
¾ 1 TB Drive
¾ 500 GB Drive
¾ 250 GB Drive
Hints
¾ Instances are elements which represent data variants for a specific object.
¾ Brown, blonde and red are possible data variants for hair color (see TCD
presentation).
¾ The identification of possible Instances (data variants) within your system under
test, and the representation of them in Tosca, is a very important task when
constructing a test case design.´
¾ Instances cannot be broken down into smaller elements (it is not possible to
have a sub-instance).
¾ Shortcuts enable you to work more efficiently.
38
TESTCASE DESIGN
Objective
¾ Familiarity with the sample web shop application.
Instructions
1. Open the sample web shop application http://tosca-webshop.azurewebsites.net/
and have a look at the purchasing process.
2. Try to analyze the application before starting with the TestCase Design.
Here are a few questions that you will try to answer step by step in test case
design:
What is the process you are testing? How do you go about purchasing a
product?
What is your starting point for the process?
What are the individual steps of your process?
Do you need preconditions in order to test properly?
What is your test focus?
Hints
At a later stage, you will define data variations necessary to test a requirement and
what should be verified with these data variations.
In this example, we want to test the ordering process. Some of the questions that
need to be answered include:
¾ What steps need to be taken in order purchase an item?
¾ Is there anything you need before you can order?
39
TESTCASE DESIGN
Objective
¾ Knowledge of the basic Tosca elements.
Instructions
1. Right-click the TestCase Design root folder and choose the command Create >>
Folder in the context menu.
3. Right-click the newly created TestCase Design folder Web shop and again
choose the command Create >> Folder in the context menu.
6. Create the required Attributes in the TestSheet Product order. You can find
the required information in the Business context section below.
Business context
Our base structure will contain the following Attributes:
¾ Precondition
¾ Purchasing process
¾ Verifications
Hints
¾ Tricentis recommends creating elements using the available keyboard
shortcuts.
40
TESTCASE DESIGN
Exercise 6 | Preconditions
Objective
¾ Creation of a basic Attribute structure below the Attribute Precondition.
Instructions
1. Copy the folder Exercise 5 and paste it into the folder “Web shop”.
You now have a folder named Exercise 6 containing the already existing
structure.
3. Create two (2) new Instances underneath Customer for “Existing Customer”
and “Guest Account”.
5. Mark the Instance Guest Account as a valid Instance using the [F7] button.
Business context
In order to make a valid check out, a customer (existing or guest) needs to complete the
order.
The focus in this TestCase Design is not to test the creation of a customer.
Thus, the Attribute Precondition presents only one characteristic, namely Customer.
More information will then be filled out for the Customer itself.
Hints
¾ If something is specified as a precondition, this means that the whole process
of this specific item will not be tested. We only specify which exact characteristic
of the item is needed for later use in tests.
¾ The items in the precondition are not part of the test focus.
41
TESTCASE DESIGN
42
TESTCASE DESIGN
Objective
¾ Construction of an extended Attribute structure for the purchasing process.
Instructions
1. Copy the folder Exercise 6 and paste it into the folder “Web shop”.
You now have a folder named Exercise 7 containing the already existing
structure.
2. Create two (2) Attributes under the Attribute Purchasing process and name
them “Product Selection” and “Order details”.
4. Assign each Instance, where applicable, the correct values for the properties
Character and Position (e.g. Valid, Invalid, and Boundary Instances etc.).
Business context
¾ All of the information is considered "business relevant" for the purchasing process, since
it influences the total amount to be paid (each piece of data has a direct impact on the
total sum).
¾ The Attribute Product Selection will contain the following:
¾ Several product types are available (It is possible to purchase several product
types at once)
¾ Cell phones (most people buy a cell phone in the web shop)
¾ Notebooks
¾ Digital downloads (the price of the downloads are always around $5)
¾ Total price of selection (the price influences the shipping costs)
43
TESTCASE DESIGN
Hints
¾ There can only be one StraightThrough Instance per Attribute.
¾ Arrange the Instances logically – i.e. an order that is easy for you to understand.
¾ Empty, invalid and boundary values must be taken into account.
44
TESTCASE DESIGN
Exercise 8 | Combinatorics
Objective
¾ Data combinations at the level of the Attributes Order Details and Product
Selection.
Instructions
1. Copy the folder Exercise 7 and paste it into the folder “Web shop”.
You now have a folder named Exercise 8 containing the already existing
structure.
4. Create an Instance directly underneath the Attribute Order Details and then
delete it, leaving an Instance folder.
45
TESTCASE DESIGN
Hints
¾ There are different possibilities of structuring Attributes and Instances.
¾ The proposed solution is just one way of doing this and might differ from the
one you’ve chosen.
¾ In order to generate Instances automatically with Tosca, you first need to specify
where you want to create Instances (by creating an Instance folder, see
Appendix of TCD presentation) and then selecting the Attributes you want to
combine.
¾ All Instances must be marked properly before generating Instances
automatically.
46
TESTCASE DESIGN
Objective
¾ Combinatorial generation on the level of the Attribute.
Instructions
1. Copy the folder Exercise 8 and paste it into the folder “Web shop”.
You now have a folder named Exercise 9 containing the already existing
structure.
2. Use the information described in the Business context section below to add
any further Instances and/or Attributes where applicable.
3. Combine the Attributes Product selection and Order details at the level of the
Attribute Purchasing process using the linear expansion method.
Business context
¾ If a Digital Download is selected, it is not possible to provide a shipping address.
Hints
¾ When considering dependencies it is important to incorporate them into the
already created Instances. This may result in an increase or decrease in the
number of expected Instances.
¾ Whenever there is a dependency you will need to check all created Instances to
see if they still reflect the information in the requirements document.
47
TESTCASE DESIGN
Exercise 10 | Verifications
Objective
¾ A set of verifications.
Instructions
1. Copy the folder Exercise 9 and paste it into the folder “Web shop”.
You now have a folder named Exercise 10 containing the already existing
structure.
3. Add relevant Instances within the Attributes to reflect the business context
information.
Business context
¾ Identify the possible verifications.
¾ Has the order been placed successfully? Did the order process fail? Is this relevant?
¾ Is an error message visible? Are confirmation messages visible?
¾ Are there shipping costs? Should there be no shipping costs, then this must also be
tested.
¾ Ensure that only relevant information is verified.
¾ The expected error messages are:
¾ The coupon code you entered couldn't be applied to your order
¾ First name is required
¾ Wrong email
¾ The expected confirmation messages are:
¾ Your order has been successfully processed
¾ The coupon code was applied
¾ The shipping costs are:
¾ $10.00 without discount
48
TESTCASE DESIGN
Hints
¾ The Attribute type “Result” must be used.
¾ Each test case should have a unique test focus, which makes it clear what needs
to be verified.
49
TESTCASE DESIGN
Objective
¾ Creating data combinations (Instances) at the level of the TestSheet.
Instructions
1. Copy the folder Exercise 10 and paste it into the folder “Web shop”.
You now have a folder named Exercise 11 containing the already existing
structure.
2. Combine the Attributes Precondition and Purchasing Process using the linear
expansion method.
Check: Are the created data combinations correct from a business perspective?
Are there dependencies?
Check: How many Instances will you get using the Linear Expansion method?
Business context
¾ If the new Billing Address is empty, the expected message will be “First name is required
¾ If the new Billing Address is invalid, the expected message will be “Wrong email”
¾ If the total price is 0, the expected message will be “You cannot complete your purchase”
Hints
¾ The column Filter (selected by right-clicking the column header via the Column
Chooser) can be used to filter for specific Instances on the Attribute level (e.g.
in case of dependencies).
50
TESTCASE DESIGN
Objective
¾ A complete and finalized Attribute structure with data combinations.
Instructions
1. Copy the folder Exercise 11 and paste it into the folder “Web shop”.
You now have a folder named Exercise 12 containing the already existing
structure.
3. Create two new Attributes “Shipping method” and “Payment method” under
the Attribute Order Details.
Check: How do the new Attributes need to be integrated into the existing
structure, in order to cover the combinations required from a business
perspective using linear expansion?
Check: How many new Instances will you have to create at the level of the
TestSheet using linear expansion?
8. Now integrate the new Instances into the TestSheet Product Order.
51
TESTCASE DESIGN
Business context
¾ Order Details
¾ Shipping method
The customer can choose to ship by air (same day or second day), by
ground or to pick the order up in store.
If the order should be picked up in store, it will not be possible to specify
a shipping address.
In most cases, orders will be shipped by ground.
¾ Payment method
An existing customer can pay by credit card or purchase order.
A guest is not allowed to pay by purchase order.
The corresponding error message is: “You need to log in to use a
purchase order.”
It is rare that customers pay by purchase order.
52
TESTCASE DESIGN
Objective
¾ TestCase Design Instances linked to the relevant Requirement.
Instructions
1. Select a window layout where you can see the risk-weighted Requirement
structure Webshop as well as the TestSheet Product order.
2. Compare the Requirement structure with the Instances from the TestSheet.
Which Instances test which Requirement?
3. Drag and drop the Instances (or the entire TestSheet) onto the appropriate
Requirement. See how TestCase Substitute Links are created.
Hints
¾ By linking your TestCase Design, the results will be projected onto the
Requirements section.
¾ Tricentis recommends to use one TestSheet to cover one Requirement.
¾ TestCase Substitute Links cannot contain further, subordinate elements.
53
TESTCASE DESIGN
Summary
Objectives achieved
¾ Structuring of elements in the TestCase Design section.
¾ Application of all methods learned to create a framework for test cases for the
sample web shop application.
¾ Understanding the relevance of test case design in the context of the test
project.
What’s next?
1. Test your knowledge by taking the Test Case Design online exam.
2. Continue with exercises for Manual Testing.
54
TESTCASE DESIGN
Notes
55
TESTCASE DESIGN
56
MANUAL TESTING
MANUAL TESTING
5 MANUAL TESTING
Table of Contents
Introduction ............................................................................................................. 58
Prerequisite .............................................................................................................. 59
Exercise 1 | Create a manual test case ................................................................. 60
Exercise 2 | ActionMode Verify (manual) 1 .......................................................... 62
Exercise 3 | ActionMode Verify (manual) 2 .......................................................... 63
Exercise 4 | Link manual TestCases to Requirements ........................................ 64
Exercise 5 | Creating an ExecutionList.................................................................. 65
Exercise 6 | Link ExecutionList to RequirementSet ............................................. 66
Exercise 7 | Executing an ExecutionList ............................................................... 67
Exercise 8 | Print a report ...................................................................................... 68
Summary .................................................................................................................. 69
Notes ......................................................................................................................... 70
Introduction
The Manual Testing exercises will guide you through the process of creating and
executing manual test cases in the TestCases and ExecutionLists section.
You will learn
How to create manual test cases
How to link the test cases to the corresponding Requirements in the Requirement
section
How to execute the manual test cases in the ExecutionList section
How to interpret the test results and create a basic report in the ExecutionList
section
58
MANUAL TESTING
Prerequisite
Objective
¾ Fully prepared workspace.
Instructions
1. Open Tosca Commander.
5. Move all imported elements out of the Import folder, in order to only see the
folder structure beneath.
Hints
¾ During the Risk Priority Assessment Module of our TCP Training we have built a
complete Requirement Structure for our project.
¾ We prioritized our Requirements and saw that the Requirement View inside of
the RequirementSet Webshop | Non-functional had the highest contribution.
59
MANUAL TESTING
Objective
¾ Creation and execution of a TestCase containing only manual TestSteps.
Instructions
1. Familiarize yourself with the ordering process by choosing products according
to the business context below.
2. Go to the folder Webshop | Frontend > Product > Order process > Manual.
4. It is only necessary to place items in the shopping cart and not complete the
whole order process.
Business context
¾ Add the item “Blue Jeans” to your Shopping cart twice. (Quantity: 2) This product is in
the category “Apparel & Shoes”.
¾ Also add the item “Casual Golf Belt” to your Shopping cart twice. This product is also in
the category “Apparel & Shoes”.
Hints
¾ The use of short and precise descriptions for test instructions (e.g. name of
Manual TestStepValue, entry in Value field) is advised.
¾ When running a TestCase in the Scratchbook, do not change the default values
in the Execution Settings.
¾ When using multiselect to select multiple TestSteps for Scratchbook execution,
be careful to select the TestSteps in the correct sequence of execution.
¾ Using the format {CLICK} in the Value field for instructing the tester when to click
in a TestStep is a handy way of getting used to the Tosca syntax.
60
MANUAL TESTING
61
MANUAL TESTING
Objective
¾ Creation of a TestCase which verifies the total quantity of chosen products.
Instructions
1. Change the TestCase that was created in the previous exercise by adding a
TestStep which will verify the correct quantity of products (4) is displayed in the
shopping cart.
62
MANUAL TESTING
Objective
¾ Creation of multiple TestCases which verify changes in the GUI of the sample
web shop application.
Instructions
1. In the folder Webshop | Non-functional > GUI > View > Manual, create two
new TestCases. Name the first one: Webshop | View | # Products. Name the
second one: Webshop | View | Price: Low to High.
4. In the TestCase Webshop | View | Price: Low to High, change how the
products are sorted from default (“Position”) to “Price: Low to High”.
5. Verify if the sorting has been changed and the products are arranged
accordingly.
63
MANUAL TESTING
Objective
¾ Creation of TestCase Links between TestCases and Requirements.
Instructions
1. Organize the Tosca Commander view in such a way that you can see both the
Requirements and the TestCase sections.
2. Drag and Drop the TestCases created in the previous exercise to the
corresponding Requirement in the RequirementSet Webshop | Non-
functional.
3. Add the Column Coverage Specified via the Column Chooser and observe the
results.
5. Observe the impact on the results in the Column Coverage Specified in the
Requirements section.
Hints
¾ The user is responsible to specify the TestCaseWorkState.
¾ The TestCaseWorkStates are calculated (with regards to the Coverage
Specified) as follows:
¾ PLANNED: 20%
¾ IN_WORK: 50%
¾ COMPLETED: 100%
¾ Coverage Specified is calculated using the formula: TestCaseWorkstate [%] x
Relative Weight [%].
64
MANUAL TESTING
Objective
¾ Creation of an ExecutionList.
Instructions
1. Organize the Tosca Commander view in such a way that you can see both the
TestCases and the ExecutionLists sections.
Hints
¾ All test data is contained in the TestCases section.
¾ The ExecutionEntry is a direct link to a TestCase (Jump to TestCase) and will use
applicable test data, as defined in the TestCase during execution.
¾ It is possible to temporarily disable ExecutionEntries within an ExecutionList.
This can be done using the [F7] button.
65
MANUAL TESTING
Objective
¾ ExecutionList linked to the corresponding RequirementsSet.
Instructions
1. Drag and Drop the ExecutionList View onto the corresponding
RequirementSet Webshop | Non-functional in the Requirements Section.
2. Add the Columns Execution State and Coverage Executed in preparation for
the next exercise.
Hints
¾ It is only possible to link an ExecutionList to a RequirementSet.
¾ Multiple ExecutionLists can be linked to a single RequirementSet.
66
MANUAL TESTING
Objective
¾ Running an ExecutionList.
Instructions
1. Select the ExecutionList View and select the command Run as Manual
TestCase in the context menu.
2. After execution, analyze the results at the level of the ExecutionList View.
3. Also observe the results at the level of the RequirementSet Webshop | Non-
functional within the Requirements section.
Hints
¾ Test results within the ExecutionLists section will automatically update the
results of linked ExecutionEntries in the Requirements section.
¾ The weight of a Requirement and TestCase Link is crucial when interpreting the
results displayed in the Requirements section.
67
MANUAL TESTING
Objective
¾ Creation of a report from the ExecutionList section and a report from the
Requirements section as two separate pdf files.
Instructions
1. Expand the ExecutionList View to show all of the ExecutionEntries.
2. Click on the printer symbol on the top right corner of the window in the
ExecutionLists section.
7. Click on the printer symbol on the top right corner of the window of the
Requirements section.
Hints
¾ In such case that a pdf reader is not installed on the computer, please choose
Preview as the preferred output format.
¾ Tosca also includes a license for the List & Label Report Designer, which can be
started directly from the Tosca Commander.
¾ For further information on creating custom reports please contact Tricentis.
68
MANUAL TESTING
Summary
Objectives achieved
¾ Creation of manual test cases for the web shop sample application.
What’s next?
1. Test your knowledge by taking the Manual Testing online exam.
2. Continue with exercises for Automated Testing.
69
MANUAL TESTING
Notes
70
AUTOMATED TESTING
AUTOMATED TESTING
6 AUTOMATED TESTING
Table of Contents
Introduction ............................................................................................................. 72
Prerequisite .............................................................................................................. 74
Exercise 1 | Creation of a Module ......................................................................... 76
Exercise 2 | Creation of a TestCase....................................................................... 78
Exercise 3 | Use of the ActionMode Buffer .......................................................... 80
Exercise 4 | Use of the ActionMode Verify 1 ........................................................ 81
Exercise 5 | Use of the ActionMode Verify 2 ........................................................ 82
Exercise 6 | Use of Dynamic Values 1 ................................................................... 84
Exercise 7 | Use of Dynamic Values 2 ................................................................... 85
Exercise 8 | Templates 1 ........................................................................................ 86
Exercise 9 | Templates 2 ........................................................................................ 88
Exercise 10 | Link TestCases to Requirements .................................................... 90
Exercise 11 | Building an Execution List ............................................................... 92
Exercise 12 | Link ExecutionList to RequirementSet........................................... 93
Exercise 13 | Executing an Execution List ............................................................ 94
Exercise 14 | Print a Report ................................................................................... 95
Exercise 15 | Final Exercise – all Sections ............................................................. 96
Summary .................................................................................................................. 97
Notes ......................................................................................................................... 98
Introduction
The Automated Testing exercises will guide you through the process of creating
automated test cases.
You will use Cross Browser Test Automation for creating those TestCases. Some of
the already prepared Modules that you will use have been created using the
Browser Engine – you can mix those two kinds of Module as necessary.
You will learn
How to scan the sample web shop application and define the basis for steering
the sample application
How to create automated test cases with and without a test case design
structures
72
AUTOMATED TESTING
How to link the test cases to the corresponding Requirements in the Requirement
section
How to execute the automated test cases in the ExecutionLists section
How to interpret the test results and create a basic report in the ExecutionLists
section
73
AUTOMATED TESTING
Prerequisite
Objective
¾ Registration of a working personalized user in the web shop sample application.
Instructions
1. Start the web shop sample application in Internet Explorer.
2. Click on “Register” (red button, on the top right corner of the page). You are
now redirected to the “Register” page.
3. Fill in the mandatory fields with the data provided below in the business
context.
6. Fill in the same data in the address as the one provided for registering, adding
the information required, detailed in the Business context below.
74
AUTOMATED TESTING
75
AUTOMATED TESTING
Objective
¾ A Module, which allows to steer certain controls in the sample web shop
application automatically, is available.
Instructions
1. Open the web shop sample application.
3. Start the Tosca XScan by right-clicking on the folder Customer >> Login in the
Modules section and choosing Scan Application >> Browser.
4. In the XScan window, select the tab where the Login screen is open and click
on start.
5. Select and rename the necessary controls as seen in the screenshot below.
Use names that correspond to the business function of the controls.
Hints
¾ On the right-hand side of your open XScan window you can check the various
control states of a control once it has been selected. For example, you can view
if a control is enabled or visible at the time of scanning.
¾ If you do not see the property you are looking for, click on load all properties.
76
AUTOMATED TESTING
77
AUTOMATED TESTING
Objective
¾ Have a technically sound and working TestCase.
Instructions
1. Create a TestCase called Webshop Order | Basic in the folder Webshop |
Frontend >> Product >> Order Process >> Automated.
2. Go to the Tab Test Configuration
3. Right click on the TestCase and choose Create>>Test configuration parameter
4. For the Test configuration parameter Name, enter: ”Browser”
5. For the Test configuration parameter Value, enter: ”InternetExplorer”
6. Please follow the path through the application as follows:
¾ Log in to the application
¾ Put the smartphone to the shopping cart
¾ Go to the shopping cart
¾ Complete the checkout process
¾ Look at the order details
¾ Log out of the application
7. Use the following Modules to get started with building the TestCase:
¾ Navigation | Top Menu Æ Click on “login”.
¾ Login page Æ Fill in “username” and “password”, click on “login”.
¾ Navigation | Product Choice Tabs Æ Click on “electronics”.
¾ Electronics Page Æ Click on “cell phones”.
¾ Cell Phone Page Æ Add “smartphone” to cart.
¾ Navigation | Top Menu Æ Click on “shopping cart”.
¾ Shopping Cart | Physical Objects Æ Check “terms of service agreement”,
click on “checkout”.
78
AUTOMATED TESTING
Business context
¾ Product: Smartphone
¾ Payment method: Credit Card
¾ Shipping method: by ground
¾ Billing and Shipping address: leave blank in Tosca (this automatically chooses the
default value of a drop-down list)
¾ Card type: Visa
¾ Cardholder name: Steven Bowen
¾ Expiration date: next month, next year
¾ Card number: 4485564059489345
¾ Card code: 123
Hints
¾ Modules are assigned to a TestCase by Drag&Drop (this creates a TestStep).
¾ By using the command Run in Scratchbook you can always check if your
TestCase is working so far even while you are building it. This is a very powerful
tool during the creation of TestCase – but it does not save any results!
¾ At the properties of a TestCase you can set the TestCaseWorkstate to three
different states. This influences the Test Coverage shown in the Requirements
section when conncted. The three workstates are:
¾ PLANNED
¾ IN_WORK
¾ COMPLETED
79
AUTOMATED TESTING
Objective
¾ Save a value from the web shop sample application for later use.
Instructions
1. Copy the TestCase Webshop Order | Basic and name the copy “Webshop Order
| Buffer”.
Hints
¾ You can look up all the buffered values currently in your system by going to Tools
>> Settings >> Engine.
¾ If you are buffering a value from a table, the name of the buffer must be written
into the TestStepSubValue Action.
80
AUTOMATED TESTING
Objective
¾ Have a TestCase that uses the previously created buffer to verify a
corresponding value.
Instructions
1. Make sure the shopping cart is empty before running the TestCase.
2. Copy the TestCase Webshop Order | Buffer and name the copy “Webshop
Order | Verify 1”.
3. Verify the price of the product in the shopping cart. This can be found in the
table Price, row Sub-total, column #2. The required ActionProperty is
InnerText.
Business context
¾ The price is displayed again in the shopping cart.
Hints
¾ Always remember to set the ActionProperty.
¾ Stored buffer values can be used at any stage during test execution:
{B[name of saved variable]}.
81
AUTOMATED TESTING
Objective
¾ Have a TestCase that verifies the control properties (e.g. visibility, colour,
existence…) of a given control.
Instructions
1. Copy the TestCase Webshop Order | Basic and name the copy “Webshop Order
| Verify 2| Button”.
4. Check the business context section below for all the properties that need to be
verified.
Business context
¾ The control “I agree with the terms of service and I adhere to them unconditionally” on
the shopping cart page must be:
¾ Enabled
¾ Visible
¾ Not checked (not selected)
Hints
¾ The following values need to be set to verify if the control is enabled:
¾ ActionProperty: Enabled
¾ Value: True
¾ The values entered in the fields ActionProperty and Value are case sensitive.
82
AUTOMATED TESTING
83
AUTOMATED TESTING
Objective
¾ Have a TestCase that automatically sets a new and random numeric value at a
given place every times it runs.
Instructions
1. Copy the TestCase Webshop Order | Basic and name the copy “Webshop Order
| RND“.
2. Set the zip code on the shopping cart page to a random 4 digit number.
3. Add TestSteps if necessary.
4. Change the value of the relevant TestStep to {RND[4]}.
5. Run the TestCase.
6. Save your changes.
Hints
¾ It is possible to combine this with set values or other dynamic values. For
example, 001 {RND[3]} {RND[6]} will give you an U.S. American phone number
with a 3 digit prefix and a 6 digit number.
84
AUTOMATED TESTING
Objective
¾ Have a TestCase that automatically sets a date a given amount of time in the
future – always calculated from the day your test runs.
Instructions
1. Copy the TestCase Webshop Order | RND and name the copy “Webshop Order
| Expiration date“.
2. At the time of the checkout, set the expiration date of a credit card to 2 months
and 3 years in the future with the help of dynamic values.
3. Add TestSteps if necessary.
4. Change the value of the relevant TestSteps by using the command {DATE[][][]}
5. Run the TestCase.
6. Save your changes.
Hints
¾ You can add or subtract Years (y), Months (M) or Days (d) from any given date
function in Tosca. This calculation is always based on your system date.
85
AUTOMATED TESTING
Exercise 8 | Templates 1
Objective
¾ A basic Template connected to a TestSheet to build on in further exercises.
Instructions
1. Copy the TestCase Webshop Order | Expiration date and name the copy
“Webshop Order | Template 1“.
2. Set the TestCaseWorkstate to COMPLETED.
3. Use the command convert to Template out of the context menu.
4. Arrange the Tosca windows in a way that you can see both the TestCase and the
TestCase Design sections.
5. Go to the TestSheet Webshop | Frontend | Order process in the folder
Webshop | Frontend >> Product.
6. Connect the TestSheet to the Template.
7. In your TestSheet, navigate to the Attribute: Precondition >> Customer >>
Customer Data. Change the email address that is currently written in the Sub-
Attribute Value | Username to the email address you used when registering.
8. Link the corresponding Attributes / Instances to the TestStepValues and
TestStepSubValues in your TestSheet. Please note, that if a value field is already
populated, the value should first be deleted:
86
AUTOMATED TESTING
9. The process is however not yet complete. Complete this process for all
remaining TestStepValues in your Template.
10. Check your Template by using the Check Template command out of the
context menu.
11. Use the command Create > TemplateInstances to create your TestCases.
14. As you see, only the first TemplateInstance is able to run through the
application – how to solve this problem will be shown in the next exercise.
Hints
¾ For connecting a TestSheet to a Template you have to drag & drop the
TestSheet to a Template. Only one TestSheet can be connected to one
Template. A TestSheet may however be connected to several Templates.
¾ When connecting a TestSheet to a Template you might get a message about
ambiguous names. This message tells you that there are several Attributes on
the TestSheet with the same name, meaning Tosca cannot connect them
automatically.
¾ The imported TestSheet is based on the TestSheet you’ve created in the TCD
module. It has been detailed by the business unit of the company in order to
have all the necessary information inside.
¾ Always use Check Template before creating TemplateInstances.
¾ You can either link the Attributes by using drag & drop operations from the
TestSheet to the Template or link them manually by using the syntax:
{XL[Attribute]} – [XL[Verifications.Messages]}.
¾ The TestCase Design gives you a unique test focus, which is reflected in your
verifications. Building a TestCase without any verifications will most likely not
fulfill your test focus.
87
AUTOMATED TESTING
Exercise 9 | Templates 2
Objective
¾ Have a Template that uses conditions to cover different branches in the
application.
Instructions
1. Copy the Template Webshop Order | Template 1 and name the copy “Webshop
Order | Template 2“.
2. Modify your Template, to also reflect the order process for ordering a notebook.
You can find information / data about this process in the TestSheet.
6. Create the TemplateInstances and have a look at your InstanceFolder and the
TestCases inside.
Hints
¾ To set a condition, add the column condition via the column chooser. A
condition is set by dragging & dropping an Instance from the connected
TestSheet column into the row of your TestStep / TestStepFolder within the
Template.
88
AUTOMATED TESTING
89
AUTOMATED TESTING
Objective
¾ TestCaseLinks at the correct Requirements.
Instructions
1. Arrange the Tosca windows in a way that you can see both the Requirements
and the TestCase sections.
2. Drag and Drop the TestCases out of your second TemplateInstance folder
created in Exercise 9 onto the Requirement Webshop | Frontend >> Product >>
Order Process in the Requirements Section.
Hints
¾ The TestCaseWorkStates are weighted (in regard to the Coverage Specified) as
follows:
¾ PLANNED: .... 20%
¾ IN_WORK: ..... 50%
¾ COMPLETED: 100%
¾ Coverage Specified is calculated by the formula: TestCase Workstate [%] x
Relative Weight [%].
¾ The TestCaseWorkState can be changed at the properties tab of any given
TestCase or Template. A TemplateInstance will inherit the Template´s
Workstate.
90
AUTOMATED TESTING
¾ In the Column Required TestCases you are shown the number of TestCases you
need to create for every Requirement – based on the Instances built and
connected from the TestCaseDesign section.
91
AUTOMATED TESTING
Objective
¾ Creation of a ready-to-run ExecutionList.
Instructions
1. Arrange the Tosca windows in a way that you can see both the TestCases and
the ExecutionLists sections.
2. Switch to the ExecutionLists section and within the section select the folder
Webshop | Frontend >> Product >> Automated.
8. Add the TestCases created in Exercise 9 to the ExecutionList, using drag &
drop.
Hints
¾ You can always disable ExecutionEntries inside your ExecutionLists by using the
command Disable or the key [F7], if you don´t want to run them without
deleting them from the ExecutionList.
¾ If you do not set a Test configuration parameter for the ExecutionList, the
parameter that was set for the TestCase will be the one used.
92
AUTOMATED TESTING
Objective
¾ Connect the ExecutionList to the corresponding RequirementsSet
Instructions
1. Drag and Drop the ExecutionList onto the corresponding RequirementSet in
the Requirements Section.
2. Save your changes.
93
AUTOMATED TESTING
Objective
¾ Running an ExecutionList to analyze and report the execution results.
Instructions
1. Run the ExecutionList.
2. View the results.
3. Go back to the Requirements Section.
4. Add the Columns Execution State and Coverage Executed.
5. View both.
6. Save your changes.
Hints
¾ The results you see in the column Execution State differ from the results you
see in the ExecutionList section because the risk assessment / weight of the
Requirements is taken into account.
¾ When using more than one ExecutionList for a RequirementSet, you can
change the Result Aggregation at the Properties of the RequirementSet. You
have two options:
¾ First: will take only the first ExecutionList into account.
¾ Each: will combine the results.
¾ This only applies for ExecutionEntries that are in more than one of those lists.
If you have ExecutionEntries only in one of those lists, they will be taken into
account no matter what.
94
AUTOMATED TESTING
Objective
¾ Have a report of the ExecutionList section and a report of the Requirement
section printed as pdf files.
Instructions
1. Expand the ExecutionList to show the ExecutionEntries.
2. Click on the printer symbol on the top right of the ExecutionList section.
3. Print as pdf, take a look at the pdf.
4. Switch to the Requirements section.
5. Expand the RequirementSet you have connected the ExecutionList to.
6. Click on the printer symbol on the top right of the Requirements section.
7. Print as pdf, take a look at the pdf.
8. Compare both reports.
9. Save your changes.
Hints
¾ Tosca also includes a license for the List & Label Report Designer, which you
can start directly from the Tosca Commander. We suggest to contact Tricentis
for building custom reports.
95
AUTOMATED TESTING
Objective
¾ Have an increased test portfolio, created out of the already existing Template.
Instructions
1. Copy the Template Webshop Order | Template 2 and name the copy ”Webshop
Order | Template Final”.
2. Modify your Template, to reflect the order of a digital download, as well as the
order of a product that costs between $2 and $49. You can find information /
data about this process in the TestSheet in the Instances Digital Download and
Price (1,50) or Price 2-49. These two Instances are marked, at the Attribute
Instantiation, as Exercise 15.
3. Modify the template Webshop Order | Template Final by using all necessary
modules and conditions to cover the two cases.
4. Create the TemplateInstances.
5. Connect them to corresponding Requirement.
6. Update your ExecutionList.
7. Run the ExecutionList.
8. Review the results.
Business context
¾ Digital Download
¾ Pay attention to this TestCase, as the the way through the checkout will differ to the
one we’ve seen so far.
¾ Price (1,50)
¾ With this TestCase, we want to make sure that the shipping costs are applied. You
can verify the shipping costs in your shopping cart.
96
AUTOMATED TESTING
Summary
Objectives achieved
¾ Creation of Modules using the Tosca XScan as a basis for automated testing.
¾ Creation of automated test cases for the web shop sample application.
CONGRATULATIONS!
You have completed all exercises required to become a professional Tosca user!
What’s next?
1. Test your knowledge by taking the Automated Testing (Cross Browser) online
exam.
2. Should you wish to increase your Tosca skills, Tricentis offers you the possibility
of doing additional exercises which can be found in the Student Case Scenario
Workbook available for download on our learning platform.
97
AUTOMATED TESTING
Notes
98
GLOSSARY
7 GLOSSARY
Frontend User interface (presentation layer) between the
user and the back end
The front end faces the user, and the back end
launches the programs of the operating system in
response.
99