0% found this document useful (0 votes)
18 views37 pages

Risk Based Testing

Risk-based testing (RBT) prioritizes testing activities based on the likelihood and impact of risks in software modules, ensuring high-risk areas are defect-free. It can be applied in both Agile and Waterfall methodologies, emphasizing early validation of high-risk modules and optimized regression testing. Additionally, security testing is crucial for identifying vulnerabilities, with various methodologies and roles defined to enhance the security of software systems.

Uploaded by

Hamza Main
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views37 pages

Risk Based Testing

Risk-based testing (RBT) prioritizes testing activities based on the likelihood and impact of risks in software modules, ensuring high-risk areas are defect-free. It can be applied in both Agile and Waterfall methodologies, emphasizing early validation of high-risk modules and optimized regression testing. Additionally, security testing is crucial for identifying vulnerabilities, with various methodologies and roles defined to enhance the security of software systems.

Uploaded by

Hamza Main
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 37

RISK BASED TESTING

DEFINITION
• Risk-based testing (RBT) means managing, prioritizing, and executing
testing activities based on the likelihood and impact of risks in
different functional software modules.
Does your project need risk-based testing?
Mission-critical software
You deal with mission-critical software (e.g., online banking application,
electronic health records application) and want to make sure that high-risk
software modules are defect-free.
You can ensure the quality of high-risk modules by:
• Assigning the most experienced, domain-trained test engineers to test such
modules.
• Testing high-risk modules before other application areas, at the point when
defects are easier to fix.
• Testing critical functionality with multiple data points.
• Applying advanced software testing techniques, for instance, decision table,
state transition diagram.
TESTING IN AGILE
• You follow Agile and have to cut down test coverage to stick to sprint
deadlines without compromising software quality.
• The key to optimizing testing in Agile is streamlining regression
testing. For that, organize two regression test suits – a partial
regression test suit comprised of test cases covering high-risk
functionality and a full regression test suit comprising test cases
covering all implemented modules. Running a partial regression test
suit of a considerably smaller volume will help you speed up testing
while ensuring that critical functionality is covered.
Risk based Testing using waterfall
You follow Waterfall and have to shorten the testing phase to release on
time as development took longer than estimated. You can start
validating high-risk software modules before development is finished.
To exclude the chance of regression though, make sure that the test
cases executed during development validate isolated software modules
that won’t be affected by the implementation of new features.
RISK BASED TESTING ROADMAP
1. Identify product risks
2. Analyze the risks and prioritize software modules.
3. Plan, design, and execute testing activities according to the modules’
prioritization.
4. Monitor and review the risk.
Significance of risk based testing
• Risk-based testing can help you deliver high-quality software with the
optimal effort.
• Whether you want to ensure the coverage of critical software
functionality or optimize testing efforts without compromising
software quality, risk-based testing might be an option for you to
consider.
Identify product risks
• Cooperating with software architects and developers, who are well
acquainted with an application’s risk areas, our test team analyzes
software requirements, design specifications, and other available
project documentation and identifies potential risks for all functional
software modules.
Analyze the risk and prioritize software Modules

Test team defines risk probability and impact. To state risk


probability for a particular software module, we analyze its
complexity, dependability on other modules, the technology
used for implementation, the experience of developers with the
technology, and other relevant factors. To assess risk impact,
we analyze the frequency of a module’s usage, its business
priority, the cost of rework, potential financial damage, and
other factors. According to the identified information, we rank
software modules as high-, medium-, and low-risk.
Plan, design, and execute testing activities
according to the modules’ prioritization.

• To prioritize software testing activities quicker, we rely on the


following matrix:
• We assign test engineers with deepest expertise in the required domain
to test high-risk modules early in the SDLC and with advanced testing
techniques. Low-risk modules, on the other hand, can be validated
later in the delivery cycle by test engineers with less domain expertise
and using simpler testing techniques (e.g., equivalence partitioning).
Intuitive and Experience-based
testing
Agenda
• Intuitive Testing
• Exploratory Testing
• Beyond the Two
INTUITIVE TESTING
• Can uncover faults overlooked by systematic testing.
• Basis of this method is the skill, experience and knowledge of the
tester.
• Should NOT be applied as the primary testing technique.
• Instead, this technique should be used to support and complete the
choice of test cases through systematic testing techniques.
Exploratory testing
• One of the intuitive testing techniques.
• Helps if the documents, which form the basis for test design, are of
very low quality or do not exist at all.
• The technique is also applicable when time is severely restricted
because it uses much less time than other techniques.
• The test object is explored and new test cases are determined and
executed when knowledge about the object is collected. Results of one
test case influence the design and execution of further test cases.
• Makes sense for testing small objects for hour or two.
Test completion criteria
• The criterion is coverage of the list of possible errors.
• Intensity and completeness of intuitive and exploratory test design
cannot be measured.
Checklist based testing
• Uses a high-level list of items to be noted, checked or remembered, or
set of rules to verify the product against.
• Checklists are built based on standards, experience or other
considerations.
Examples: checklists of UI standards, checklist of core functionalities
of the system.
ATTACKS
• Direct focused evaluation by attempt to force specific failures to
occur.
• Principle of attack is based on interaction between software and its
environment, including UI, OS with kernel, APIs and file systems.
• Interactions are based on data exchanges, and misalignment in those
can be the cause of a failure.
When To Use
• No specifications are available.
• There is poor documentation of the system under test.
• Insufficient time to design and create test procedures.
• Testers are experienced in the domain and/or the technology.
• Seek diversity from scripted testing.
• Analyze operational failures.
Experience based techniques
• When applying experience based test techniques, the test cases are
derived from the tester’s skill and intuition. Their past works with
similar applications and technologies also play a role in this. These
techniques can be helpful in looking out for tests that were not easily
identified by other structured ones. Depending on the tester’s
approach, it may achieve widely varying degrees of coverage and
effectiveness. Coverage can be difficult to assess and may not be
measurable with these techniques.
When should we use experience based technique?

