UNIT-I [12 Hours]

Introduction: Basic definitions, A testing life cycle, Test Cases, Fundamental approaches to
apply Test Cases, Levels of Testing,
Examples: The NextDate function, Triangle problem and The Commission Problem and The
SATM (Simple Automatic Teller Machine) problem.

Boundary Value Testing: Generalizing Boundary Value Analysis, Limitations of Boundary Value
Analysis,

Robustness Testing, Worst-Case Testing, Special Value Testing,

Test cases for the Triangle problem,

Test cases for the NextDate function,
Test cases for the Commission Problem,

Random Testing and

Guidelines for Boundary Value Testing.
 SOFTWARE TESTING
Testing is the process of executing a software system to determine whether it matches its
specification and executes in its intended environment.
It involves any activity aimed at evaluating an attribute or capability of a program or system
and determining that it meets its required results.
Software can fail in many ways. Testing involves the operation of a system or application
under controlled conditions and evaluating the results. The controlled conditions include both
normal and abnormal. Testing should intentionally attempt to make the things go wrong and
determine if any things happens when they should and should not. Testing helps in verifying
and validating whether the software is working as it is intended to be working.

Testing Objectives:
1. It is a process of executing a program with the intent of finding an error.
2. Testing is to cause failures in order to make faults visible so that it can be fixed before
delivery.
3. It is also used to assess the quality of the software.
Software Testing is a process used to identify the correctness, completeness and quality of
developed computer software.
Testing can never completely establishes the correctness of computer software. Thus Testing
is the process of demonstrating that defects are not present in the application that was
developed.
Testing is the activity or process which shows or demonstrates that a program or system
performs all intended functions correctly.
Testing helps in establishing the necessary confidence that a program or system does what it
is supposed to do based on the requirements that the user has specified.

Testing Activity:

Test Plan  Test design  Test Case  Test Procedure  Test Execution
 Verification and Validation: ( V & V )
It is a name given for checking and analysis processes that ensures that the software confirms
to its specifications and meets the need of the customer.
It is whole life-cycle process. It starts with requirement reviews and continues with design
review, code inspection to product testing.
There should be V & V activities at each stage of the software process. These activities check
that the results of various process activities are as specified.
Verification is “ARE WE BUILDING THE PRODUCT RIGHT?”
Validation is “ARE WE BUILDING THE RIGHT PRODUCT?”
Thus, Verification involves checking that the software conforms to its specification. Here
whether the system meets its functional and non-functional requirements should be checked.
Whereas Validation is a general process where it is checked that the software meets the
expectation of the customer.
During Software V & V defects in the program are discovered and the program must be
modified to correct these defects. This is known a “DEBUGGING PROCESS”. It is not the same
as testing.
V & V is a process that establishes the existence of defects in a Software System.
Debugging is process that locates and corrects these defects.
Definition:
“Software testing is a process used to identify the correctness, completeness & quality of
developed software”
OR
Primary role of testing is not demonstration of correct performance, but the exposure of
hidden defects. - GlenMyers

Important Terms used in Software Testing:

Error: Refers to the difference between the actual output and the correct output of the
software. It is a measure of the difference between the actual and the ideal value.
Errors can be Syntactical Error
Logical Error
Executional Error
Syntactical Error is the error that occurs due to wrong syntax usage in the program.
Logical Error is the improper usage of logic in the program.
Executional Error is the error that occurs during the execution of the program.
Fault: It is a condition that causes the software to fail to perform its required function. It is
an incorrect step, process which makes the program perform in an unanticipated manner.

Failure: It is the inability of a system to perform a required function according to its

specification. A software failure occurs if the behavior of the software is different from the
specified behavior. A failure occurs only when there is a fault in the system.

Faults represent problems that the developer sees, while failures are problems that the
user sees.

Actual result : The behavior produced/observed when a component or system is tested.

Alpha testing: Simulated or actual operational testing by potential users/customers or an
independent test team at the developers' site, but outside the development organization.
Alpha testing is often employed for commercial offthe-shelf software as a form of internal
acceptance testing.
Beta testing : field testing or Operational testing by potential and/or existing
users/customers at an external site not otherwise involved with the developers, to determine
whether or not a component or system satisfies the user/customer needs and fits within the
business processes. Beta testing is often employed as a form of external acceptance testing
for commercial off-the-shelf software in order to acquire feedback from the market.
black-box testing : specification-based testing Testing, either functional or non-functional,
without reference to the internal structure of the component or system.
defect : problem A flaw in a component or system that can cause the component or system
to fail to perform its required function, e.g., an incorrect statement or data definition. A
defect, if encountered during execution, may cause a failure of the component or system.
driver : A software component or test tool that replaces a component that takes care of the
control and/or the calling of a component or system.
expected result : or expected outcome , predicted outcome The behavior predicted by the
specification, or another source, of the component or system under specified conditions.
test case result : The final verdict on the execution of a test and its outcomes, such as pass,
fail, or error. The result of error is used for situations where it is not clear whether the problem
is in the test object.
test environment: An environment containing hardware, instrumentation, simulators,
software tools, and other support elements needed to conduct a test.
test plan : A document describing the scope, approach, resources and schedule of intended
test activities. It identifies amongst others test items, the features to be tested, the testing
tasks, who will do each task, degree of tester independence, the test environment, the test
design techniques and entry and exit criteria to be used, and the rationale for their choice,
and any risks requiring contingency planning. It is a record of the test planning process.

