SOFTWARE TESTING

BCA – VI SEM
 SOFTWARE TESTING
BCA – VI SEM
UNIT-1
Example Test Series - First Cycle, Second Cycle, Subsequent
Cycles, Objectives and Limits ofTesting.
Testing in Software Development Process - Planning Stage, Design
Stage, Glass Box Code Testing, Regression
Testing, Black Box' Testing Software Errors.
Reporting and Analyzing Bugs - Problem Report: Contents,
Characteristics; Analysis of Reproducible Bug,
Tactics for Analyzing and Making a Bug Reproducible.
 Why we need software to be tested?
The irrecoverable damages that software failure can cause are evident from the startling reports across the world.
In 2017 a report released by Tricentis reveals that global enterprises have testified a loss of 1.7 trillion in assets
and affects 3.7 million people across the globe.  In 2018 across the US, poor software quality incurs a scaring loss
of $2.84 trillion collectively. 
The testing is important since it discovers defects/bugs
before the delivery to the client, which guarantees the
quality of the software. It makes the software more
reliable and easy to use.

Thoroughly tested software ensures reliable and high-

performance software operation
Few software testing companies
 Importance of Software Testing   
The importance of software testing can be traced from the user’s
response. It assures the quality of the product and satisfies the
customers as well as users.

Also, it promises better business optimization (less maintenance cost),

reliability, and superior user experience. Substantially, the iterative
efforts spending to mold a powerful yet error-free software are far and
wide.
https://www.youtube.com/watch?v=TDynSmrzpXw&ab_channel=Guru
99
 
Career Growth in Software Testing - Future Scope
of Testing | Testing Tools Tutorial by Mr. Suresh
https://www.youtube.com/watch?v=46niAd4bdGs&ab_channel=NareshiTechnologies

Why Software Testing is an exciting career option - TESTimony finalists speak

https://www.youtube.com/watch?v=qNgSqk9MPls&ab_channel=TCSGlobal
Text book link----

https://books.google.co.in/books?id=Q-hTDwAAQBAJ&printsec=frontcover&dq=testing+c
omputer+software+by+cem+kaner+%221998%22++text+book+pdf+free+download&hl=en
&newbks=1&newbks_redir=1&sa=X&ved=2ahUKEwjJp7qxsbLvAhXeqksFHf7lD1QQ6w
EwAXoECAIQAQ
 What is Software Testing?
It is the process of critical analysis to identify and evaluate whether the
developed application meets the Business Requirement Specifications. It is
a continuous process, namely Software Testing Lifecycle (STLC) works
along with the software development life cycle. Over each phase, it verifies
the functionalities and validates the app performance with the requirement. 

Besides, to deliver bug-free software, software testing helps to improvise

the functionalities and usability of applications. There are different types,
methods, and techniques to test software, and it involves multiple levels to
verify and validate it. 
 Software Errors and Bugs
 “An error is a deviation from accuracy or correctness” and  “A software
bug is an error, flaw, failure, or fault in a computer program or system that
causes it to produce an incorrect or unexpected result, or to behave in
unintended ways “.

•Error is a variance of the actual result from the expected result.

•Errors are a category of software bugs.
•Errors can be introduced as result of incomplete or inaccurate requirements or
due to human data entry problems.
 Common Categories of Software Errors
Functionality Errors:
Functionality is a way the software is intended to behave. Software has a functionality
error if something that you expect it to do is hard, awkward, confusing, or impossible.

Expected Functionality for Cancel button is

that the ‘Create new project’ window should
close and none of the changes should be
saved (i.e. no new project must be created).

If the Cancel button is not clickable then it

is a functionality error.
 Communication Errors
These errors occur in communication from software to end-user. Anything that the end user needs to know in
order to use the software should be made available on screen.
Few examples of communication errors are – No Help instructions/menu provided, features that are part of the
release but are not documented in the help menu, a button named ‘Save’ should not erase a file etc.
 Missing command errors

This happens to occur when an

expected command is missing.
 Syntactic Error
Syntactic errors are misspelled words or grammatically incorrect
sentences and are very evident while testing software GUI. Please note that
we are NOT referring to syntax errors in code. The compiler will warn the
developer about any syntax errors that occur in the code

Note the misspelled word ‘Cancel’ Note the grammatically incorrect message
 Error handling errors
Any errors that occur while the user is interacting with the software needs to be handled in a clear
and meaningful manner. If not, it is called as an Error Handling Error.

Take a look at this image. The error message gives no indication of what the error actually is. Is it missing
mandatory field, saving error, page loading error or is it a system error? Hence, this is an ‘Error Handing Error’.
When possible, further steps should be listed for the user to follow.
If the software has certain mandatory fields that need to be filled before they can
save the information on a form, the validation messages should be clear and
indicative of the action that is required by the user.
 Calculation Errors
