bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 2
Test DesignVampV CoE
Company Confidential 3
Pre-requisites
The participants have attended amp completed the course for
bull Art of Software Testing
bull Task Based Approach
Recommended ndash Understanding of
bull Use Case Diagram
bull Domain Model E-R Diagram
Company Confidential 4
Evolution of Test Design Techniques
Risk Based Test Design
Art of Software Testing
Task Based Approach
Use Case Interaction
Company Confidential 5
Table of Contents
bull Test Design ndash Definition amp Introduction bull Test Design Tools Techniques bull Functional Testing bull Business Process Testing
o Use Case Diagram o Developing test scenarios from
Use Case Interaction Matrix Entity Interaction Matrix Use Case ndash Entity Interaction Matrix
o Role Based Access Testing o System Testing
bull Requirements Verification o Eight point check o Traceability Matrix
bull Risk Based Testing o Risk Identification o Risk Assessment o Risk Value Calculations o Test Prioritization
bull Case Study
Company Confidential 6
Test Design ndash Definition amp Introduction
bull Test design is a technique for creating developing effective and efficient test cases
bull Many of the elemental design components can be chained together into anall- encompassing test design that executes a series of test cases
Company Confidential 7
Test Design - Introduction (Contd hellip)
In the IT industry often two groups of people are doing Software Testing
bull The Developers who build the software application want to make sure the final
product works as intended
bull The end users who will be using the final product do ad-hoc testing based on their
work experience
bull The testing done by developers is done from technical perspective without relating
back to the business
bull End users make assumptions of how the application should work that come from their
individual needs and ideas Their approach is more trial and error than systemized
testing and hence can create lot of rework
Company Confidential 8
Test Design - Introduction (Contd hellip)
Integration of STLC with SDLC
Company Confidential 9
Functional Testing
In the context of todayrsquos presentation
bull A business function is a Unit By Unit testing we refer to testing a business function
For Example ndash
The MS Outlook application can have following business Functions-
bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 3
Pre-requisites
The participants have attended amp completed the course for
bull Art of Software Testing
bull Task Based Approach
Recommended ndash Understanding of
bull Use Case Diagram
bull Domain Model E-R Diagram
Company Confidential 4
Evolution of Test Design Techniques
Risk Based Test Design
Art of Software Testing
Task Based Approach
Use Case Interaction
Company Confidential 5
Table of Contents
bull Test Design ndash Definition amp Introduction bull Test Design Tools Techniques bull Functional Testing bull Business Process Testing
o Use Case Diagram o Developing test scenarios from
Use Case Interaction Matrix Entity Interaction Matrix Use Case ndash Entity Interaction Matrix
o Role Based Access Testing o System Testing
bull Requirements Verification o Eight point check o Traceability Matrix
bull Risk Based Testing o Risk Identification o Risk Assessment o Risk Value Calculations o Test Prioritization
bull Case Study
Company Confidential 6
Test Design ndash Definition amp Introduction
bull Test design is a technique for creating developing effective and efficient test cases
bull Many of the elemental design components can be chained together into anall- encompassing test design that executes a series of test cases
Company Confidential 7
Test Design - Introduction (Contd hellip)
In the IT industry often two groups of people are doing Software Testing
bull The Developers who build the software application want to make sure the final
product works as intended
bull The end users who will be using the final product do ad-hoc testing based on their
work experience
bull The testing done by developers is done from technical perspective without relating
back to the business
bull End users make assumptions of how the application should work that come from their
individual needs and ideas Their approach is more trial and error than systemized
testing and hence can create lot of rework
Company Confidential 8
Test Design - Introduction (Contd hellip)
Integration of STLC with SDLC
Company Confidential 9
Functional Testing
In the context of todayrsquos presentation
bull A business function is a Unit By Unit testing we refer to testing a business function
For Example ndash
The MS Outlook application can have following business Functions-
bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 4
Evolution of Test Design Techniques
Risk Based Test Design
Art of Software Testing
Task Based Approach
Use Case Interaction
Company Confidential 5
Table of Contents
bull Test Design ndash Definition amp Introduction bull Test Design Tools Techniques bull Functional Testing bull Business Process Testing
o Use Case Diagram o Developing test scenarios from
Use Case Interaction Matrix Entity Interaction Matrix Use Case ndash Entity Interaction Matrix
o Role Based Access Testing o System Testing
bull Requirements Verification o Eight point check o Traceability Matrix
bull Risk Based Testing o Risk Identification o Risk Assessment o Risk Value Calculations o Test Prioritization
bull Case Study
Company Confidential 6
Test Design ndash Definition amp Introduction
bull Test design is a technique for creating developing effective and efficient test cases
bull Many of the elemental design components can be chained together into anall- encompassing test design that executes a series of test cases
Company Confidential 7
Test Design - Introduction (Contd hellip)
In the IT industry often two groups of people are doing Software Testing
bull The Developers who build the software application want to make sure the final
product works as intended
bull The end users who will be using the final product do ad-hoc testing based on their
work experience
bull The testing done by developers is done from technical perspective without relating
back to the business
bull End users make assumptions of how the application should work that come from their
individual needs and ideas Their approach is more trial and error than systemized
testing and hence can create lot of rework
Company Confidential 8
Test Design - Introduction (Contd hellip)
Integration of STLC with SDLC
Company Confidential 9
Functional Testing
In the context of todayrsquos presentation
bull A business function is a Unit By Unit testing we refer to testing a business function
For Example ndash
The MS Outlook application can have following business Functions-
bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 5
Table of Contents
bull Test Design ndash Definition amp Introduction bull Test Design Tools Techniques bull Functional Testing bull Business Process Testing
o Use Case Diagram o Developing test scenarios from
Use Case Interaction Matrix Entity Interaction Matrix Use Case ndash Entity Interaction Matrix
o Role Based Access Testing o System Testing
bull Requirements Verification o Eight point check o Traceability Matrix
bull Risk Based Testing o Risk Identification o Risk Assessment o Risk Value Calculations o Test Prioritization
bull Case Study
Company Confidential 6
Test Design ndash Definition amp Introduction
bull Test design is a technique for creating developing effective and efficient test cases
bull Many of the elemental design components can be chained together into anall- encompassing test design that executes a series of test cases
Company Confidential 7
Test Design - Introduction (Contd hellip)
In the IT industry often two groups of people are doing Software Testing
bull The Developers who build the software application want to make sure the final
product works as intended
bull The end users who will be using the final product do ad-hoc testing based on their
work experience
bull The testing done by developers is done from technical perspective without relating
back to the business
bull End users make assumptions of how the application should work that come from their
individual needs and ideas Their approach is more trial and error than systemized
testing and hence can create lot of rework
Company Confidential 8
Test Design - Introduction (Contd hellip)
Integration of STLC with SDLC
Company Confidential 9
Functional Testing
In the context of todayrsquos presentation
bull A business function is a Unit By Unit testing we refer to testing a business function
For Example ndash
The MS Outlook application can have following business Functions-
bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 6
Test Design ndash Definition amp Introduction
bull Test design is a technique for creating developing effective and efficient test cases
bull Many of the elemental design components can be chained together into anall- encompassing test design that executes a series of test cases
Company Confidential 7
Test Design - Introduction (Contd hellip)
In the IT industry often two groups of people are doing Software Testing
bull The Developers who build the software application want to make sure the final
product works as intended
bull The end users who will be using the final product do ad-hoc testing based on their
work experience
bull The testing done by developers is done from technical perspective without relating
back to the business
bull End users make assumptions of how the application should work that come from their
individual needs and ideas Their approach is more trial and error than systemized
testing and hence can create lot of rework
Company Confidential 8
Test Design - Introduction (Contd hellip)
Integration of STLC with SDLC
Company Confidential 9
Functional Testing
In the context of todayrsquos presentation
bull A business function is a Unit By Unit testing we refer to testing a business function
For Example ndash
The MS Outlook application can have following business Functions-
bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 7
Test Design - Introduction (Contd hellip)
In the IT industry often two groups of people are doing Software Testing
bull The Developers who build the software application want to make sure the final
product works as intended
bull The end users who will be using the final product do ad-hoc testing based on their
work experience
bull The testing done by developers is done from technical perspective without relating
back to the business
bull End users make assumptions of how the application should work that come from their
individual needs and ideas Their approach is more trial and error than systemized
testing and hence can create lot of rework
Company Confidential 8
Test Design - Introduction (Contd hellip)
Integration of STLC with SDLC
Company Confidential 9
Functional Testing
In the context of todayrsquos presentation
bull A business function is a Unit By Unit testing we refer to testing a business function
For Example ndash
The MS Outlook application can have following business Functions-
bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 8
Test Design - Introduction (Contd hellip)
Integration of STLC with SDLC
Company Confidential 9
Functional Testing
In the context of todayrsquos presentation
bull A business function is a Unit By Unit testing we refer to testing a business function
For Example ndash
The MS Outlook application can have following business Functions-
bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 9
Functional Testing
In the context of todayrsquos presentation
bull A business function is a Unit By Unit testing we refer to testing a business function
For Example ndash
The MS Outlook application can have following business Functions-
bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 10
bull We test each Function independently as soon as it has passed Unit testing from
Developerrsquos point of view
Entry Criteria For Functional Testing
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 11
Functional Testing Techniques
bull Each component in the application should be tested for functional correctness
bull The techniques that can be used for testing functionality are Test Cases from Use cases
Field level and Form level validation test cases
bull Each function will be tested for its functionality as well as its integration with other
business functions
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 12
Exit Criteria For Functional Testing
Quality gates for the Business Function Tests are
bull All planned test cases have been executed
bull All incidents have been logged as defects
bull All identified defects have been resolved
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 13
Business Process Test
Entry Criteria for Business Process Testing - All functional tests have been carried out
What is Business Process Testing
Testing the full business process from the start to completion with focus on the correct implementation of the interfaces between the business functions is Business Process Testing
Login
Send a MailAdd a Contact
Exit
Login
Assign TaskAdd a Contact
Exit
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 14
Business Process Test (Contd hellip)
bull When it comes to business process test we need to make sure that we test various
business function sequences
For example
Login -gt Add Contact -gt Send Mail -gt Exit
bull It is important to test each possible combination between business functions at least
once For Example below is a combination of different business functions which needs
to be tested
Login -gt Adding Contacts -gt New Distribution List -gt Send Email -gt Exit
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 15
Business Process Test (Contd hellip)
bull The focus is on transition from one business function to next and not to functional
Each Business Function can be treated as a Use Case
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 16
What is Use Case Interactions
bull Use Case Interactions depict the relationships among
the Use Cases in a system
bull Use Case Interactions is a technique used to capture functional requirements of complex systems composed of many features
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 17
Testing Use Case Interactions
Why to test Use Case Interactions
bull Use Case Interactions provide the basis to validate the integration among various Use cases of an Application Hence test based on Use Case Interactions helps to perform User Acceptance Test in an effective manner
bull Study of use case interactions helps us to validate intended interactions as well as detects un-intended interactions
When to Test Use Case Interactionsbull Use case interactions are identified and specification of the interactions is captured
after related use cases are unit-tested
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 18
Use Case Relationships Symbol
Includes One Use Case uses (includes) the services
(behaviors) specified by another Use Case It is similar to a
common sub routine which can be called from many places
Uses In Uses relationship the scenario of one Use Case is
not only a part of another Use Case but also a pre condition
for the other Use Case
Extends In an extend relationship between two use cases
the child (Optional) use case adds to the existing
functionality and characteristics of the parent use case
Create New Order
Lookup Item avail
ltltincludesgtgt
Withdraw Money
Make Express Withdrawal
ltltextendsgtgt
Withdraw Money
Authenticate Customer
ltltusesgtgt
Use Case Diagram ndash Symbols amp Notations
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 19
What Is a Use Case Diagram
A use case diagram displays the relationship among actor and use cases in asystem
Use Case Interactions from Use Case Diagram bull Obtain various kinds of interactions from Use Case Diagram bull The relationships shown in the use case diagram tell how the different use cases are
interacting with each otherbull Use Case Interactions detected from use case diagram help structuring and integrating
test scenarios to validate these relationships
Input Document For MS Outlook
Use Case Diagram For MS Outlook
InputDoc for MSOutlook
UCD for MSOutlook
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Use Case- Description for MS-Outlook Example S No Use Case Description
1 Add Contact User can add Name(s) of people their numbers Email Ids and this
information can be saved in the Contact Details One or more Email Ids work numbers as well as residential numbers can be saved
2 Delete Contact
User can delete the name of a personcontact from the contact details
3 Edit Contact User can edit the Contact details for a particular person like name phone
number Email Id Task Appointment and Meeting assigned to the contact can be changed
4
Send Mail Mail can be sent to a contact from the contact details after verifying email id from the Contact details Attachments can be sent to a person (or a group of people in case of a distribution list)
5 Receive Mail Looks up the contact details and displays the mail message senderrsquos name as stored in the contact details (if it exists in the contact list of the user)
6 Create Distribution List
Refers to contact details for creating a distribution list
7 Assign Calendar User assigns date amp time in order to request meetings assign tasks and verify the schedules of the contacts for the appointments
8 Assign Task User assigns a task to the contact with details like required date time and schedule from the calendar for the particular contact
9 Make Appointment
User gets the appointment created with all the specifications like day time intended contact and the request approval from the contact
10 Make a Meeting Request
User creates a Meeting Request with all the specifications like day time intended contact and the request approval from the contact
11 Verify Address Verify Email Address from Contact list if it exists in the contact list It also verifies whether the email id specified is correctly formed
kulkarmr
File Attachment
InputDocument_MSOutlookpdf
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Example - Use case Diagram for MS-Outlook
Add Contact
Assign Calendar
Delete Contact
ltltusesgtgt
Edit Contact
ltltusesgtgt
Send Mail
ltltincludesgt
Receive Mail
Make Appointment
ltltincludesgtgt
Assign Task
Userltltusesgtgt
Create Distribution List
ltltincludesgt
ltltincludesgt
Verify address
ltltusesgtgt
ltltincludesgt
ltltincludesgt
ltltusesgtgtltltextendsgtgt
Make a meeting request
kulkarmr
File Attachment
UseCaseDiagram_MSOutlookpdf
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 20
Use Case ndash Use Case Interactions Matrix
bull Derive Use Case ndash Use Case Interaction Matrix which captures the explicit interaction among the Use Cases of a system
Use Case ndash Use Case Matrix
Use Case 1
Use Case 2
Use Case 3
Test for Validating the
InteractionsAmong the Use cases
Interactions among Use Cases
Extends
Uses
Includes UC-UC Interaction Matrix
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Use Case -Use Case Interaction Matrix
Use CaseUse Case
Send Mail
Receive Mail
Add Contact
Delete Contact
Edit contact
Assign Calendar
Make Appointment
MakeMeeting Request
Verify Address
Create Distribution List Assign Task
Send Mail Receive Mail Add ContactDelete Contact Edit Contact Assign CalendarMake Appointment Make A Meeting Request Verify Address Create Distribution List Assign Task
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
From the Use Case Interaction Matrix we will now identify different Test Scenarios to creats Test Cases
Sr No Test Scenario Description Expected Result
1
Sending mails includes adding contacts
User specifies the e-mail address of the contact adds the email id in his contact list and sends a mail to the added contact
The contact should be added and the user should be able to send the mail to the added contact
2
Mails can be received from the added contacts
User specifies the e-mail addressThe email id is added inthe contact listUser recieves mail from the email id which is added in the contact list
Mails can be recieved from the e-mail id thatrsquos added in the contact list
3A contact can be deleted from the added contact list
User specifies the email id and deletes it from the added contact list
User should be able to Delete a contact from the added contact list
4A contact can be edited from the added contact list
Specify the email id and contact added in the contact list and edit information for that contact
User should be able to Edit an added contact
5An appoointment can be created for an added contact
Specify the email id and a contact from the contact list and create an appointment for that contact
User should be able to create an appointment for the contact added
6
An appointment can be created using the default calendar settings
User specifes the contact from the contact list User then specifies date and time using the calendar for the specified contact
User should be able to create an appointment using the calendar for the selected contact
7
A meeting can be scheduled for an added contact
Specify the email id and a contact Schedule a meeting for that contact added in the contact list
User should be able to schedule a meeting for the specified contact added
8
Meeting can be scheduled by creating an appointment for the added contact
Specify the appointment details for the selected contactSchedule a meeting for the contact
The meeting should be scheduled for the selected contact
9
Addresses can be verified for the contacts added
Specify the email id and address for a particular contact and verifies the correct address is saved for the contact
The address for the added contacts can be verified
10
A Distribution list can be created by adding contacts
User adds contacts with their email ids numbers addresses and creates a distribution list for sending multiple emails
User should be able to create a distribution list for added contacts in the contact list
11
Tasks can be assigned to the added contact
Specify the email id and a contact from the added contact list Assign a task to the specified contact
The user should be able to assign task to the selectedspecified contact
12A task can be made by assigning a task
User makes a task and assigns it to the contact added in the contact list
User should be able to create a task and assign it to the contact
UseCase_Interactions
TestScenarios
kulkarmr
File Attachment
Copy of UseCaseInteractionMatrix_MSOutlook_1pdf
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 21
Testing Use Case Interactions (Contd hellip)
bull Once Use Case interaction matrix is created identify test scenarios from the Matrixbull Test Scenario refers to the possible different course of action that different instances
of the same use case might takebull This method of identifying Test Scenarios will ensure maximum test coverage with
optimum number of test cases bull Use Cases which are created can be directly mapped to the requirements for
Requirement Traceability
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 22
Advantages of Use Case Interactions
bull The analysis and validation of requirements only with use case is incomplete for development of complex systems It is mandatory to study the interactions among the use cases to depict an overall view of the complete functionality of the system
bull Use Case Interaction will be useful for requirements specification design testing Specifically it can be used for
bull Detection of required interaction bull Avoidance of undesirable interactions
Use Cases Interactions must be validated by the Business Users or the Client
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 23
What is an Entity
bull An entity is a thing of significance either real or conceptual (person place or thing)
about which the business or system being modeled needs to hold information
bull An entity is a self-contained piece of data that can be referenced as a unit
bull An Entity represents a discrete object
Example EMPLOYEE DEPARTMENT CAR etc Each entity in an ERD generally corresponds
to a physical table on database level
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 24
What is Entity Interactions
bullEntity Interactions depict the relationships among different entities in a system
bullEntity Interactions is a technique used to capture functional data flow between
different entities in a system
For Eg In MS Outlook User Contact Mails Calendar Meeting Appointment and
Tasks are entities
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 25
Entity Interactions (Contd hellip)
Why to test Entity Interactions
bull Entity interactions depict integration between different entities in the system
bull Testing integration between the entities help functional data flow testing of the system
bull Hence the tests based on Entity Interactions help integration testing of the system
When to test Entity Interactions
bull When the system is complex with number of entities integrated together entity
interactions would be helpful
bull Entity interactions are tested when entities involved in the system are unit-tested
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 26
What is a Domain Model
bull A domain model can be thought as a conceptual model of a system that tells about the various entities involved along with their relationships The domain model is created to understand the key concept of the system and to familiarize with the vocabulary of the system
bull Domain model for a system will display relationship between different entities in a system
Entity Interactions from Domain Modelbull Identify the entities participating in the use casesbull Obtain relationship among different entities in a system from domain modele-r diagrambull Obtain Scenario which depicts how change in one entity affects otherbull Design Test Case for each scenario
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 27
Entity Interactions from Domain Model
User SendsReceive Mails
Contacts
MaintainsSendReceive
Tasks
Assigns
Allocated to
Calendar
AppointmentCreates
Is scheduled from
MeetingOrganizes Send to
Sendreceive
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 28
Entity-Entity Matrix
bull Form Entity-Entity Matrix which shows the Referential Integrity among the entities eg A contact cannot be deleted if there exists any active Meeting Request against that contact
bull Example for Inter- form dependency Scheduling a Meeting at a particular time gets scheduled on the Calendar for selected time period
Entity - Entity Matrix
Entity 1
Entity 3
Entity 2
Entity 4
Relationship among Entities
Used ForDetecting the
Implicit Interactions
E2E Matrix
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Entity To Entity MatrixEntity Entity Calendar Appointment User Mails Tasks Contacts MeetingCalendarAppointment User MailsTasks Contacts Meeting
Entity-Entity Matrix
kulkarmr
File Attachment
EntityInteractionMatrix_MSOutlook_1pdf
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 29
Use Case ndash Entity Interactions
bull Use case and entity interactions depict relationship between use case and different
entities in a system
bull This relationship will show how the use case and different entities in the system interact
with each other
bull There can be many entities interacting with a single use case in a system
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 30
Use Case - Entity Interactions (Contd hellip)
Why to test use case and entity interactions
bull Use case and entity interactions will help us test integrations between a use case and
different entities in the system
bull It will help in the functional testing of a system
When to test use case and entity interactions
bull Use case and entity interactions are tested when there are many entities integrated with
one or more use cases
bull Use case and entity interactions are tested when use cases and entities in a system are
unit tested
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 31
Use Case-Entity Matrix
bull Use Case-Entity matrix shows association between different use cases and entities of the system This
matrix shows the use cases that would get affected by changing a particular entity Thus this matrix
would be useful for Impact Analysis
Use Case - Entity Matrix
Entity 1
Entity 2
Use Case 1
Use Case 2
Use Cases and the Participating Entities
Used ForDoing Impact
Analysis UC2Entity
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Use Case to Entity Matrix Use Case
Entity Send Mails
Receive Mails
Add Contacts
Delete Contacts
Edit contacts
Assign Calendar
Create Appointment
MakeMeeting Request
Verify Address
Create Distribution
ListAssign Task
Make Task
RequestCalendar Appointment User Mails Tasks Contacts Meeting
Sheet1
kulkarmr
File Attachment
UseCase-Entity-InteractionMatrix_MSOutlook_1pdf
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 32
Exit Criteria For Business Process Test
Possible quality gates for Business Process Test are
bull All end to end processes can be executed
bull A workaround exists for all defects found
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 33
Role Based Access Testing
What is Role Based Access Testing
Role Based Access Testing is where permissions are associated with roles and users are
assigned to appropriate roles
Where
Permissions Is an approval of a particular mode of access to one or more objects in the
system Permissions can apply to single or many roles
Example- Read access to a particular file or generic as read access to all files
belonging to a department
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 34
Role Based Access Testing (Contd hellip)
Role Is a function or job title written within the organization with some associated
semantics regarding the authority and responsibility conferred on a member of the role
User A user in this model is a human being The concept of users can be generalized
Tasks Is defined as a job Itrsquos an ongoing action requiring completion It comprises a set
of instructions
bull A User can be a member of many roles and a role can have many users
bull A Role can have many permissions and the same permission can be assigned to
many roles
bull The key for Role Based Access Testing lies in these two relations
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 35
Example Library Management system
In the working of a library management system
Different types of users are allowed to login and access the
library facilities
bull Only some users are allowed to lend an item from the system
bull Only some users are allowed to use the library resources like printers
bull Depending upon the access rights few users can add items (Books CD etc) to the
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 37
Understanding Task-Role Matrix
bull Different Roles perform different Tasks
bull Many Tasks can be performed by Many Roles
bull For a given application the access rights are specified using the Task-Role matrix
bull A ldquoYesrdquo in the matrix indicates that Role has access rights to perform the task
Nordquo indicates that role does not have access rights for that task
bull This matrix acts as a specification for the design tests
bullLibrarian has access to perform all the tasks
bullStudent has access to perform some of the tasks only
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 38
Understanding Role-User Matrix
bull For a given application the access rights for user to perform a task is specified
using the User-Role matrix
bull A ldquoYesrdquo in the matrix indicates that the User performs that particular role
Nordquo indicates that User does not have rights to perform the Role
bull Tests can be designed based on this specification In doing so each and every
cell of the matrix is tested Hence for every ldquoYesrdquo and ldquoNordquo specified in the
matrix tests are prepared
The Test design and Validation from the User-Role matrix can also be done in the similar way as done for Task-Role matrix
bull Many Users can perform Many Roles
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 39
Exit Criteria For Role Based Access Test
Possible quality gates for Role Based Access Test are
bull All access rights adhere to the specifications
bull A workaround exists for all defects found
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 40
System Test
System Test makes various applications work together as the business process requires
Goals of system test are
bull Functional Correctness All interfacing applications are in place and the application
functions correctly in the defined environment
bull Usability The product can be employed by users to achieve specified goals
effectively and efficiently in a specified context of use
bull Reliability The system can perform and maintain its functionality in routine
circumstances as well as in hostile or unexpected circumstances
bull Accessibility A system is usable by as many people as possible with modification
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 41
Exit Criteria For System Test
Possible quality gates for system test are
bull All end to end processes can be executed
bull No severe defects exist
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 42
Case Study - 1
Tasks
bull Identify Use Cases amp Entities
bull Create Use Case ndash Entity Interactions Matrix
bull Create Use Case Interactions Matrix
bull Create Entity Interactions Matrix
Use Case Diagram For MS Project
Domain Model Diagram for MS Project
UCD for MS-Project
DomainModel-MSProject
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Use case Diagram for MS-Project
Create project
Schedules task
Entering tasks
Sub-tasks
Linking tasks
User
Removing tasks
Manage resource
Resource pool
Update work
Project manager
Entering cost
Viewing cost
Budget Representative
ltltIncludesgtgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt
ltltIncludesgtgt
ltltUsesgt
ltltIncludesgtgt
ltltIncludesgtgt
ltltUsesgtgtltltUsesgt
ltltUsesgtgt
ltltUsesgtgt
ltltUsesgtgt Calendar Setting
ltltUsesgtgt
Use case Diagram for MS-Project
kulkarmr
File Attachment
UseCaseDiagram_MSProjectpdf
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Domain Model for MS-Project
User Project
Task Resource Pool
Resource Cost
Budget Representative
1 Scheduled 1
1 Schedules
1hellip Creates 1
1 allots resources
1 get Scheduled 1
1 Manages resources
1 is allotted to 1
1 Consists of
1 Gets 1
1 Does
Schedules
Assigned 1 1 is allotted to
assigns
Base Calendar Resource Calendar
Assigned to 1
kulkarmr
File Attachment
DomainModel__MSProjectpdf
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 43
Requirements Verification
Requirements Verification ensures that the system requirements are satisfied and also
that the technical derived and product requirements are verified
Software requirements are often called as specifications
In order to ensure test coverage we will be mapping requirements to the test cases
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 44
Requirements Verification (Contd hellip)
Following steps are to be taken for requirement Verification
bull Build a common reference or business analysts and IT Group similar user cases to form
one business function Split complex use case into two or more business functions
bull Link Requirements Here we can link requirements with appropriate business functions
bull For Example Login functionality for the Ms Outlook application will have requirements
related to login with Valid User name and password
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 45
Requirements Verification (Contd hellip)
bull Add Proof Points are for requirements based on changes Each requirement must have
within it a statement of the acceptance criteria
For example Requirement must specify that New page is displayed after validating
user login
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 46
Eight Point Check
It is advisable to do a check on the requirements received from the client The testing
team can take care of the following aspects ndash
The following guidelines can be used to verify requirements received from the client
Singular Consistent
Unambiguous Dependencies
Measurable Testable
Complete Traceable
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 47
Eight Point Check (Contdhellip)
Singular
Donrsquot merge or link requirements The requirement must address one and only one
thing Break the requirements down into singular Units The usage of the word and to
combine two separate thoughts into one requirement If itrsquos two separate thoughts it
should be two requirements
Unambiguous
Anything that makes you think that there are at least two different ways of understanding
the requirement amp clarification sought is ambiguous
Example The HTML Parser shall produce an HTML markup error report which
allows quick resolution of errors when used by HTML novices
The word quick is ambiguous
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 48
Eight Point Check (Contdhellip)
Measurable
Specific ranges and outcomes ndash no approximates Can you have an expected measurable
result It should be possible to construct an expected result for every requirement
Complete
No requirements or necessary information should be missing Completeness is also a
desired characteristic of an individual requirement It is hard to spot missing requirements
because they arenrsquot there
Example - ldquoThe product shall provide status messages at regular intervals not less than
every 60 seconds This requirement is incomplete as it leaves the following questions
unanswered Is the interval between status messages really supposed to be at least 60
seconds so showing a new message every 1 hour is okay
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 49
Eight Point Check (Contdhellip)
Consistent
The requirement does not contradict any other requirement and is fully consistent with
all other project documentation
Dependencies
Clearly identify the dependency of your requirements on ndash
bull Any other requirement
bull On systems which are outside the scope of the project This is prevalent in
environments where inputs come from other systems Interface requirements
need to be clearly documented and signed off by all the stakeholders
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 50
Eight Point Check (Contdhellip)
Testable
One of the major challenges we face during requirements gathering is the testability of a
requirement Very often customers come up with requirements that are not testable
To determine the testability of a requirement following questions can be asked -
bull Can we define the acceptance criteria for this requirement
If the answer is no then this requirement is not testable
bull Is this requirement clashing with any other requirement
If yes then the set of requirements are not testable
Example ndash The following requirement is not testable
10 The system shall be user-friendly
20 The user interface shall indicate the correct format for data input
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 51
Eight Point Check (Contdhellip)
Traceable
You should be able to link each software requirement to its source which
could be a higher-level system requirement a use case or a voice-of-the-customer
statement or even a change request Also link each software requirement to the
design elements source code and test cases that are constructed to implement and
verify the requirement
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 52
Requirements Traceability
bull Requirement traceability is a process of establishing the linkage between the
requirements and the testcases This helps the project in many ways
bull It indicates the extent of testing a requirement has undergone
bull It also gives a clear indication of how many requirements have gone live without
any testing
bull It also helps the testing team in identifying the impact of a requirement change
For example if a requirement is getting tested using 10 testcases a change
request will mean revisiting and retesting 10 testcases
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 53
Requirements Traceability
Traceability Matrix - A table that documents the requirements of the system
for use in subsequent stages to confirm that all requirements have been met
Requirements Id Design Specification Program Specification Test Case ID Defect ID
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 54
Risk Based Testing
Definition of Risk
Risk is the possibility of suffering harm or loss
In software testing we think of risk on three dimensions
bull A way the program could fail
bull How likely it is that the program could fail in that way
bull What the consequences of that failure could be
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 55
Risk Identification
Risk is the product of damage and probability for damage to occur Analyze the ways the software may fail Find the possible consequences of such failure modes bydetermining damage amp determining the Probability of Failure
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 56
Risk Assessment
Damage or Business Impact Business Impact is defined in terms of the damage to the
business if a failure were to occur Each business function is checked with each criterion
The result of analysis will help us divide business Functions into impact categories High
Medium Low
Impact
Criteria High Impact Medium Low
Type of Process
Calculation
Validation
Change of data Display
Business Implication Legal Wrong information None
Frequency of use Very often Often Rare
Number or
Significance of Users
Large number
Very important
Group Some
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 57
Risk Assessment (Contdhellip)
Type Of Process
This criterion has the following possible values
Calculation Validation - The feature represented by the requirement is an important
calculation or validation
Data Change - The feature represented by the requirement modifies application data
Display - The feature represented by the requirement modifies the application display
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 58
Risk Assessment (Contdhellip)
Business Implication
The impact to the business if the requirement is not met
This criterion has the following possible values
Legal - There may be legal consequences
Wrong Information - The user may receive inaccurate information but this
would not have legal consequences
No Impact - The business would not be affected
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 59
Risk Assessment (Contdhellip)
Frequency of Use
How often the feature represented by the requirement is used
This criterion has the following possible values
Very often - The feature is used very often
Often - The feature is used relatively often
Rare - The feature is rarely used
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 60
Risk Assessment (Contdhellip)
No or Significance of Users
This criterion has the following possible values
ManyHigh - The requirement affects many users or users with high importance
to the business
SomeMedium - The requirement affects some users or users with medium
importance to the business
FewLow - The requirement affects few users or users with minimal importance
to the business
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 61
Risk Assessment (Contdhellip)
Failure Probability Like business impact failure probability is the result of an
assessment based on standard criteria The criteria can be changed and adapted
depending on a given environment The business functions are divided into three
probability categories Very likely Likely and Unlikely
Probability
Criteria Very Likely Likely UnlikelyChange Type
New Feature Changed Feature Unchanged Feature
Software MaturityImmature Intermediate Mature
Defect RateA high number of defects are likely to be opened
Medium - A medium number of defects are likely to be opened
Low - A low number of defects are likely to be opened
No of affected ScreensEntities
greater than 4 between 2 and 4 less than 2
FAILURE PROBABILITY
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 62
Risk Assessment (Contdhellip)
Change Type
Whether the feature the requirement is new changed or unchanged feature
This criterion has the following possible values
bull New feature - The requirement represents a feature that is new in this release
bull Changed feature - The requirement represents a feature that previously existed but
has been changed for this release
bull Unchanged feature - The requirement represents a feature that is unchanged since
previous releases
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 63
Risk Assessment (Contdhellip)
Software Maturity
How mature is the code of feature represented by the requirement
This criterion has the following possible values
bull Immature - The code is not mature
bull Intermediate - The code is at a medium level of maturity
bull Mature - The code is at a high level of maturity
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 64
Risk Assessment (Contdhellip)
Defect Rate
An estimate of how many defects are likely to be opened that relate to the requirement
This criterion has the following possible values
bull High - A high number of defects are likely to be opened
bull Medium - A medium number of defects are likely to be opened
bull Low - A low number of defects are likely to be opened
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 65
Risk Assessment (Contdhellip)
No of Affected Screens Entities
This criterion has the following possible values
bull How many application screens and entities are affected by the requirement
bull This criterion has the following possible valuesgt 4 2-4 lt 2
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 66
Risk Value Calculations
Risk = Damage ProbabilityWhere -
Damage = (Value of Damage Factor 1 + Value of Damage Factor 2 + hellipValue of Damage Factor n)
Probability = (Value of Probable Factor 1 + Value of Probable Factor2 +hellipValue of Probable Factor n)
Hence we can derive the following formula ndashR (f) = C(f) P(f)
Where - R (f) ndash calculated risk of function fC (f) ndash cost related to a fault in function f
P (f) ndash probability of a fault in function f
Risk Calculator TemplateRisk Calculator
Template
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
RISK
Function
Type of process(a)
Impact of Failure(b)
No Significance of Users(c)
Frequency of Use(d)
Total Weighted Business Impact(x=a+b+c+d)
Change Type(p)
Software Maturity(q)
Defect Rate(r)
No of affected ScreensEntities(s)
Total Weighted Failure Probability(y=p+q+r+s)
RISK(xy)
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Sheet1
kulkarmr
File Attachment
Risk Calculatorpdf
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 67
Test Prioritization
Test Prioritization is done on the basis of identified Risk
bull Test should find the most important defects first Most important means often ldquoin the most
important functionsrdquo To find possible damage analyze how every function supports the mission and
checking which functions are critical and which are not
bull To find the probability of damage you have to decide where you expect
most failures Finding the worst areas in the product and testing them more will help you find more
defects If you find too many serious problems management will often be motivated to give you
more time and resources for testing
bull Testing in a situation where management cuts both budget and time is a bad game
You have to endure and survive this game and turn it into a success The general methodology for
this situation is not to test everything a little but to concentrate on high risk areas and the worst
areas The Prioritization of Test Cases needs to be done in consultation with the Client Customer
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 68
Test Prioritization
In the MS- Outlook example the risk value calculation is as shown below The functions with high risk should get high priority for testing
In the above example testing needs to be more focused on the high risk areasHence more test cases need to be developed around the functionalities with high risk values and fewer test cases can be developed for functionalities with low risk value
NOTE Weights for each parameter is given in the comment Please exchange the given weight numbers with your chosen weightsTypically the three values of 1 - 3 - 10 are good to determine low medium and high impact
BUSINESS IMPACT FAILURE PROBABILITY
Assumption - The MS Outlook system is fairly stable
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 69
Tasks amp Deliverables
Test Designerrsquos tasks Deliverables Test Engineerrsquos tasks DeliverablesAnalyze the Business RequirementsIdentify the Use Cases Business functions Test Scenarios
Develop Test Cases from Use Cases Create Form level test cases and field level test cases
Create Domain Use Case ModelCreate Matrices - Use Case Interactions Use case entity interactions and Entity Interactions
Verify that test cases are created for all end to end flows in the application
Create Requirements Verification matrix for all business functions
Update requirements verification matrix with Test case Ids created
Create Prioritization Matrix for Test case development and Execution
Execute developed test cases
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
bull URLs
httpwwwprocessimpactcomarticlesqualreqshtml
Slide Number 1
Test Design
Pre-requisites
Evolution of Test Design Techniques
Table of Contents
Slide Number 6
Test Design - Introduction (Contd hellip)
Test Design - Introduction (Contd hellip)
Functional Testing
Entry Criteria For Functional Testing
Functional Testing Techniques
Exit Criteria For Functional Testing
Business Process Test
Business Process Test (Contd hellip)
Business Process Test (Contd hellip)
What is Use Case Interactions
Testing Use Case Interactions
Use Case Diagram ndash Symbols amp Notations
What Is a Use Case Diagram
Use Case ndash Use Case Interactions Matrix
Testing Use Case Interactions (Contd hellip)
Advantages of Use Case Interactions
What is an Entity
What is Entity Interactions
Entity Interactions (Contd hellip)
What is a Domain Model
Entity Interactions from Domain Model
Entity-Entity Matrix
Use Case ndash Entity Interactions
Use Case - Entity Interactions (Contd hellip)
Use Case-Entity Matrix
Exit Criteria For Business Process Test
Role Based Access Testing
Role Based Access Testing (Contd hellip)
Example Library Management system
Task-Role-User Relationship
Understanding Task-Role Matrix
Understanding Role-User Matrix
Exit Criteria For Role Based Access Test
System Test
Exit Criteria For System Test
Case Study - 1
Requirements Verification
Requirements Verification (Contd hellip)
Requirements Verification (Contd hellip)
Eight Point Check
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Eight Point Check (Contdhellip)
Requirements Traceability
Requirements Traceability
Risk Based Testing
Risk Identification
Risk Assessment
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Assessment (Contdhellip)
Risk Value Calculations
Test Prioritization
Test Prioritization
Tasks amp Deliverables
References
Company Confidential 70
References
bull Writing Effective Use Cases by Alistair Cockburn
![ChapterVI Water Flood Design_ Surveillance [Compatibility Mode]](https://img.dokumen.tips/doc/110x75/5520d1674979590a3f8b4c07/chaptervi-water-flood-design-surveillance-compatibility-mode.jpg)