white-box testing : or clear-box testing , code-based testing , glass-box testing , logic-

coverage testing , logic-driven testing , structural testing , structure-based testing
Testing based on an analysis of the internal structure of the component or system.

TEST CASE:
Test Plan focusses on how the testing for the project will proceed. It focusses on which unit
is to be tested, what approach or tools are to be used during testing. It does not specify the
details of testing. It is carried out through “ TEST CASE SPECIFICATIONS ”.

“ The Test Case Specification gives for each unit to be tested all the test cases, inputs to be
used in test cases, conditions being tested by the test case, outputs expected for those test
cases and other testing activities. ”
Thus, test case is a scenario made up of sequence of steps and conditions or variables,
where test inputs are provided and the program is running to those inputs, to see how it
performs.
An expected result is outlined and the actual result is compared to it. Certain working
conditions are also present in the test case, to see how the program handles the conditions.
Definition: A test case is a document that describes an input, action or event and an
expected response to determine if a feature of an application is working correctly.

Structure of Test Case: A test case contains three parts:

Information – contains general information about the test case such as test case identifier
(id), test case creator information, version, name of the test case, purpose or brief description
of the test case. It also contains specific hardware, software requirements and any other
configuration requirements.

Activities : This part consists of actual test case activities such as environment that should
exist during testing, activities to be done at the initialization of the test, step-by-step actions
to be done while testing and the input data that is to be supplied for testing.
Result : Results are the outcomes of a performed test case. Result data consists of
information about expected results which is necessary for the program to pass the test and
the actual recorded results.
Test Case Format:

Test Case No. Test Method:

Project Name: Version:

Test Case Description:

Input No. Functional Inputs Condition Type Condition State

1
2
3
4

Expected Output:

Actual Output:

Status:

Created by: Created Date:

Typical Test Case Parameters
Software Testing Life Cycle (STLC): The Software Testing Life Cycle (STLC) is a systematic
approach to testing a software application to ensure that it meets the requirements and is free
of defects.
It is a process that follows a series of steps or phases, and each phase has specific objectives
and deliverables.
The STLC is used to ensure that the software is of high quality, reliable, and meets the needs
of the end-users.

The main goal of the STLC is to identify and document any defects or issues in the software
application as early as possible in the development process. This allows for issues to be
addressed and resolved before the software is released to the public.

The stages of the STLC include

1. Requirement Analysis 2. Test Planning 3. Test Case Development
4. Test Environment Setup 5. Test Execution 6. Test Closure

Each of these stages includes specific activities and deliverables that help to ensure that the
software is thoroughly tested and meets the requirements of the end users.

STLC is an important process that helps to ensure the quality of software applications and
provides a systematic approach to testing. It allows organizations to release high-quality
software that meets the needs of their customers, ultimately leading to customer
satisfaction and business success.

Characteristics of STLC
 STLC is a fundamental part of the Software Development Life Cycle (SDLC) but STLC
consists of only the testing phases.
 STLC starts as soon as requirements are defined or software requirement document is
shared by stakeholders.
 STLC yields a step-by-step process to ensure quality software.

Phases of STLC
1. Requirement Analysis: Requirement Analysis is the first step of the Software Testing Life
Cycle (STLC).
In this phase quality assurance team understands the requirements like what is to be
tested. If anything is missing or not understandable then the quality assurance team meets
with the stakeholders to better understand the detailed knowledge of requirements.

The activities that take place during the Requirement Analysis stage include:
 Reviewing the software requirements document (SRD) and other related documents
 Interviewing stakeholders to gather additional information
 Identifying any ambiguities or inconsistencies in the requirements
 Identifying any missing or incomplete requirements
 Identifying any potential risks or issues that may impact the testing process

At the end of this stage requirement traceability matrix (RTM) is created to map
requirements to test cases. The testing team should have a clear understanding of the
software requirements and should have identified any potential issues that may impact the
testing process. This will help to ensure that the testing process is focused on the most
important areas of the software and that the testing team is able to deliver high-quality
results.

2. Test Planning: Test Planning is the most efficient phase of the software testing life cycle
where all testing plans are defined.
In this phase manager of the testing, team calculates the estimated effort and cost for the
testing work. This phase gets started once the requirement-gathering phase is completed.

The activities that take place during the Test Planning stage include:
 Identifying the testing objectives and scope
 Developing a test strategy: selecting the testing methods and techniques that will be
used
 Identifying the testing environment and resources needed
 Identifying the test cases that will be executed and the test data that will be used
 Estimating the time and cost required for testing
 Identifying the test deliverables and milestones
 Assigning roles and responsibilities to the testing team
 Reviewing and approving the test plan

At the end of this stage, the testing team should have a detailed plan for the testing
activities that will be performed, and a clear understanding of the testing objectives, scope,
and deliverables. This will help to ensure that the testing process is well-organized and that
the testing team is able to deliver high-quality results.

3. Test Case Development: The test case development phase gets started once the test
planning phase is completed. In this phase testing team notes down the detailed test cases.
The testing team also prepares the required test data for the testing. When the test cases
are prepared then they are reviewed by the quality assurance team.
The activities that take place during the Test Case Development stage include:
 Identifying the test cases that will be developed
 Writing test cases that are clear, concise, and easy to understand
 Creating test data and test scenarios that will be used in the test cases
 Identifying the expected results for each test case
 Reviewing and validating the test cases
 Updating the requirement traceability matrix (RTM) to map requirements to test cases