These errors occur due to any of the following reasons:
•Bad logic
•Incorrect formulae
•Data type mismatch
•Coding errors
•Function call issues , etc.
In 1999, NASA lost its Mars climate orbiter because one of the subcontractors
NASA employed had used English units instead of the intended metric system,
which caused the orbiter’s thrusters to work incorrectly. Due to this bug, the
orbiter crashed almost immediately when it arrived at Mars.
 Control flow errors
The control flow of a software describes what it will do next and on what
condition.
For example, consider a system where user has to fill in a form and the
options available to user are: Save, Save and Close, and Cancel. If a user
clicks on ‘Save and Close’ button, the user information in the form should be
saved and the form should close. If clicking on the button does not close the
form, then it is a control flow error.
This is a Missing command error. Cancel button is required but is missing.
Also, both buttons ‘Proceed’ and ‘Delete’ are redundant and perform the same
function.
Output of addition of two numbers

?2
?3

5
?-
Output of addition of two numbers

enter the value of a: 2

enter the value of b: 3
the sum of a and b is: 5
 First cycle of testing
Step-1:
Problem reports arising from the first test
1. Design error: nothing shows you on what error this is how do you know
you are in the right program?
2. Design error: There are no instructions on screen how do you know what
to do? What if you enter a wrong number
3. Design error: how do you stop the program? These instructions should
appear on screen to
4. Coding error: The sum isn't lined up with the other displayed numbers
 Step-2: make some notes about what else needs in testing
Test case Expected results Notes

99 +99 198 largest pair of numbers the program can add

-99+- 99 -198 the spec didn't say you could'nt use negative numbers
99 +-14 85 the large first number might affect the program's interpretation of the
next number
-38+99 61 check addition of a negative to positive number
56+99 155 large second number effect on first
9+9 18 9 is the largest one digit number
0+0 0 program often fail on 0
0+23 23 the program may treat 0 as a special case it should be tested in the first
and second entry position
-78+0 -78
 Step-3: check the valid cases and see what happens
Test Results:
1. Positive numbers worked fine so did zero
2. None of the negative numbers worked the computer locked( means the computer ignores the keyboard
input) when you entered the second digit
you tried -9+-9 to see if single digit negative numbers worked but computer got locked
when you pressed enter after -9 evidently the program does not expect negative
numbers

Step-4: Do some testing on the fly

No matter how many test cases of how many types you created you will run out of formally planned tests at
some point you will stop formally planning and documenting new tests until the next test cycle

Always prepare for more no of tests …..

Step-5:summarize what you know about the program and its
problems
 Second cycle of Testing
Step-1: Before doing any testing review the responses to the problem reports carefully to see what needs
to be done and what doesn’t

It take cares of test which no longer have to run and the ones you have to replace with others
 Step-2: Review comments on problems that wont be fixed
In the present scenario the program crashes when you press certain keys (alphabetic keys, control keys, function keys)…

What if program crashes if you press keys which are not expected

Step-3: pull out your notes last time add your new notes to them and
start testing
Just two to three attempts to fix a program does not work…..
Subsequent cycles
 Objectives and limits of Testing
Software Testing has different goals and objectives.The major objectives of Software testing are as
follows:

 Finding defects which may get created by the programmer while developing the software.
 Gaining confidence in and providing information about the level of quality.
 To prevent defects.
 To make sure that the end result meets the business and user requirements.
 To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is
System Requirement Specifications.
 To gain the confidence of the customers by providing them a quality product.
Limitations of Testing

https://www.professionalqa.com/software-testing-limitations
Software Development process
 SOFTWARE DEVELOPMENT STAGES

Coding &
Planning Design
Documentation

Post release
Testing & Fixing Maintenance and
Enhancement
PLANNING
 Testing during the planning stages

1. Are these the right requirements ?

2. Is this the product that should be built?
3. Are they complete?
4. Are they compatible?
requirements can be logically In compatible
5. Are they Achievable?
Do they assume that hardware works more quickly than it does?
6. Are they reasonable?
development speed, development cost,product performance,reliability, and memory usage
7. Are they testable?
Design stages
 Testing during design stages

Review meeting:

1. Inspection : inspectors check every line of design in check list. Focuses on error handling, conformity with
standards.

2. Technical Review: Reviewers describe their objections and point out things that are
ambiguous and confusing. The purpose of review is to list out problems and make
sure the designer understands each one.
Glass Box code 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.
https://youtu.be/3bJcvBLJViQ
 BLACK BOX TESTING
Black Box Testing is a software testing method in which the functionalities of software applications are tested
without having knowledge of internal code structure, implementation details and internal paths.

Black Box Testing mainly focuses on input and output of software applications and it is entirely based on
software requirements and specifications. It is also known as Behavioral Testing.
Black Box Testing Techniques
Following are the prominent Test Strategy amongst the many used in Black box Testing

Equivalence Class Testing: It is used to minimize the number of possible test cases to an optimum level while maintains
reasonable test coverage.

