Software Testing

Unit 1 :Basic Of Software Testing

Definition Of Software Testing
• Testing is the execution of programs with the intent of finding
defects.
• Testing is a the process of exercising a software component
 using a selected set of test cases,
 with the intent of revealing defects and evaluating quality.
• Software testing is a technical investigation of a product, i.e.
an empirical search for quality-related information of value to a
project’s stakeholders
Bug, Fault & Failure
• A person makes an Error
• That creates a fault in software
• That can cause a failure in operation
• Error : An error is a human action that produces the incorrect result that
results in a fault.
• Bug : The presence of error at the time of execution of the software.
• Fault : State of software caused by an error.
• Failure : Deviation of the software from its expected result. It is an event.
• Defect :A defect is an error or a bug, in the application which is created. A
programmer while designing and building the software can make mistakes or
error. These mistakes or errors mean that there are flaws in the software.
These are called defects.
Objective of testing
• To find defects before they cause a production system to fail.
• To bring the tested software, after correction of the identified defects
and retesting, to an acceptable level of quality.
• To perform the required tests efficiently and effectively, within the
limits budgetary and scheduling limitation.
• To compile a record of software errors for use in error prevention (by
corrective and preventive actions)
Test Plan
A test plan is a systematic approach to testing a system i.e. software.
The plan typically contains a detailed understanding of what the
eventual testing workflow will be.

Test Case
A test case is a specific procedure of testing a particular requirement.
It will include:
• Identification of specific requirement tested
• Test case success/failure criteria
• Specific steps to execute test
• Test Data
ENTRY CRITERIA

Entry Criteria for QA testing is defined as “Specific conditions or on-going activities that must be present
before a process can begin”. In the Systems Development Life Cycle it also specifies which entry criteria are
required at each phase. Additionally, it is also important to define the time interval or required amount of lead
time that an entry criteria item is available to the process. Input can be divided into two categories. The first is
what we receive from development. The second is what we produce that acts as input to later test process
steps.
The type of required input from development includes:
1.Technical Requirements/Statement of Need
2.Design Document
3.Change Control
4.Turnover Document
The type of required input from test includes:
5.Evaluation of available software test tools
6.Test Strategy
7.Test Plan
8.Test Incident Reports
By referencing the Entry Exit Criteria matrix, we get the clarity of the deliverables expected from each phase.
The matrix should contain “date required” and should be modified to meet the specific goals and
requirements of each test effort based on size and complexity.
EXIT CRITERIA

Exit Criteria is often viewed as a single document concluding the end of a life cycle phase. Exit Criteria
is defined as “The specific conditions or on-going activities that must be present before a life cycle
phase can be considered complete. The life cycle specifies which exit criteria are required at each
phase”. This definition identifies the intermediate deliverables, and allows us to track them as
independent events.

The type of output from test includes:

1.Test Strategy
2.Test Plan
3.Test Scripts/Test Case Specifications
4.Test Logs
5.Test Incident Report Log
6.Test Summary Report/Findings Report
By identifying the specific Exit criteria, we are able to identify and plan how these steps and processes
fit into the life cycle. All of the Exit Criteria listed above, less the Test Summary/Findings Report; act
as Entry Criteria to alter process.
Skills Required for Tester
• Communication skills
• Domain knowledge
• Desire to learn
• Technical skills
• Analytical skills
• Planning
• Integrity
• Curiosity
• Think from users perspective
• Be a good judge of your product
Software Quality Concept
Quality : Quality means consistently meeting customer needs in
terms of requirement, Cost and delivery schedule.
Quality of s/w is reasonably bug free, delivered on time and
within budget, meets requirements and exceptions and is
maintainable
Software Quality Concept
● Quality Control: “All defined work products and Measurable
Specifications” are compared with the output of each
process.
● Quality control focuses on operational technique and activities
used to fulfill and verify requirement of quality.
● - S/w quality involves – Series of inspection, reviews, and test
used through out the s/w process.
Quality Assurance (QA): consist of Auditing and reporting
procedure. Which are used to provide necessary data to
management. In order to make decision.

● Goal of Quality Assurance is to provide adequate confidence

that a product or services is of the and quality expected by
the customer.
● If the data provided through quality assurance identify
problems, then it is management’s responsibility to address
the problems & apply the necessary resources to resole
quality issues.
● S/w Quality Assurance is planned and systematic way to evaluate
quality of s/w product standards processes and procedures.
● SQA includes the process of insuring that standers and
procedures are established and are followed throughout the
software acquisition Life cycle.
● “ SQA consists of a means of monitoring the s/w engineering
process and methods used to insure quality ”
Verification & Validation

• Verification
• Are you building the product right?
• Software must conform to its specification