At the end of this stage, the testing team should have a set of comprehensive and accurate
test cases that provide adequate coverage of the software or application. This will help to
ensure that the testing process is thorough and that any potential issues are identified and
addressed before the software is released.

4. Test Environment Setup: Test environment setup is a vital part of the STLC. Basically, the
test environment decides the conditions on which software is tested. This is independent
activity and can be started along with test case development. In this process, the testing
team is not involved, either the developer or the customer creates the testing environment.

5. Test Execution: After the test case development and test environment setup test
execution phase gets started. In this phase testing team starts executing test cases based
on prepared test cases in the earlier step.
The activities that take place during the test execution stage of the Software Testing Life
Cycle (STLC) include:
 Test execution: The test cases and scripts created in the test design stage are run against
the software application to identify any defects or issues.
 Defect logging: Any defects or issues that are found during test execution are logged in
a defect tracking system, along with details such as the severity, priority, and description
of the issue.
 Test data preparation: Test data is prepared and loaded into the system for test
execution
 Test environment setup: The necessary hardware, software, and network
configurations are set up for test execution
 Test result analysis: The results of the test execution are analyzed to determine the
software’s performance and identify any defects or issues.
 Defect retesting: Any defects that are identified during test execution are retested to
ensure that they have been fixed correctly.
 Test Reporting: Test results are documented and reported to the relevant stakeholders.
It is important to note that test execution is an iterative process and may need to be
repeated multiple times until all identified defects are fixed and the software is deemed fit
for release.

6. Test Closure: Test closure is the final stage of the Software Testing Life Cycle (STLC) where
all testing-related activities are completed and documented. The main objective of the test
closure stage is to ensure that all testing-related activities have been completed and that
the software is ready for release.
At the end of the test closure stage, the testing team should have a clear understanding of
the software’s quality and reliability, and any defects or issues that were identified during
testing should have been resolved. The test closure stage also includes documenting the
testing process and any lessons learned so that they can be used to improve future testing
processes
Test closure is the final stage of the Software Testing Life Cycle (STLC) where all testing-
related activities are completed and documented.

The main activities that take place during the test closure stage include:
 Test summary report: A report is created that summarizes the overall testing process,
including the number of test cases executed, the number of defects found, and the
overall pass/fail rate.
 Defect tracking: All defects that were identified during testing are tracked and managed
until they are resolved.
 Test environment clean-up: The test environment is cleaned up, and all test data and
test artifacts are archived.
 Test closure report: A report is created that documents all the testing-related activities
that took place, including the testing objectives, scope, schedule, and resources used.
 Knowledge transfer: Knowledge about the software and testing process is shared with
the rest of the team and any stakeholders who may need to maintain or support the
software in the future.
 Feedback and improvements: Feedback from the testing process is collected and used
to improve future testing processes

Test closure is not just about documenting the testing process, but also about ensuring that
all relevant information is shared and any lessons learned are captured for future reference.

The goal of test closure is to ensure that the software is ready for release and that the
testing process has been conducted in an organized and efficient manner.

Fundamental approaches to apply Test Cases:

A test case is a document that describes an input, action or event and an expected response
to determine if a feature of an application is working correctly.

The Objective of Writing Test Cases in Software Testing

 To validate specific features and functions of the software.

 To guide testers through their day-to-day hands-on activity.
 To record a catalog of steps undertaken, which can be revisited in the event of a bug
popping up.
 To provide a blueprint for future projects and testers so they do not have to start work
from scratch.
 To help detect usability issues and design gaps early on.
 To help new testers and developers quickly pick up testing, even if they join in the middle
of an ongoing project.
Types of test case design techniques:
The test case design techniques can be classified into three major groups:
 Specification-based
 Structure-based
 Experience-based

Specification-Based or Black-Box techniques: Specification-based testing, also known as black-

box testing, is a testing technique that focuses on testing the software system based on its functional
requirements and specifications without any knowledge about the underlying code or system
structure.
1. Boundary Value Analysis (BVA) : identifies errors at the input domain’s boundary.

Simple example of boundary value analysis would be testing a text box that requires the user
to enter a number between 1 and 10. In this case, the boundary values would be 1 and 10,
and we would test with values that are just above, at, and just below these boundaries .

For example, we would test with 0, 1, 2, 9, 10, and 11.

We can expect that errors or defects are most likely to occur at or near the boundary values.
Identifying these issues early can help prevent them from causing problems later in the
software development process.

2. Equivalence Partitioning (EP) is another technique that helps reduce the required test
cases. By partitioning test input data into classes with an equivalent number of data, one can
design test cases for each class or partition. This technique ensures that one thoroughly tests
the software while minimizing the required test cases.
For example, if a program requires an input of numbers between 1 and 100, an EP test
would include a range of values, such as 1-50 and 51-100, and numbers outside that range,
such as -1 or 101. Testing one value from each partition is sufficient to test all values within
that partition.

3. Decision Table Testing: is a technique that involves designing test cases based on decision
tables formulated using different combinations of inputs and their corresponding outputs
based on various conditions and scenarios sticking to other business rules. This technique
ensures that we test the software thoroughly and accurately .

