0% found this document useful (0 votes)
12 views

5 Software Testing

Uploaded by

Jennifer Lopez
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views

5 Software Testing

Uploaded by

Jennifer Lopez
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 57

The Software Development Life Cycle

Comprises of 5 major phases:

1)Analysis Phase
2)Design Phase
3)Coding Phase
4)TESTING Phase
5)Operational Phase
WHAT DOES
TESTING MEAN??
Various definitions :

• In 1973, Hetzel defined “Testing is the process of establishing confidence


that a program or a system does what it is supposed to do”.
BUT it does not take care of “what happens if the inputs to the program are
given wrongly or would it do something undesirable?”
• Glen Meyers in 1979 defined “Testing is the process of executing a program
or system with the intent of finding errors.”
BUT through this concept of testing narrowed down to execution only.
• Thus, Hetzel modified in 1983 his earlier definition : “testing is an activity
aimed at evaluating an attribute or capability of a program of system and
determining that it meets its required results.”
• Similarly standard organizations like IEEE,ISO defined : “ Testing is the
process of analysis a software item to detect the differences between
existing and required conditions and to evaluate the features of the software
item. Software item is a source code, object code, job control code , control
data or a collection of these items.”
BUT this definition restricted testing to code only.
• Today, testing not only encompasses the code and
execution but also to all the process of software
development. It should start from first day of requirement
specification and should be carried out at every stage.

• Testing is verification and validation.


Criteria Verification Validation
Definition The process of evaluating work- The process of evaluating software
products (not the actual final product) during or at the end of the
of a development phase to determine development process to determine
whether they meet the specified whether it satisfies specified business
requirements for that phase. requirements.

Objective To ensure that the product is being To ensure that the product actually
built according to the requirements meets the user’s needs, and that the
and design specifications. In other specifications were correct in the first
words, to ensure that work products place. In other words, to demonstrate
meet their specified requirements. that the product fulfils its intended use
when placed in its intended
environment.
Question Are we building the product right? Are we building the right product?

Evaluation Plans, Requirement Specs, Design The actual product/software.


Items Specs, Code, Test Cases
Activities •Reviews •Testing
•Walkthroughs
•Inspections
WHY TESTING OF
SOFTWARES?
EXAMPLES
• London Olympics security is affected due to bugs in
software:
It was reported that the security staff of London Olympics 2012 was
underestimated. Sources of Security Company said it was only due to
software failure that caused security fiasco, the software G4S faced
problems in its internal computer system and hence failed to calculate the
strength of staff. It’s being reported that security details for the London
2012 Olympics are woefully understaffed, yes, because of a computer
glitch.
However, the issue was resolved that cost company £50m along with loss
of reputation.
• Automatic machine bug benefits customers
by overdrawing the cash:

Commonwealth bank of Australia faced a bug, when its officials were


operating the ATM on standby mode. Due to the bug, customers were
allowed to draw more amount than they entered in the machine. The
situation last for more than five hours, officials seem helpless as they were
unable to identify the account balance of the customers due to this bug.
Enterprise application failures cost the organizations heavily but prove to
be beneficial for the customers.
❑ Software testing answers questions that development testing and code
reviews can’t.
♦ Does it really work as expected? ♦ Does it meet the users’ requirements?
♦ Is it what the users expect? ♦ Do the users like it?
♦ Which areas need more work? ♦ Is it compatible with our other
systems?
♦ How does it perform? ♦ Is it ready for release?
♦ How does it scale when more users are added?

❑ What can we do with the answers to these questions?


♦ Save time and money by identifying defects early
♦ Avoid or reduce development downtime
♦ Provide better customer service by building a better application
♦ Know that we’ve satisfied our users’ requirements
♦ Build a list of desired modifications and enhancements for later versions
♦ Identify and catalog reusable modules and components
♦ Identify areas where programmers and developers need training
WHO DOES
TESTING?
➢ Software testing is not a one person job.
➢ It takes a team, but the team may be larger or smaller depending on the size
and complexity of the application being tested.
➢ The programmer(s) who wrote the application should have a reduced role in
the testing if possible.
Key Players and Their Roles

➢ Business sponsor(s) and partners


♦ Provides funding
♦ Specifies requirements and deliverables
♦ Approves changes and some test results
➢ Project manager Plans and manages the project
➢ Software developer(s)
♦ Designs, codes, and builds the application
♦ Participates in code reviews and testing
♦ Fixes bugs, defects, and shortcomings
➢ Testing Coordinator(s) Creates test plans and test specifications based on the
requirements and functional, and technical documents
➢ Tester(s) Executes the tests and documents results.
TEST PLAN
➢ The test plan is a mandatory document.
➢ A formal detailed document that describes
♦ Scope, objectives, and the approach to testing,
♦ People and equipment dedicated/allocated to testing
♦ Tools that will be used
♦ Dependencies and risks
♦ Categories of defects
♦ Test entry and exit criteria
♦ Measurements to be captured
♦ Reporting and communication processes
♦ Schedules and milestones
TEST CASE
➢ A test case is a set of test inputs, execution conditions, and expected
results developed for a particular objective, such as to exercise a particular
program path or to verify compliance with a specific requirement.
OR
Documentation specifying inputs, predicted results, and a set of execution
conditions for a test item.”