• Requirements and specifications are not available.


• Requirements are inadequate.
• Limited knowledge of the software product.
• Time constraints to follow a structured approach.

Once the structured testing is complete, there can be an opportunity to


use this testing technique. It will ensure the testing of important and
error-prone areas of applications.
Examples
you test an eCommerce application like Amazon, there are some scenarios that a tester
would know from his experience that a casual user might not try such as:

• Enter a negative value in the quantity field.


• Order multiple products or quantities, apply a discount code on the cart value, and then
return some quantity. E.g. if you bought 3 quantities at 100 each and then applied a
10% discount your final amount is 270. When you return one quantity, you should get
90 refunded and not 100.
• Also, try loging in to multiple sessions and see if cart gets updated correctly.
• Add a product in cart and make it out of stock from the backend.
• Add product to cart, enter payment details, and just before clicking place order make it
out of stock from the backend.
Security testing
• Security testing is a process intended to reveal flaws in the security
mechanisms of an information system that protect data and maintain
functionality as intended.
• Security testing is a type of Software Testing that uncovers
vulnerabilities, threats, risks in a software application and prevents
malicious attacks from intruders.
PURPOSE OF SECURITY TESTING
• The purpose of Security Tests is to identify all possible loopholes and
weaknesses of the software system which might result in a loss of
information, revenue, repute at the hands of the employees or
outsiders of the Organization.
Why security testing is importance?
• The main goal of Security Testing is to identify the threats in
the system and measure its potential vulnerabilities, so the
threats can be encountered and the system does not stop
functioning or can not be exploited. It also helps in detecting
all possible security risks in the system and helps developers
to fix the problems through coding.
Types of Security Testing in Software Testing
• There are seven main types of security testing as per Open Source Security
Testing methodology manual.

• Vulnerability Scanning: This is done through automated software to scan a


system against known vulnerability signatures.
• Security Scanning: It involves identifying network and system weaknesses, and
later provides solutions for reducing these risks. This scanning can be performed
for both Manual and Automated scanning.
• Penetration testing: This kind of testing simulates an attack from a malicious
hacker. This testing involves analysis of a particular system to check for potential
vulnerabilities to an external hacking attempt.
• Risk Assessment: This testing involves analysis of security risks observed in the
organization. Risks are classified as Low, Medium and High. This testing
recommends controls and measures to reduce the risk.
• Security Auditing: This is an internal inspection of Applications and
Operating systems for security flaws. An audit can also be done via
line by line inspection of code
• Ethical hacking: It’s hacking an Organization Software systems.
Unlike malicious hackers, who steal for their own gains, the intent is
to expose security flaws in the system.
• Posture Assessment: This combines Security scanning, Ethical
Hacking and Risk Assessments to show an overall security posture of
an organization.
How to do Security Testing

• It is always agreed, that cost will be more if we postpone security


testing after software implementation phase or after deployment. So, it
is necessary to involve security testing in the SDLC life cycle in the
earlier phases.

• Let’s look into the corresponding Security processes to be adopted for


every phase in SDLC
SDLC Phases Security Processes
Security analysis for requirements and
Requirements
check abuse/misuse cases
Security risks analysis for designing.
Design Development of Test Plan including security
tests
Static and Dynamic Testing and Security
Coding and Unit Testing
White Box Testing
Integration Testing Black Box Testing
Black Box Testing and Vulnerability
System Testing
scanning

Implementation Penetration Testing, Vulnerability Scanning

Support Impact analysis of Patches


The test plan should include
• Security-related test cases or scenarios
• Test Data related to security testing
• Test Tools required for security testing
• Analysis of various tests outputs from different security tools
Example Test Scenarios for Security Testing

Sample Test scenarios to give you a glimpse of security test cases –


• A password should be in encrypted format
• Application or System should not allow invalid users
• Check cookies and session time for application
• For financial sites, the Browser back button should not work.
Methodologies/ Approach / Techniques for Security Testing

In security testing, different methodologies are followed, and they are as


follows:
• Tiger Box: This hacking is usually done on a laptop which has a
collection of OSs and hacking tools. This testing helps penetration
testers and security testers to conduct vulnerabilities assessment and
attacks.
• Black Box: Tester is authorized to do testing on everything about the
network topology and the technology.
• Grey Box: Partial information is given to the tester about the system,
and it is a hybrid of white and black box models.
Security Testing Roles

• Hackers – Access computer system or network without authorization


• Crackers – Break into the systems to steal or destroy data
• Ethical Hacker – Performs most of the breaking activities but with
permission from the owner
• Script Kiddies or packet monkeys – Inexperienced Hackers with
programming language skill
Junit test scripting
• JUnit is a unit testing open-source framework for the
Java programming language. Java Developers use this
framework to write and execute automated tests. In
Java, there are test cases that have to be re-executed
every time a new code is added. This is done to make
sure that nothing in the code is broken.
• JUnit has several graphs that represent the progress of a test.
When the test runs smoothly, the graph displays a green
color, and it turns red if the test fails. JUnit Testing enables
developers to develop highly reliable and bug-free code.
• JUnit plays a huge role when it comes to regression testing.
Regression Testing is a type of software testing that checks if
the recent changes made to the code do not adversely affect
the previously written code.

You might also like