For example, if a program offers discounts based on the type of customer and the amount
spent, a decision table would list all possible combinations of customer types and the amount
paid to receive a discount. Each cell in the table would specify the value that should be
applied. Testers can ensure the program behaves correctly under various scenarios by
testing all combinations.

4. State Transition Diagrams (STD) to test software with a finite number of states of different
types. A set of rules that define the response to various inputs guides the transition from one
state to another. This technique is handy for systems with specific workflows within them.
For example, consider an e-commerce website that has different states such as “logged out,”
“logged in,” “cart empty,” “cart not empty,” and “order placed.”
The transitions between the states would be triggered by login in and logout, adding the
product to the cart, removing the product from the cart, proceeding to checkout, etc.
An STD can help visualize and test such complex states and transitions in a system.

Structure-Based or White-Box techniques: is a testing technique that involves the testing of

internal structures or components of software applications. In this approach, the tests interact with
the code directly. These tests are designed to ensure the code works correctly and efficiently.
The different methods used here are,

1. Statement Testing and Coverage is a technique that involves executing all the executable
statements in the source code at least once. We then calculate the percentage of executable
statements as per the given requirement.

For example, consider code that inputs two numbers and checks if the first number is greater
than or equal to the second. A statement coverage test would verify that both the “greater
than” and “equal to” statements are executed during testing to ensure that all code branches
are covered.

2. Decision Testing Coverage, also known as branch coverage, validates all the branches in
the code by executing each possible branch from each decision point at least once. This helps
ensure that no branch leads to unexpected application behavior.

For example, if a program requires an input of a number between 1 and 100 and uses an
“if/else” statement to check if the number is even, decision testing coverage would ensure
that both the even and odd outcomes have been tested to confirm all possible scenarios have
been checked.

3. Condition Testing, also known as Predicate coverage testing. It involves evaluating each
Boolean expression in the code and checking its output values, TRUE or FALSE, against the
expected outcomes. This test checks all outcomes at least once to achieve 100% code
coverage. We design test cases that make it easy to execute the condition outcomes.
For example, if a program determines whether a user is eligible for a discount based on age,
condition testing would verify that the code handles each age group accurately. It would test
age values such as one less than, one more than, and within the age range requirement to
evaluate if the code performs as expected.

4. Multiple Condition Testing aims to test different combinations of conditions to achieve

100% coverage. This technique requires two or more test scripts, which may require more
effort.
For example, if a program uses an “if/else” statement to check age and gender to provide a
discount, multiple condition testing would verify that the program handles all possible
scenarios correctly. It would test various age ranges and gender combinations to ensure the
code performs accurately for all possibilities.
5. All Path Testing leverages the source code of a program to find every executable path.
For example, if a program asks a user for two inputs (A and B) and has multiple conditions,
All Path Testing would ensure that each condition is tested independently. The technique
would test all combinations of A and B, including zero, negative, and positive Testings, to
identify any potential errors in the code.

Experience-Based techniques:

The experience-based techniques can be broadly categorized into the following types:

1. Error Guessing is a testing technique that relies on the testers’ skill, intuition, and
experience to anticipate potential errors in the product.

2. Exploratory Testing is a technique used to test applications without any formal

documentation. This method is recommended once scripted testing has been executed when
working on the software.

Best Practice for Writing Test Case:

There are certain practices that one could follow while writing the test cases that would be
considered beneficial.

1. Simple and clear: Test cases need to be very concise, clear, and transparent. They
should be easy and simple to understand not only for oneself but for others as well.

2. Maintaining the client/customer/end-user requirements must be unique: While writing

the test cases, it’s necessary to make sure that they aren’t being written over and over
again and that each case is different from the others.

3. Zero Assumptions: Test cases should not contain assumed data, and don’t come up with
features/modules that don’t exist.

4. Traceability: Test cases should be traceable for future reference.

5. Different input data: While writing test cases, all types of data must be taken into
consideration.

6. Strong module name: The module name should be self-explanatory while writing the
test case.

7. Minimal Description: The description of a test case should be small, one or two lines
are normally considered good practice, but it should give the basic overview properly.

8. Maximum conditions: All kinds of conditions should be taken into consideration while
writing a test, increasing the effectiveness.

9. Meeting requirements: While writing the test case the client/customer/end-user

requirements must be met.
10. Repetitive Results: The test case must be written in such a way that it should provide
the same result.

11. Different Techniques: Sometimes testing all conditions might not be possible but using
different testing with different test cases could help to check every aspect of a software.

12. Create test cases with the end user’s perspective: Create test cases by keeping end-
user in mind and the test cases must meet customer requirements.

13. Use unique Test Case ID: It is considered a good practice to use a unique Test Case ID
for the test cases following a naming convention for better understanding.

14. Add proper pre-conditions and post-conditions: Pre-conditions and post-conditions for
the test cases must be mentioned properly and clearly.

15. Test cases should be reusable: There are times when the developer updates the code,
then the testers need to update the test cases to meet the changing requirements.

16. Specify the exact expected outcome: Include the exact expected result, which tells us
what will be result of a particular test step.

Why write Test Cases :