➢ Why Test Case?


The process of developing test cases can also help find problems in the
requirements or design of an application.
Types of testing
➢Functional Testing
➢Non- Functional Testing
➢Regression Testing
➢Usability Testing
➢Compatibility Testing
➢Performance Testing
➢Mutation Testing
➢Alpha Testing
➢Beta Testing
Following are the various test methods:

➢Static testing
➢Dynamic testing
➢Visual testing
➢The box approach
1. Black box testing
2. White box testing
STATIC TESTING
➢ Under Static Testing code is not executed. Rather it manually
checks the code, requirement documents, and design documents
to find errors. Hence, the name “static”.

➢ Main objective of this testing is to improve the quality of software


products by finding errors in early stages of the development
cycle. This testing is also called as Non-execution technique or
verification testing.

➢ Static testing involves manual or automated reviews of the


documents. This review, is done during initial phase of testing to
catch defect early in STLC. It examines work documents and
provides review comments
DYNAMIC TESTING
➢ Under Dynamic Testing code is executed. It checks for functional
behaviour of software system , memory/CPU usage and overall
performance of the system. Hence the name “Dynamic”

➢ Main objective of this testing is to confirm that the software


product works in conformance with the business requirements.
This testing is also called as Execution technique or validation
testing.

➢ Dynamic testing executes the software and validates the output


with the expected outcome. Dynamic testing is performed at all
levels of testing and it can be either black or white box testing.
Difference between Static and Dynamic Testing
Static Testing Dynamic Testing
Testing done without executing the program Testing done by executing the program

Dynamic testing does validation process


This testing does verification process

Static testing is about prevention of defects Dynamic testing is about finding and fixing the defects

Dynamic testing gives bugs/bottlenecks in the software


Static testing gives assessment of code and documentation
system.

Static testing involves checklist and process to be followed Dynamic testing involves test cases for execution

This testing can be performed before compilation Dynamic testing is performed after compilation

Static testing covers the structural and statement coverage


Dynamic testing covers the executable file of the code
testing

Cost of finding defects and fixing is less Cost of finding and fixing defects is high

Return on investment will be high as this process involved Return on investment will be low as this process involves
at early stage after the development phase

More reviews comments are highly recommended for


More defects are highly recommended for good quality.
good quality
VISUAL TESTING
➢ Aim : To provide developers with the ability to examine what was happening
at the point of software failure by presenting the data in such a way that the
developer can easily find the information required and the information is
expressed clearly.

➢ At the core of visual testing is the idea that showing someone a problem (or
a test failure), rather than just describing it, greatly increases clarity and
understanding.
Example- video recording of whole testing process

➢ Advantage : Visual testing is gathering recognition in customer


acceptance and usability testing, because the test can be used by many
individuals involved in the development process. For the customer, it
becomes easy to provide detailed bug reports and feedback, and for
program users, visual testing can record user actions on screen, as well as
their voice and image, to provide a complete picture at the time of software
failure for the developer.
THE BOX APPROACH

➢Black box testing


➢White box testing
Black box testing
➢ User/tester is unaware of the code of the
program.

➢ Software is tested for its functionality as per the


specification.

➢ Also known as data driven testing, input/output


based testing and specific based testing.

➢ For example : an operating system like Windows,


a website like Google ,a database like Oracle or
even your own custom application
Example:
➢MS Calc : if we perform the following
operations
sqrt(4) =2
sq(sqrt(4)) =4
Functionally this is right and even the display
will show you four(4).
Now just subtract 4 from the result and you get
a precision error.
Definitions

➢ Black box testing implies that a tester doesn’t know


how the application is designed at the code level i.e. it
involves dynamic testing of compiled applications.
Tester interacts with the software system via its
interface and analyzes the application reaction.

➢ Black box testing is a software testing techniques in


which functionality of the software under test (SUT) is
tested without looking at the internal code structure,
implementation details and knowledge of
internal paths of the software.
Black box testing - Steps

Here are the generic steps followed to carry out any type of
Black Box Testing:

➢ Initially requirements and specifications of the system are