• Validation
• Are you building the right product?
• Software should do what the user really requires
What is Verification?
• Definition : The process of evaluating software to determine whether the
products of a given development phase satisfy the conditions imposed at the
start of that phase.
• Verification is a static practice of verifying documents, design, code and program.
It includes all the activities associated with producing high quality software:
inspection, design analysis and specification analysis. It is a relatively
objective process.
• Verification will help to determine whether the software is of high quality, but it
will not ensure that the system is useful. Verification is concerned with whether
the system is well-engineered and error-free.
• Methods of Verification : Static Testing
• Walkthrough
• Inspection
• Review
What is Validation?

• Definition: The process of evaluating software during or at the end of

the development process to determine whether it satisfies specified
requirements.
• Validation is the process of evaluating the final product to check
whether the software meets the customer expectations and
requirements. It is a dynamic mechanism of validating and testing the
actual product.
• Methods of Validation : Dynamic Testing
• Testing
• End Users
 Verification              Validation
1. Verification is a static practice of verifying documents, 1. Validation is a dynamic mechanism of validating and
design, code and program. testing the actual product.
2. It does not involve executing the code. 2. It always involves executing the code.
3. It is human based checking of documents and files. 3. It is computer based execution of program.

4. Verification uses methods like inspections, reviews, 4. Validation uses methods like black box (functional) 
testing, gray box testing, and white box (structural) testing
walkthroughs, and Desk-checking etc.
etc.
5. Verification is to check whether the software conforms 5. Validation is to check whether software meets the
to specifications. customer expectations and requirements.
6. It can catch errors that validation cannot catch. It is low 6. It can catch errors that verification cannot catch. It is High
level exercise. Level Exercise.
7. Target is requirements specification, application and
7. Target is actual product-a unit, a module, a bent of
software architecture, high level, complete design, and
database design etc. integrated modules, and effective final product.

8. Verification is done by QA team to ensure that the 8. Validation is carried out with the involvement of testing
software is as per the specifications in the SRS document. team.
9. It generally comes first-done before validation. 9. It generally follows after verification.
In the V-Model software development life cycle different steps are
followed however here we will taking a most common type of V-
model example. The V-model typically consist of the following
phases:

1. Unit Testing: Preparation of Unit Test Cases

2. Integration Testing: Preparation of Integration Test Cases

3. System Testing: Preparation of System test cases

4. Acceptance Testing: Preparation of Acceptance Test Cases

Methods of testing:

1. Static Testing :
 Static testing is the testing of the software work products manually,
or with a set of tools, but they are not executed.
 It starts early in the Life cycle and so it is done during the
verification process.
 It does not need computer as the testing of program is done without
executing the program. For example: reviewing, walk through,
inspection, etc.
 Static testing consists of following methods
1) Walkthrough 2) Inspection 3) Technical Review
Advantages of Static Testing
 Since static testing can start early in the life cycle, early feedback
on quality issues can be established.
 By detecting defects at an early stage, rework costs are most often
relatively low.
 Since rework effort is substantially reduced, development
productivity figures are likely to increase.
 The evaluation by a team has the additional advantage that there is
an exchange of information between the participants.
 Static tests contribute to an increased awareness of quality issues.
Disadvantages of Static Testing
 Demand great amount of time when done manually
 Automated tools works with only few programming languages
 Automated tools may provide false positives and false negatives
 Automated tools only scan the code
 Automated tools cannot pinpoint weak points that may create troubles in run-time

2. Dynamic Testing

 Dynamic testing (or dynamic analysis) is a term used in software engineering to describe
the testing of the dynamic behavior of code.
 That is, dynamic analysis refers to the examination of the physical response from the
system to variables that are not constant and change with time.
 In dynamic testing the software must actually be compiled and run.
Advantages of Dynamic Testing
 Dynamic testing could identify the weak areas in the runtime environment.
 Dynamic testing supports application analysis even if the tester does not have an
actual code.
 Dynamic testing could identify some vulnerabilities that are difficult to find by static
testing.
 Dynamic testing also could verify the correctness of static testing results.
 Dynamic testing could be applied to any application.

Disadvantages of Dynamic Testing

 Automated tools may give the wrong security, such as check everything.
 Automated tools can generate false positives and false negatives.
 Finding trained dynamic test professionals is not easy.
 Dynamic testing is hard to track down the vulnerabilities in the code, and it takes
longer to fix the problem. Therefore, fixing bugs becomes expensive.
White box testing
1) Walkthrough
 In walkthrough, author guides the review team via the document to fulfill the common
understanding and collecting the feedback.
 Walkthrough is not a formal process.
 In walkthrough, a review team does not require to do detailed study before meeting while
authors are already in the scope of preparation.
 Walkthrough is useful for higher-level documents i.e requirement specification and
architectural documents.
Goals of Walkthrough
 Make the document available for the stakeholders both outside and inside the software
discipline for collecting the information about the topic under documentation.
 Describe and evaluate the content of the document.
 Study and discuss the validity of possible alternatives and proposed solutions.
Participants of Structured Walkthrough
 Author - The Author of the document under review.
 Presenter - The presenter usually develops the agenda for the walkthrough and presents the
output being reviewed.
 Moderator - The moderator facilitates the walkthrough session, ensures the walkthrough