To check whether the software meets customer expectations: Test cases help to check if a
particular module/software is meeting the specified requirement or not.
To check software consistency with conditions: Test cases determine if a particular
module/software works with a given set of conditions.
Narrow down software updates: Test cases help to narrow down the software needs and
required updates.
Better test coverage: Test cases help to make sure that all possible scenarios are covered and
documented.
For consistency in test execution: Test cases help to maintain consistency in test execution.
A well-documented test case helps the tester to just have a look at the test case and start
testing the application.
Helpful during maintenance: Test cases are detailed which makes them helpful during the
maintenance phase.
Levels of Testing:
Software testing is a process, to evaluate the functionality of a software application with an
intent to find whether the developed software meets the specified requirements or not and
to identify the defects to ensure that the product is defect free in order to produce the quality
product.

The levels of software testing involve the different methodologies, which can be used while
we are performing the software testing.

In software testing, we have four different levels of testing, which are as discussed below:

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

Level 1: Unit Testing:

Unit testing is the first level of software testing, which is used to test if individual software
modules are satisfying the given requirement or not. i.e., executing unit testing is to validate
unit components with their performance.

Unit Testing is done to check whether the individual modules of the source code are
working properly. i.e. testing each and every unit of the application separately by the
developer in the developer’s environment.

A unit component is an individual function of the application, or we can say that it is the
smallest testable part of the software. The reason of performing the unit testing is to test
the correctness of code.

Unit testing will help the test engineer and developers in order to understand the base of
code that makes them able to change defect causing code quickly.

Level 2: Integration Testing:

The second level of software testing is the integration testing. The integration testing process
comes after unit testing.

In integration testing, the test engineer tests the units or separate components or modules
of the software in a group.

The primary purpose of executing the integration testing is to identify the defects at the
interaction between integrated components or units.
When each component or module works separately, we need to check the data flow
between the dependent modules, and this process is known as integration testing.

Integration testing is done when the functional testing has been completed successfully on
each application module. i.e., integration testing aims to evaluate the accuracy of
communication among all the modules.

Approaches of Integration testing are,

Big Bang Integration Testing Approach
Top-Down Integration Testing Approach
Bottom-Up Integration Testing Approach

System Testing:
The third level of software testing is system testing, which is used to test the software's
functional and non-functional requirements. i.e., test the application as a whole system.

It is also known as end-to-end testing where the testing environment is parallel to the
production environment.

In system testing, we will go through all the necessary modules of an application and test if
the end features or the end business works fine, and test the product as a complete system.

System testing is a sequence of different types of tests to implement and examine the entire
working of an integrated software computer system against requirements.

Acceptance Testing:
The last and fourth level of software testing is acceptance testing, which is used to evaluate
whether a specification or the requirements are met as per its delivery.

The software has passed through three testing levels (Unit Testing, Integration Testing,
System Testing). Some minor errors can still be identified when the end-user uses the system
in the actual scenario.

The acceptance testing is also known as User acceptance testing (UAT) and is done by the
customer before accepting the final product.

UAT is done by the domain expert (customer) for their satisfaction and checks whether the
application is working according to given business scenarios and real-time scenarios.

Types of Acceptance Testing are - Alpha, Beta & Gamma Testing.

Alpha Testing: Alpha testing is mostly like performing usability testing which is done by the
in-house developers who developed the software. Sometimes this alpha testing is done by
the client or outsiders with the presence of developers or testers.
Beta Testing: Beta testing is done by a limited number of end users before delivery, the
change request would be fixed if the user gives feedback or reports defect.

Gamma Testing: Gamma testing is done when the software is ready for release with specified
requirements; this testing is done directly by skipping all the in-house testing activities.

The NextDate function:

Given a day in the format of day-month-year, user needs to find the next date for the given
date. i.e., It is a function that returns the date of the day after the input date.
The month, day and year values in the input date have numerical values with the following
constraints. A year is a leap year if it is divisible by 4.
Next Date” consists of three variables like: month (mm), date (dd) and year (yyyy).
It returns the date of next day as output.
It reads current date as input date.

Input classes:

Day: Month: Year:

D1: day between 1 to 28 M1: Month has 30 days Y1: Year is a leap year

D2: 29 M2: Month has 31 days Y2: Year is a normal year

D3: 30 M3: Month is February

D4: 31

Output Classes:

 Increment Day
 Reset Day and Increment Month
 Increment Year
 Invalid Date

Boundary Value Analysis:

No. of test Cases (n = no. of variables) = 4n+1 = 4*3 +1 =13

Test Cases for the above the problem:

Test Case ID Day Month Year Expected Output

1 1 6 2000 2-6-2000

2 2 6 2000 3-6-2000

3 15 6 2000 16-6-2000

4 30 6 2000 1-7-2000

5 31 6 2000 Invalid Date

6 15 1 2000 16-1-2000

7 15 2 2000 16-2-2000

8 15 11 2000 16-11-2000

9 15 12 2000 16-12-2000

10 15 6 1800 16-6-1800

11 15 6 1801 16-6-1801

12 15 6 2047 16-6-2047

13 15 6 2048 16-6-2048
Triangle problem:
The program reads three input numbers that represent the lengths of the three sides of a
triangle.
These are taken to be sides of a triangle. The output of the program is the type of triangle
determined by the three sides: Equilateral, Isosceles, Scalene, or Not A Triangle.
 Equilateral Triangle all the sides are equal.
 Isosceles Triangle exactly two sides are equal.
 Scalene Triangle all the sides are different.

Minimal Test:

The integers a, b, and c must satisfy the following conditions:

c1. 1 ≤ a ≤ 200 c2. 1 ≤ b ≤ 200 c3. 1 ≤ c ≤ 200
c4. a < b + c c5. b < a + c c6. c < a + b
If an input value fails any of conditions c1, c2, or c3, the program notes this with an output message,
for example, “Value of b is not in the range of permitted values.”

If values of a, b, and c satisfy conditions c1, c2, and c3, one of four mutually exclusive outputs is
given:

1. If all three sides are equal, the program output is Equilateral.

2. If exactly one pair of sides is equal, the program output is Isosceles.

3. If no pair of sides is equal, the program output is Scalene.

4. If any of conditions c4, c5, and c6 is not met, the program output is No t A Triangle.

The total test cases using Boundary Value Analysis (BVA) is,
4n+1 = 4*3+1 = 13
( 3 is the number of variables )
So, the test cases is,
Boundary Value testing:
Boundary value testing is a method used in software testing where inputs at the edge or
boundary of acceptable ranges are tested to ensure the system behaves correctly.
It involves testing with values at the lower and upper boundaries as well as just beyond those
boundaries to uncover potential issues.
i..e, Boundary value testing is a black box software testing technique where test cases are
designed using boundary values.
It is based on the single fault assumption, also known as critical fault assumption which states
that failures are the product of two or more simultaneous faults.
Hence, while designing the test cases for BVA we keep all but one variable to the nominal
value and allowing the remaining variable to take the extreme value.

Here in Boundary testing between extreme ends or boundaries between partitions of the
input values are performed.

Therefore, these extreme ends like Start- End, Lower- Upper, Maximum-Minimum, Just
Inside-Just Outside values are called boundary values and the testing is called “boundary
testing”.

The basic idea in normal boundary value testing is to select input variable values at their:
 Minimum
 Just above the minimum
 A nominal value
 Just below the maximum
 Maximum

Eg:

Generalizing boundary value analysis: refers to extending the principles of boundary value
testing beyond individual test cases to broader testing strategies and methodologies.

• Pattern Recognition: Identifying common patterns or categories of boundary conditions

across different input parameters or variables.
• Systematic Approach: Developing systematic approaches or guidelines for conducting
boundary value analysis across various domains and applications.

• Automation: Implementing automated tools or scripts to generate boundary value test

cases efficiently, especially for complex systems with multiple input parameters.

• Integration with Other Techniques: Integrating boundary value analysis with other
testing techniques such as equivalence partitioning, decision tables, and state transition
testing to create comprehensive test strategies.

• Risk-Based Testing: Prioritizing boundary value testing based on the perceived risk
associated with different boundary conditions, focusing efforts on critical areas.

• Continuous Improvement: Continuously refining boundary value analysis techniques

based on feedback from testing experiences and evolving understanding of system
requirements and behaviors.

 Documentation and Standardization: Documenting best practices, guidelines, and

standards for boundary value analysis to facilitate consistent and effective testing across
teams and projects.

• Cross-Domain Application: Applying boundary value analysis principles not only in

software testing but also in other domains such as hardware testing, quality assurance
processes, and regulatory compliance.

Guidelines for conducting boundary value testing:

• Identify Input Boundaries: Understand the input boundaries of the system under test.
This includes the minimum and maximum values allowed for each input parameter.

• Select Test Cases: Choose test cases that focus on the boundaries of these input ranges.
This means selecting values that are just below, just above, exactly at, and slightly beyond the
boundaries.
• Include Invalid Values: Test both valid and invalid boundary values. Invalid boundary
values are values that fall outside the acceptable range.

• Test Single Boundaries: Design test cases to examine single boundary values
independently.
This means focusing on one boundary at a time to ensure thorough coverage.

• Test Combinations: Test combinations of boundary values for multiple input parameters,
especially where interactions between parameters might occur.
• Include Edge Cases: Consider edge cases where the behavior of the system might change
abruptly.
These are situations where the input values are at the very extremes of the allowed range.

• Consider Data Types: Pay attention to data types and their specific boundary conditions.
For example, consider the boundaries for integers, floating-point numbers, strings, etc.

• Use Equivalence Partitioning: Employ equivalence partitioning to divide the input domain
into equivalence classes, and then apply boundary value testing within each class.
• Automate Testing: Whenever possible, automate boundary value testing to increase
efficiency and repeatability.
• Document Test Cases: Document the boundary value test cases thoroughly, including the
input values, expected results, and any additional context or assumptions.

Limitations of BVA:

• Not Comprehensive: It doesn't find all types of errors; some issues may remain
undetected.
• Limited Scope: It mainly focuses on specific input boundaries and may miss testing other
parts of the software.
• Complex Systems: In complex systems, interactions between different inputs can be hard
to predict, making it challenging to identify all relevant boundaries.
• Dependent on Specifications: It relies heavily on accurate specifications; if these are
unclear or incomplete, testing may not be effective.
• Time-Consuming: Testing large systems with boundary value analysis can take a lot of
time due to the generation and execution of numerous test cases.
• Potential for Missing Cases: It might overlook corner cases where multiple boundaries
interact, leading to possible errors being missed.
• Focus on Inputs, not Logic: It concentrates on input values rather than the functional logic
of the software, potentially leaving some defects undetected.

Software Testing tools:

• Selenium WebDriver: For automating web browser interactions.
• Appium: For automating mobile application testing (iOS and Android).
• Test Complete: For functional UI testing of web, desktop, and mobile apps.
• Katalon Studio: A comprehensive tool for web, API, mobile, and desktop automation.
• Robot Framework: An open-source automation framework for various types of testing.
• Cypress: Specifically designed for modern web application testing.
• Postman: For automating API testing and web services.
• Jenkins: For automating Continuous Integration (CI ) / Continuous Development (CD)
pipelines and integrating testing into development workflows .
Differentiate between White box and Black box testing
Robust Case Testing

Robustness testing is a type of testing that is performed to assess the ability of a system or
component to function correctly when it is subjected to invalid or unexpected inputs, or
when it is operating outside of its specified operating conditions. i.e., It's aims to evaluate a
system's ability to function properly under stressful or unfavorable conditions.
The purpose of robustness testing is to identify weaknesses or maintaining the security and
integrity of a software system that could lead to failures or unexpected behaviour when it
encounters abnormal inputs or adverse environmental conditions.
Robustness testing helps improve the reliability, performance, and overall quality of the
software.
It is typically used to test for the presence of memory leaks or other types of errors like high
temperature, humidity, etc. that can cause a system to crash.
Robustness testing is also sometimes referred to as reliability testing, stress testing, or
endurance testing.
The purpose of robustness testing is to identify the parts of the system that are most
vulnerable to failure and to determine how the system can be made more resistant to failure.
It is conducted after the system has been tested under normal conditions.
Robustness testing is typically conducted by subjecting the system to a variety of stressful
conditions, such as high temperatures, high humidity, high pressure, and high levels of
vibration.

Robustness testing typically involves:

• Invalid inputs: Providing the software with unexpected or incorrect input data to see how
it handles errors or unexpected situations.
• Extreme inputs: Using inputs at the limits or beyond the normal range to test how the
software handles boundary conditions.
• High load: Testing the software under conditions of high user traffic or heavy processing
loads to assess its performance and stability.
• Low system resources: Simulating scenarios where the system is under low memory, low
disk space, or low network bandwidth conditions.
• Faulty hardware or network conditions: Introducing faults or disruptions in the hardware
or network environment to see how the software responds.
• Concurrent access: Testing the software's ability to handle multiple users accessing it
simultaneously and ensuring data integrity and consistency.

Robustness testing is used to,

Handle Unexpected Inputs: Robustness testing is important because it helps ensure that a
system can handle unexpected or abnormal inputs without crashing.
Uncover Potential Issues: This type of testing can help uncover potential issues that could
cause a system to fail in unexpected ways. By uncovering these issues early on, they can be
fixed before the system is put into production.
Test Limits: It allows developers to test the limits of their software and ensure that it can
handle unexpected inputs and situations.
Uncover Hidden Bugs: This type of testing can help uncover hidden bugs that could cause
major problems in the field.
Stability: This can help to prevent software failures and crashes, and can also help to
improve the overall stability of your software.

Robust Testing Example:

Invalid Inputs: Instead of entering numbers like 5 or 10, you type in letters or symbols like
"abc" or "$%" to see how the calculator responds.
Does it show an error message or crash gracefully?

Extreme Inputs: You try performing calculations with really large numbers, like adding
9999999999999999999999 to 1.
This tests if the calculator can handle very big numbers without crashing or giving incorrect
results.

High Load: You press buttons rapidly or enter many calculations quickly to see if the calculator
slows down or crashes when it's being used a lot in a short time.
Low System Resources: You run the calculator while your computer is doing other tasks that
use a lot of memory or processing power.
This checks if the calculator still works when your computer is busy or has limited resources
available.

Faulty Hardware or Network Conditions: You might simulate a situation where your
computer's internet connection is unstable or there's a problem with the keyboard or mouse.
This tests if the calculator can still work properly even if there are issues with the hardware
or network.

Concurrent Access: You have multiple people using the calculator at the same time to see if
it can handle different people pressing buttons or entering calculations simultaneously
without getting confused or giving wrong answers.

Robust Test Cases are –

Test cases are 6*n+1 , n is number of variables
Boundary Value Test Cases are –
Test cases are, 4*n + 1, n is number of variables

Robust Test Cases are –

Test cases are 6*n+1 , n is number of variables

Worst Test Cases are –

Test cases are 5*n , n is number of variables

Worst-case testing : Worst-Case boundary value analysis is a Black Box software testing
technique and an extension of BVA testing technique.
• Worst-case testing is a method used to evaluate the performance or behavior of a system
or application under the most unfavorable conditions possible.
• In simple terms, it involves testing a system using the maximum or most extreme inputs
or scenarios to see how it responds.
• In Worst case boundary value testing, we make all combinations of each value of one
variable with each value of another variable.
Worst Test Cases are –
• Test cases are 5*n , n is number of variables

Suppose we have two variables x1 and x2 to test.

The range of x1: 10 to 90
The range of x2: 20 to 70

X1 X2

Min 10 20

Min+ 11 21

Nominal 50 45

Max- 89 69

Max 90 70
Testing points detected in Worst Case Boundary Value Testing.
Test cases:
 Total test cases = A*A
5*5=25
A= Number of testing points, These testing points are min, min+, nominal, max- and max.
We can generate 25 test cases from both variables x1 and x2 by making a combination of
each value of one variable with each value of another variable.

Test Case# X1,X2 Test Case # X1,X2 Test Case # X1,X2