examined.
➢ Tester chooses valid inputs (positive test scenario) to check
whether SUT processes them correctly . Also some invalid
inputs (negative test scenario) are chosen to verify that the
SUT is able to detect them or not.
➢ Tester determines expected outputs for all those inputs.
➢ Software tester constructs test cases with the selected
inputs.
➢ The test cases are executed.
➢ Software tester compares the actual outputs with the
expected outputs.
➢ Defects if any are fixed and re-tested.
TYPES
There are many types of Black Box Testing but following are the prominent
ones –

➢ Functional testing – It verifies that each function of the software


application operates in conformance with the requirement specification.
This testing involves checking of User Interface, APIs, Database, security,
client/ server applications and functionality of the Application Under Test.
This testing usually describes what the product does.

➢ Non-functional testing – It verifies all the non-functional requirements of a


software system such as performance, scalability, usability and reliability
and is designed to evaluate the readiness of the system. It should be
performed after functional testing. This testing usually describes how good
the product works.

Example: Functional testing reveals that the function of inputting data into
a set of cells in a database works or not, however, Non Functional Testing
reveals that saving a version of the document requires 2 minutes, which
will (or should) be judged as too long to wait.
➢ Regression testing –Testing to ensure that the
application remains intact during defect fixes and new
enhancements.
➢ Usability testing- this is a Black box testing that test for
user friendliness. Ensure the user interface is properly
designed for a positive end-user experience.
➢ Compatibility testing- Testing to ensure application
compatibility with different OS, other application
softwares , browsers or target environments that
greatly differs from the original.
Advantages

1. Ease of use- Because testers do not have to concern themselves


with the inner workings of an application, it is easier to
create test cases by simply working through the
application, as would an end user.

2. Quicker test case development- Because testers only concern


themselves with the GUI, they do not need to spend time
identifying all of the internal paths that may be involved in a
specific process, they need only concern themselves with the
various paths through the GUI that a user may take.

3. Simplicity- Where large, highly complex applications or systems


exist black-box testing offers a means of simplifying the testing
process by focusing on valid and invalid inputs and ensuring the
correct outputs are received.
Disadvantages
1.Sript maintenance- While an image-based approach to testing is
useful, if the user interface is constantly changing the input
may also be changing. This makes script maintenance very
difficult because black-box tools are reliant on the method of
input being known.

2.Lack of introspection- Ironically, one of the greatest criticism of


black-box testing is that, it doesn’t know how to look inside an
application and therefore can never fully test an application or
system.
➢ Program is known to the tester/user.

➢ Tests the internal structure of the software.

➢ Also known as clear box testing, glass box


testing, transparent box testing, and structural
testing.

➢ Example - For login window, suppose you provide


username and password and click "Cancel", it turns to
the login window again but database still maintains the
record and saves it.
In this case, black box testing will verify that "Cancel"
button is working properly and login window turns up
again. But only white box testing would be able to
make sure whether the cancelled data has really been
discarded or not.
Definition
➢ White Box Testing is the testing of a software solution's
internal coding and infrastructure. It focuses primarily on
strengthening security, the flow of inputs and outputs
through the application, and improving design and
usability. It involves testing a series of predefined inputs
against expected or desired outputs so that when a
specific input does not result in the expected output, you
have encountered a bug.
What do you verify in White
Box Testing ?
White box testing involves the testing of the
software code for the following:

➢ Internal security holes


➢ Broken or poorly structured paths in the coding
processes
➢ The flow of specific inputs through the code
➢ Expected output
➢ The functionality of conditional loops
➢ Testing of each statement, object and function on
an individual basis
White box testing-Steps
➢ Understanding of the source code.
➢ Test cases to be created so that every visible path is exercised
for testing.
➢ These are the three basic steps that white-box testing takes in
order to create test cases:
1. Input- Involves different types of requirements, functional
specifications, detailed designing of documents, proper source
code, security specifications. This is the preparation stage of
white-box testing to layout all of the basic information.
2. Processing Unit- Involves performing risk analysis to guide whole
testing process, proper test plan, execute test cases and
communicate results. This is the phase of building test cases to
make sure they thoroughly test the application and the given
results are recorded accordingly.
3. Output- Prepare final report that encompasses all of the above
preparations and results.
Techniques

➢ Code Coverage analysis- Code Coverage analysis, eliminates gaps in a test


case suite. It identifies areas of a program that are not exercised by a set of
test cases. Once gaps are identified, you create test cases to verify untested
parts of code, thereby increase the quality of the software product.

➢ Statement Coverage This technique requires every possible statement in


the code to be tested at least once during the testing process.

➢ Branch Coverage – This technique checks every possible path (if-else and
other conditional loops) of a software application.

➢ Decision coverage – it identifies a set of test cases sufficient for


guaranteeing that each decision will have value “true” at least once and
value “false” at least once.

Using Statement and Branch coverage you generally attain 80-90% code
coverage which is sufficient.
Types

➢ Regression testing- White box testing during regression


testing is the use of recycled white box test cases at the unit
and integration testing levels.