agenda is followed, and encourages all the reviewers to participate.

 Reviewers - The reviewers evaluate the document under test to determine if it is technically
accurate.
 Scribe - The scribe is the recorder of the structured walkthrough outcomes who records the
issues identified and any other technical comments, suggestions, and unresolved questions.
Benefits of Structured Walkthrough
 Saves time and money as defects are found and rectified very early in the lifecycle.
 This provides value-added comments from reviewers with different technical backgrounds and
experience.
 It notifies the project management team about the progress of the development process.
 It creates awareness about different development or maintenance methodologies which can
provide a professional growth to participants.
2) Inspection
 The trained moderator guides the Inspection. It is most formal type of
review.
 The reviewers are prepared and check the documents before the meeting.
 In Inspection, a separate preparation is achieved when the product is
examined and defects are found. These defects are documented in issue log.
 In Inspection, moderator performs a formal follow-up by applying exit
criteria.
Goals of Inspection
 Assist the author to improve the quality of the document under inspection.
 Efficiently and rapidly remove the defects.
 Generating the documents with higher level of quality and it helps to
improve the product quality.
 It learns from the previous defects found and prohibits the occurrence of
similar defects.
 Generate common understanding by interchanging information.
3) Technical Review
 Technical review is a discussion meeting that focuses on technical content of the
document. It is a less formal review.
 It is guided by a trained moderator or a technical expert.

Goals of Technical Review

 The goal is to evaluate the value of technical concept in the project environment.
 Build the consistency in the use and representation of the technical concepts.
 In early stages it ensures that the technical concepts are used correctly.
 Notify the participants regarding the technical content of the document.
Code Functional Testing:
i. Code Functional Testing involves tracking a piece of data completely through the software.
ii. At the unit test level this would just be through an individual module or function.
iii. The same tracking could be done through several integrated modules or even through the
entire software product although it would be more time consuming to do so.
iv. During data flow, the check is made for the proper declaration of variables declared and
the loops used are declared and used properly.
For example
1. #include<stdio.h>
2. void main()
3. {
4. int i , fact= 1, n;
6. scan
7. for(i =1; i<=n; i++)
8. fact = fact * i;
9.printf(“\n Factorial of number is %d”,fact);
10. }
Code Coverage Testing:
i. The logical approach is to divide the code just as you did in black-box testing into its data and its states (or
program flow).
ii. By looking at the software from the same perspective, you can more easily map the white-box information
you gain to the black-box case you have already written
iii. Consider the data first. Data includes all the variables, constants, arrays, data structures, keyboard and
mouse input, files and screen input and output, and I/O to other devices such as modems, networks, and so on.
For example
1. #include<stdio.h>
2. void main()
3. {
4. int i , fact= 1, n;
5. printf(“Enter the number”);
6. scanf(“%d”,&n);
7. for(i =1; i<=n; i++)
8. fact = fact * i;
9.printf(“\n Factorial of number is %d”,fact);
10. }
The declaration of data is complete with the assignment statement and the variable declaration statements. All
the variable declared are properly utilized.
Program Statements and Line Coverage (Code Complexity Testing)

i. The most straightforward form of code coverage is called statement coverage or line
coverage.

ii. If you‘re monitoring statement coverage while you test your software, your goal is to make
sure that you execute every statement in the program at least once.

iii. With line coverage the tester tests the code line by line giving the relevant output.

For example
1. #include
2. void main()
3. {
4. int i , fact= 1, n;
5. printf(―enter the number ―);
6. scanf(―%d‖, &n);
7. for(i =1 ;i <=n; i++)
8. fact = fact * i;
9. printf(“\n Factorial of number is %d”,fact);
10. }
Black Box Testing
 Black Box Testing, also known as Behavioral Testing, is a software testing method in which the
internal structure/ design/ implementation of the item being tested is not known to the tester. These
tests can be functional or non-functional, though usually functional

Advantages of black box testing

 Tests are done from a user’s point of view and will help in exposing discrepancies in the
specifications.

 Tester need not know programming languages or how the software has been implemented.
Disadvantages of black box testing

 Only a small number of possible inputs can be tested and many program paths will be left
untested.
 Without clear specifications, which is the situation in many projects, test cases will be difficult to
design.
 Tests can be redundant if the software designer/ developer has already run a test case.
 Ever wondered why a soothsayer closes the eyes when foretelling events? So is almost the case in
Black Box Testing.

Techniques for black box testing

1.Requirement Based Testing

2.Boundary Value Analysis
3. Equivalence Partitioning

1) Requirement based testing

 Requirements-based testing is a testing approach in which test cases, conditions and data are derived from requirements. It
includes functional tests and also non-functional attributes such as performance, reliability or usability.
2) Boundary Value Analysis

Boundary value analysis is used to find the errors at boundaries of input

domain rather than finding those errors in the center of input.

3) Equivalence Partitioning

 This reduces the number of permutation & combination of input, output

values used for testing, thereby increasing the coverage and reducing the
effort involved in testing.

 The set of input values that generate one single expected output is
called a partition.