Boundary Value Testing: Boundary value testing is focused on the values at boundaries. This technique determines whether a
certain range of values are acceptable by the system or not. It is very useful in reducing the number of test cases. It is most
suitable for the systems where an input is within certain ranges.

Decision Table Testing: A decision table puts causes and their effects in a matrix. There is a unique combination in each colum

https://youtu.be/Wi75S5TTfQ0
 Differences between white box and black box testing
Black Box Testing White Box Testing
the main focus of black box testing is on the validation of your White Box Testing (Unit Testing) validates internal structure and
functional requirements. working of your software code

Black box testing gives abstraction from code and focuses on To conduct White Box Testing, knowledge of underlying programming
testing effort on the software system behavior. language is essential. Current day software systems use a variety of
programming languages and technologies and its not possible to know
all of them.

Black box testing facilitates testing communication amongst White box testing does not facilitate testing communication amongst
modules modules

https://www.youtube.com/watch?v=jRwwb7iaRsU
 Regression Testing
REGRESSION TESTING  - is defined as a type of software testing to confirm that a recent program or code change has
not adversely affected existing features.

Regression Testing is nothing but a full or partial selection of already executed test cases which are re-executed to
ensure existing functionalities work fine.

This testing is done to make sure that new code changes should not have side effects on the existing functionalities. It
ensures that the old code still works once the latest code changes are done.

Need of Regression Testing:

The Need of Regression Testing mainly arises whenever there is requirement to change the code and we need to test
whether the modified code affects the other part of software application or not. Moreover, regression testing is needed,
when a new feature is added to the software application and for defect fixing as well as performance issue fixing.
Retest All
This is one of the methods for Regression Testing in which all the tests in the existing test bucket
or suite should be re-executed. This is very expensive as it requires huge time and resources.
Regression Test Selection
Regression Test Selection is a technique in which some selected test cases from test suite are
executed to test whether the modified code affects the software application or not. Test cases are
categorized into two parts, reusable test cases which can be used in further regression cycles and
obsolete test cases which can not be used in succeeding cycles.

Prioritization of Test Cases

Prioritize the test cases depending on business impact, critical & frequently used functionalities.
Selection of test cases based on priority will greatly reduce the regression test suite.
 Challenges in Regression Testing

Following are the major testing problems for doing regression testing:

 With successive regression runs, test suites become fairly large. Due to time and budget constraints, the entire regression test
suite cannot be executed
 Minimizing the test suite while achieving maximum Test coverage remains a challenge
Determination of frequency of Regression Tests, i.e., after every modification or every build update or
after a bunch of bug fixes, is a challenge.

https://www.youtube.com/watch?v=1o_msdu6sIo
 Types of errors with examples

User Interface Errors: Missing/Wrong Functions, Doesn’t do what the user expects, Missing information, Misleading,
Confusing information, Wrong content in Help text, Inappropriate error messages. Performance issues – Poor
responsiveness, Can’t redirect output, inappropriate use of key board.

Error Handling: Inadequate – protection against corrupted data, tests of user input, version control; Ignores – overflow,
data comparison, Error recovery – aborting errors, recovery from hardware problems.

Boundary related errors: Boundaries in loop, space, time, memory, mishandling of cases outside boundary.

Calculation errors: Bad Logic, Bad Arithmetic, Outdated constants, Calculation errors, Incorrect conversion from one data
representation to another, Wrong formula, Incorrect approximation.

Initial and Later states: Failure to – set data item to zero, to initialize a loop-control variable, or re-initialize a pointer, to
clear a string or flag, Incorrect initialization.

Control flow errors: Wrong returning state assumed, Exception handling based exits, Stack underflow/overflow, Failure to
block or un-block interrupts, Comparison sometimes yields wrong result, Missing/wrong default, Data Type errors.

Errors in Handling or Interpreting Data: Un-terminated null strings, Overwriting a file after an error exit or user abort.

Race Conditions: Assumption that one event or task finished before another begins, Resource races, Tasks starts before its
  prerequisites are met, Messages cross or don’t arrive in the order sent.
Load Conditions: Required resources are not available, No available large memory area, Low priority tasks not put off,
Doesn’t erase old files from mass storage, Doesn’t return unused memory.

Hardware: Wrong Device, Device unavailable, Underutilizing device intelligence, Misunderstood status or return code,
Wrong operation or instruction codes.

Source, Version and ID Control: No Title or version ID, Failure to update multiple copies of data or program files.

Testing Errors: Failure to notice/report a problem, Failure to use the most promising test case, Corrupted data files,
Misinterpreted specifications or documentation, Failure to make it clear how to reproduce the problem, Failure to check for
unresolved problems just before release, Failure to verify fixes, Failure to provide summary report.
Reporting and analyzing bugs
Video on Bug report
https://www.youtube.com/watch?v=GWG
N0znexW8