➢ Penetration Testing- In this testing, the tester/developer has


full information of the application’s source code, detailed
network information, IP addresses involved and all server
information the application runs on. The aim is to attack the
code from several angles to expose security threats.

➢ Mutation Testing: Mutation testing is often used to discover


the best coding techniques to use for expanding a software
solution.
Advantages
➢ Introspection- Introspection, or the ability to look inside the
application, means that testers can identify objects
programmatically.

➢ Stability- By-product of introspection in white-box testing


can deliver greater stability and reusability of test cases if the
objects that comprise an application never change.

➢ Thoroughness- In situations where it is essential to know that


every path has been thoroughly tested, that every possible
internal interaction has been examined, white-box testing is
the only viable method. As such, white-box testing offers
testers the ability to be more thorough in terms of how much
of an application they can test.
Disadvantages

1. Complexity- Being able to see every constituent part of an application


means that a tester must have detailed programmatic knowledge of the
application in order to work with it properly. This high-degree of complexity
requires a much more highly skilled individual to develop test case.

2. Integration- For white-box testing to achieve the degree of introspection


required it must be tightly integrated with the application being tested. This
creates a few problems. To be tightly integrated with the code you must install
the white-box tool on the system on which the application is running.

3. Platform support- Due to the highly integrated nature of white-box testing


tools many do not provide support for more than one platform, usually
Windows®. Where companies have applications that run on other platforms,
they either need to use a different tool or resort to manual Testing.
White box vs. black box
Testing levels
➢Unit testing
➢Integration testing
➢System testing
➢Acceptance testing
Unit Testing

➢ Unit testing, also known as component testing, refers to tests


that verify the functionality of a specific section of code,
usually at the function level.

➢ Unit testing alone cannot verify the functionality of a piece of


software, but rather is used to assure that the building blocks
the software uses work independently of each other.

➢ The goal of unit testing is to isolate each part of the program


and show that the individual parts are correct. This strategy is
intended to increase the quality of the resulting software.

➢ Unit testing is usually performed by the developer during the


construction phase of the software development lifecycle.
Integration Testing
➢ Integration testing is any type of software testing that seeks to verify the
interfaces between components against a software design. Integration
testing works to expose defects in the interfaces and interaction between
integrated components (modules).

➢ In Integration Testing, individual software modules are integrated logically


and tested as a group.

➢ At the time of module development, there wide chances of change in


requirements by the clients. These new requirements may not be unit
tested and hence integration testing becomes necessary

➢ Integration testing focuses on checking data communication amongst these


modules. Hence it is also termed as ‘I & T’ (Integration and Testing), ‘String
Testing’ and sometimes ‘Thread Testing’.

➢ Example- Scenario could be like if the ATM has different modules


ValidatePIN and GetPIN then how some value passed in GetPIN affects
ValidatePIN etc.
System Testing
➢ System testing is a series of different tests whose sole purpose is
to exercise the full computer based system.

➢ In addition, the system testing should ensure that the program, as


well as working as expected, does not also destroy or partially
corrupt its operating environment or cause other processes within
that environment to become inoperative.

➢ System testing falls under the black box testing category of


software testing.

➢ Example- In case of an ATM system testing would be inserting a


valid debit card followed by correct pin code and knowing the
balance in the account. Another scenario would be inserting a
valid debit card followed by correct pin code and withdrawing
more amount than the allowed limit.
How to do System Testing?
In Software System Testing following steps needs to be
executed:

Step 1) First & important step is preparation of System


Test Plan.
Step 2) Second step is to creation Test Cases.
Step 3) Creation of test data which used for System testing.
Step 4) Automated test case execution.
Step 5) Execution of normal test case & update test case if
using any test management tool (if any).
Step 6) Bug Reporting, Bug verification & Regression testing.
Step 7) Repeat testing life cycle (if required).
User Acceptance Testing
➢ User acceptance is a type of testing performed by the Client to certify the
system with respect to the requirements that was agreed upon.

➢ This testing happens in the final phase of testing before moving the
software application to Market or Production environment.

➢ The main purpose of this testing is to validate the end to end business flow.
It does NOT focus on the cosmetic errors, Spelling mistakes or System
testing.

➢ This testing is carried out in separate testing environment with production


like data setup. It is a kind of black box testing where two or more end users
will be involved.

➢ With UAT , the client can be sure “What to expect” from the product rather
than assuming. The benefit of UAT is that there will be no surprises when
the product is released to the market.
Main types of acceptance testing

➢ Alpha testing takes place at developers' sites, and


involves testing of the operational system by
internal staff, before it is released to external
customers.

➢ Beta testing takes place at customers' sites, and


involves testing by a group of customers who use
the system at their own locations and provide
feedback, before the system is released to other
customers. It is often called “field testing”.

You might also like