1 10,20 2 10,21 3 10,45

4 10,69 5 10,70 6 11,20

7 11,21 8 11,45 9 11,69

10 11,70 11 50,20 12 50,21

13 50,45 14 50,69 15 50,70

16 89,20 17 89,21 18 89,45

19 89,69 20 89,70 21 90,20

22 90,21 23 90,45 24 90,69

25 90,70

Worst Boundary value testing on 2 variables

Special value testing:

It is executed by expert testers who go through each and every aspect of the program and
use their domain knowledge to devise test cases. This type of functional testing is highly
popular and provides most accurate results.

Special Value is an applied form of Functional Testing, that verifies whether each function of
the software application operates in conformance with the required specification. Here
testing is carried out,

 Based on past experiences, which validates that no bugs or defects are left undetected.
 It is Ad-hoc in nature.
 It has had some very valuable inputs and success in finding bugs and errors.
Random testing: Software testing in which the system is tested with the help of generating
random and independent inputs and test cases. It is a black box assessment outline technique
in which the tests are being chosen randomly and the results are being compared by some
software identification to check whether the output is correct or incorrect. Monkey Testing
i.e., here test cases are generated randomly without following any specific pattern or
strategy.
The idea behind random testing is to uncover defects or bugs in a software system by
subjecting it to unpredictable inputs or scenarios.

In random testing,
Input Selection: Test inputs are chosen randomly from the input domain of the software. This
means that inputs can include valid, invalid, and boundary values.

Execution: The selected test inputs are then executed against the software under test.

Analysis: The results of the execution are analyzed to determine if the software behaves as
expected or if any defects are encountered.

The characteristics of random testing:

1. It is performed where defects in a software application is not identified by the regular
intervals.
2. Random input is used to test the system performance and its reliability.
3. Saves time and effort than actual tests.
The strength of random testing are:
1. It is inexpensive to use
2. It does not have any bias
3. The bugs are found very easily and quickly
4. If software is used properly it will find the bugs.

Types of random testing:

1. Random input sequence generation: It is also known as Random Number Generator (RNG)
in which a random sequential number or symbols is being generated which cannot be
assumed during the random selection.
2. Random sequence of data inputs: n this, all the data are selected randomly for the inputs
which can be used during the testing.
3. Random data selection from an existing database: The record where all the data are
available from that record only the data can be selected for testing afterward no additional
data cannot be added which are not available in the record.
Commission problem:

A rifle salesperson in the former Arizona Territory sold rifle locks, stocks, and barrels made
by a gunsmith in Missouri.
Locks cost $45, Stocks cost $30, and Barrels cost $25.

The salesperson had to sell at least one lock, one stock, and one barrel (at least one
complete rifle) per month

Production limits:
Maximum of 70 locks ; 1<=locks<=70
Maximum of 80 stocks ; 1<=stocks<=80
Maximum of 90 barrels ; 1<=barrels<=90

After each town visit, the salesperson sent a telegram to the Missouri gunsmith with the
number of locks, stocks, and barrels sold in that town.

At the end of a month, the salesperson sends a very short telegram showing –1 lock sold ( to
indicate the end of inputs for a particular sale person)

The gunsmith then knew the sales for the month were complete and computed the
salesperson’s commission as follows:
10% on sales up to (and including) $1000
15% on the next $800
20% on any sales in excess of $1800.

The commission program produced a monthly sales report that gave the total number of
locks, stocks and barrels sold, the salesperson’s total dollar sales and finally the commission.

Sales= lock_price * tot_locks + stock_price * tot_stocks + barrel_price * tot_barrel

Commission ->
SATM (Simple Automatic Teller Machine) problem:
The SATM System Problem statement The SATM (Simplified Automated Teller Machine)
system communicates with bank customers via the 15 options available in the display screen.

Customers can select any of three transaction types

✓Deposits
✓Withdrawals
✓Balance enquires

Transactions can be done on two types of account

✓checking
✓savings

SATM GUI Interface

Problem Statement: The SATM system communicates with bank customers via the 15
screens shown in diagram.

Using a terminal with features as shown in Figure1, SATM customers can select any of three
Transaction types:

•Deposits •withdrawals, and •balance inquiries.

For simplicity, these transactions can only be done on a checking account.

When a bank customer arrives at an SATM station, screen 1 is displayed.

The bank customer accesses the SATM system with a plastic card encoded with a personal
account number (PAN), which is a key to an internal customer account file, containing, among
other things, the customer’s name and account information.

If the customer’s PAN matches the information in the customer account file, the system
presents screen2 to the customer.

If the customer’s PAN is not found, screen 4 is displayed, and the card is kept.

At screen2, the customer is prompted to enter his or her personal identification number
(PIN).

If the PIN is correct (i.e., matches the information in the customer account file),the system
displays screen5;otherwise,screen3 is displayed.
TEST CASES
Screen Outcome
Screen 1,4 - PAN not found
Screen 1,2,3 - PIN incorrect
Screen 1,2,5 - PIN correct
Screen 5,6,14 - Balance Inquiry
Screen 5,12 - Problem in deposits
Screen 5,13,12 - Problem in deposits
Screen 5,13,14,15 - successful deposits
Screen 5,7,8 - Problem in withdrawals
Screen 5,10 - Problem in withdrawals
Screen 5,7,11,15 - Successful withdrawals
*PAN- Personal Account Number