UNIT 6.

CODE DESIGN & SOFTWARE TESTING

6.1 Code Design

6.2 Testing Fundamentals
6.3 Testing Process
6.4 White box and Black Box Testing
6.5 Unit Testing
6.6 Integrated Testing
6.7 Test Data Preparations

6.1 Code Design

The objective of the coding phase is to transform the design of a system into code
The programmers adhere to standard and well defined style of coding which they call their coding
standard. The main advantages of adhering to a standard style of coding are as follows:
• A coding standard gives uniform appearances to the code written by different engineers
• It facilitates code of understanding.
• Promotes good programming practices.
For implementing our design into a code, we require a good high level language

Coding standards and guidelines

Good software development organizations usually develop their own coding standards and
guidelines depending on what best suits their organization and the type of products they develop.
The following are some rules of coding standards.

To make programming easier and more organized, every company or team follows certain rules for writing code.
Here are some key coding standards:

1. Rules for Using Global Variables

• Global variables are those that can be accessed from anywhere in the program.
• To avoid confusion, only certain types of data should be made global.
• Other data should be kept inside functions to prevent accidental changes.

2. Standard Headers in Code

Before writing code in any module (a part of a program), a header should be added with important details. This
helps others understand the code easily.

A standard header should include:

Module Name – The name of the file or module.

 UNIT 6. CODE DESIGN & SOFTWARE TESTING

Date Created – When the module was written.

Author’s Name – Who wrote the code.
Modification History – Any changes made over time.
Synopsis – A short description of what the module does.
Functions List – A list of functions in the module, including what inputs they take and what they return.
Global Variables Used – If any global variables are used or changed, they should be mentioned.

3. Naming Rules for Variables and Constants

To keep code clean and easy to read, use a standard way of naming variables:
Global Variables – Start with a capital letter (e.g., TotalCount).
Local Variables – Use small letters (e.g., sum).
Constants – Use all capital letters (e.g., MAX_VALUE).

4. Handling Errors Properly

• Every function should have a clear way to report errors.

• If something goes wrong, the program should not crash but instead return a proper error message.
• The same method should be used across the entire project to keep things consistent.

The following are some representative coding guidelines recommended by many software development
organizations.
Simple Coding Guidelines for Better Code

To write clean, understandable, and maintainable code, follow these simple rules:

1. Code Should Be Easy to Understand

• Write code that is clear and readable .

• Complicated or cryptic code makes it hard to understand and difficult to fix later.

2. Avoid Hidden Side Effects

• A function should not modify global variables or perform file operations unless it’s clearly mentioned in its
name or comments.
• Hidden side effects make debugging and understanding the code difficult.

3. Do Not Use One Variable for Multiple Purposes

• Every variable should have a clear purpose and a meaningful name.

• Using the same variable for multiple tasks can cause confusion and errors.

4. Write Clear Comments

• Add comments to explain what your code does.

• A good rule is to have at least one comment line for every three lines of code.

5. Keep Functions Short (Max 10 Lines)

 UNIT 6. CODE DESIGN & SOFTWARE TESTING

• A function should be short and do only one task.

• Long functions are harder to read and more prone to bugs.

6. Avoid Using goto Statements

• goto statements make the code messy and hard to follow.

• Use loops (for, while) or functions instead.

Code Review :
Code review for a model is carried out after the module is successfully compiled and the all
the syntax errors have been eliminated.
Code reviews are extremely cost-effective strategies for reduction in coding errors and to
produce high quality code.
These two types code review techniques are
1. code inspection
2. code walk through
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

CODE INSPECTION
The aim of code inspection is to discover some common types of errors caused due to
oversight and improper programming.
In addition to the commonly made errors, observance to coding standards is also checked
during code inspection.
Good software development companies collect statistics regarding different types of errors
commonly committed by their engineers and identify the type of errors most frequently
committed.
Following is a list of some classical programming errors which can be checked during code
inspection:
• Use of uninitialized variables.
• Jumps into loops.
• Nonterminating loops.
• Incompatible assignments.
• Array indices out of bounds.
• Improper storage allocation and deallocation.
• Mismatches between actual and formal parameter in procedure calls.
• Use of incorrect logical operators or incorrect precedence among operators.
• Improper modification of loop variables.
• Comparison of equally of floating point variables, etc.

CODE WALK THROUGHS

• Code walk through is an informal code analysis technique.

• This technique is undertaken after coding of module is completed.
• A few members of the development team are given the code few days before the walk
through meeting to read and understand code.

• Each member selects some test cases and simulates execution of the code by hand
(i.e. trace execution through each statement and function execution).
• The main objectives of the walk through are to discover the algorithmic and logical
errors in the code.
• The members note down their findings to discuss these in a walk through
meeting Some of these guidelines are the following:
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

• The team performing code walk through should not be either too big or too small.
Ideally, it should consist of between three to seven members.
• Discussion should focus on discovery of errors and not on how to fix the discovered
errors.
• Top level should not participate in discussion.

6. 2 Testing Fundamentals

Testing checks whether the actual software matches the expected requirements and
ensures the software is bug-free.
Testing is the process of executing a program to find errors. To make our software perform
well it should be error-free. If testing is done successfully it will remove all the errors from the
software.

Aim of Testing / Goal and Objective of Testing:

1. The first and the foremost objective of software testing is to ensure that it fulfills all
the requirements of the customer
2. Second main objective is to find out the defects or issues occurring in the application
before it are encountered by the end user.
3. Thirdly, to evaluate the overall performance of the application.
4. Providing a high quality product to the end user.
5. To evaluate security related issues for the application under test

6.3 Testing Process

Software testing is a process that to find out defects from the software and helps to make
quality software.
A good process for software testing will help the developer or the tester to find the
defects or issues in the software faster.
If you want to fix the defects fast, you should know the process. Here 7 steps in
software testing process are discussed.

Seven Steps of Testing Process / Phases of Software Testing life cycle (STLC)
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

1. Requirement Analysis:
• In this phase quality assurance team understands and analyze requirements to
determine what needs 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.

2. Test Planning:
• Based on the requirements, a test plan is created which outlines the scope,
objectives, resources, schedule, and approach for testing.
• This plan serves as a roadmap for the entire testing process.
• 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.

3. Test case development

• This phase involves the actual test case creation to verify that the software meets the
specified requirements or not.
• Test cases consist of a set of inputs, execution conditions, and expected results.
• Test cases can be manual or automated, depending on the project requirements.

4.Test Environment Setup

• A test environment is set up to mimic the production environment as closely as possible. This
includes hardware, software, network configurations, and test data necessary for conducting
tests.
• The test environment is created by developers or the customer.
• The different types of testing – manual, automated, performance, etc., are carried out
here.

5.Test Execution
• In this phase, the actual testing is performed according to the test plan and test cases. Testers
execute the test cases, record the results, and report any defects found.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

6 Test Closure
• Once all test activities are completed, a test closure report is prepared summarizing the
testing activities, achievements, issues encountered, and lessons learned during the
testing process.

The software testing life cycle (STLC) is a systematic and well-structured process of testing
software applications to uncover defects and errors and check whether it meets the specified
requirements.
It is an integral process in software development involving different phases, where each phase
has its own goals and deliverables.

Types of Testing:-

1. Unit Testing
It focuses on the smallest unit of software design. In this, we test an individual unit or group
of interrelated units. It is often done by the programmer by using sample input and observing
its corresponding outputs.
2. Integration Testing
The objective is to take unit-tested components and build a program structure that has been
dictated by design. Integration testing is testing in which a group of components is combined
to produce output.
Integration testing is of four types: (i) Top-down (ii) Bottom-up (iii) Sandwich (iv) Big-Bang
3. Regression Testing
Every time a new module is added leads to changes in the program. This type of testing
makes sure that the whole component works properly even after adding components to the
complete program.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

4. Smoke Testing
This test is done to make sure that the software under testing is ready or stable for further
testing
It is called a smoke test as the testing of an initial pass is done to check if it did not catch the
fire or smoke in the initial switch on.
Example:
If the project has 2 modules so before going to the module
make sure that module 1 works properly
5. Alpha Testing
This is a type of validation testing. It is a type of acceptance testing which is done before the
product is released to customers. It is typically done by QA people.
Example:
When software testing is performed internally within the organization
6. Beta Testing
The beta test is conducted at one or more customer sites by the end-user of the software.
This version is released for a limited number of users for testing in a real-time environment
Example:
When software testing is performed for the limited number of people
7. System Testing
This software is tested such that it works fine for the different operating systems. It is covered
under the black box testing technique. In this, we just focus on the required input and output
without focusing on internal working.
In this, we have security testing, recovery testing, stress testing, and performance testing
Example: This includes functional as well as nonfunctional testing
8. Stress Testing
In this, we give unfavourable conditions to the system and check how they perform in those
conditions.
10. Object-Oriented Testing
This testing is a combination of various testing techniques that help to verify and validate
object-oriented software. This testing is done in the following manner:
• Testing of Requirements,
• Design and Analysis of Testing,
• Testing of Code,
• Integration testing,
• System testing,
• User Testing.
11. Acceptance Testing
Acceptance testing is done by the customers to check whether the delivered products perform
the desired tasks or not, as stated in requirements.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

6. 3 White box and Black Box Testing

Types of Testing

1. Black Box Testing:

• Black box testing is a software testing technique where the internal workings of the
system under test are not known to the tester.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

• Instead, the tester focuses solely on the inputs and outputs of the software
without considering its internal code structure, algorithms, or implementation
details. The term "black box" refers to the idea that the system is treated as a
closed box, with only its observable behaviors being considered during testing.
• This can be applied to every level of software testing such as Unit, Integration,
System, and Acceptance Testing.

Black Box Testing Techniques includes:

• Equivalence Partitioning: Dividing the input domain into classes or partitions and
selecting representative values from each partition to design test cases.
• Boundary Value Analysis: Testing the boundaries between equivalence classes, as
errors often occur at the boundaries of input ranges.
• Decision Table Testing: Creating decision tables to test all possible combinations of
inputs and their corresponding actions or outcomes.

Black box testing is particularly useful for:

• Ensuring that the software meets its requirements and specifications.

• Identifying defects or discrepancies between expected and actual behaviors.
• Verifying that the software behaves correctly from the user's perspective,
regardless of its internal implementation.

Overall, black box testing helps ensure the quality and reliability of software by focusing on
its external behavior and user experience.

Advantages:

1. Focus on User Perspective: Black box testing prioritizes end-user experience,

ensuring that the software meets user requirements and expectations.
2. Independence from Implementation Details: Testers don't need access to the
internal code, making it suitable for testing teams with diverse backgrounds.
3. Thoroughness in Functionality Testing: It helps uncover defects in software
functionality, ensuring that the system operates as intended.
4. Early Detection of Usability Issues: Black box testing can detect usability
issues and user experience flaws early in the development cycle.
5. Higher-Level Perspective: Testers can assess the system from a higher-level
perspective, focusing on overall system behavior rather than individual
components.

Disadvantages:

1. Limited Coverage: Black box testing may not cover all possible scenarios, leading to
potential gaps in test coverage.
2. Inefficiency in Complex Systems: Testing without knowledge of internal
workings can be inefficient, especially in complex systems where understanding
internal behavior could streamline testing.
3. Difficulty in Defect Localization: Identifying the root cause of defects may be
challenging since testers lack visibility into the internal code.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

4. Overlap with Other Testing Methods: There can be overlap with other testing
methods, leading to redundancy in testing efforts.
5. Dependency on Requirements: Effectiveness depends heavily on the
quality and completeness of requirements documentation. If requirements
are incomplete or inaccurate, it may lead to ineffective testing.

1. Equivalence Class Testing:

• Equivalence Partitioning is also known as Equivalence Class Partitioning.

• In equivalence partitioning, Dividing the input domain into classes or partitions and
selecting representative values from each partition to design test cases.
• Each and every condition of particular partition (group) works as same as
other. If a condition in a partition is valid, other conditions are valid too.
If a condition in a partition is invalid, other conditions are invalid too.
• It helps to reduce the total number of test cases from infinite to finite. The selected test
cases from these groups ensure coverage of all possible scenarios.

Example on Equivalence Partitioning Test Case Design

Technique: Example-1:
Let us consider an example of any college admission process. There is a college that
gives admissions to students based upon their percentage.
Consider percentage field that will accept percentage only between 50 to 90 %, more and
even less than not be accepted, and application will redirect user to an error page.
If percentage entered by user is less than 50 %or more than 90 %, that equivalence
partitioning method will show an invalid percentage.
If percentage entered is between 50 to 90 %, then equivalence partitioning method will show
valid percentage.

Example 2 :
Assume, we have to test a field which accepts Age 18 – 56

valid Input: 18 – 56
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

Invalid Input: less than or equal to 17 (<=17), greater than or equal to 57

(>=57) Valid Class: 18 – 56 = Pick any one input test data from 18 – 56
Invalid Class 1: <=17 = Pick any one input test data less than or equal to
17 Invalid Class 2: >=57 = Pick any one input test data greater than or
equal to 57 We have one valid and two invalid conditions here.

2. Boundary Value Testing:

• Boundary value testing is focused on the values at boundaries.

• Testing the boundaries between equivalence classes, as errors often occur at the
boundaries of input ranges.
• 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.

For each boundary, we test +/-1 in the least significant digit of either side of the boundary.

Boundary value analysis can be applied at all test levels.

Example on Boundary Value Analysis Test Case Design Technique:

Assume, we have to test a field which accepts Age 18 – 56
Minimum boundary value is 18
Maximum boundary value is 56

Valid Inputs: 18, 19, 55

Invalid Inputs: 17

Test case 1: Enter the value 17 (18-1) =

Invalid Test case 2: Enter the value 18 =
Valid
Test case 3: Enter the value 19 (18+1) =
Valid Test case 4: Enter the value 55 (56-1)
= Valid

3. Decision Table Testing:

Creating decision tables to test all possible combinations of inputs and their corresponding
actions or outcomes.A decision table puts causes and their effects in a matrix. There is a
unique combination in each column.

It focuses on the business rule where logical conditions or decision-making steps are
required. Inputs are identified by the testers on which the actions are to be performed
based on conditions.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

White Box testing

White box testing, also known as clear box testing, glass box testing, or structural testing, is a
software testing method that examines the internal structure and logic of the software being
tested.
Unlike black box testing, where the internal workings of the system are not known to the tester, white
box testing requires knowledge of the internal code, architecture, and implementation details.

Here, the development team will review the entire coding part line by line to ensure the
correctness of the code. If he/she finds any dissimilarities or errors in the code, they will correct
or fix the errors in the coding or designs.
Here, the process is entirely carried out manually and it is efficient since the checking code or
design is manually checked by humans.
White box testing techniques include:
• Statement Coverage: Ensuring that each statement in the code is executed at least
once during testing.

• Branch Coverage: Ensuring that each decision point (branch) in the code is exercised
by at least one test case, including both true and false branches.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

• 4 test cases required such that all branches of all decisions are covered, i.e, all edges
of flowchart are covered

• Path Coverage: Ensuring that every possible path through the code is traversed by at
least one test case, aiming to test all possible combinations of branches and conditions.
• Mutation Testing: Introducing small changes (mutations) to the code and running test
cases to detect if the tests can identify these changes. This helps assess the
effectiveness of the test suite.
White box testing is particularly useful for:
• Identifying code defects, such as logical errors, syntax errors, or incorrect assumptions.
• Assessing code quality, including readability, maintainability, and adherence to coding
standards.
• Achieving thorough test coverage and ensuring that all code paths are tested.
Automation Potential: Many white box testing techniques, such as code reviews, static
analysis, and unit testing, can be automated, allowing for efficient and continuous testing.
The advantages of white-box testing include:
1. Spotting errors and problems more quickly
2. Providing introspection, or the ability to look into the software and examine it more
thoroughly
3. Finding hidden bugs more efficiently and ensuring greater stability
4. Optimizing the code due to the programming knowledge required
5. Obtaining maximum coverage of the different path present
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

The disadvantages of white-box testing include:

1. Higher degree of complexity involved due to the detailed programming knowledge
needed
2. More script maintenance needed as the underlying code can change frequently,
making it more likely that testing scripts could break
3. Requires tools that have tighter integration with the system being testing, which poses
the risk of system performance then being affected by those same tools, thus
interfering with the results
This testing technique is especially predominant in unit testing, whereby a tester examines at
a detailed level that the code written for a particular component works in isolation before
integrating it with the rest of the system.
It is used less often in higher-level testing.
Overall, white box testing complements black box testing by providing insight into the internal
behavior of the software and helping ensure its correctness and robustness from a code
perspective.

Parameter Black Box Testing White Box Testing

Meaning It is a software testing method in It is a software testing method in

which the program or the internal which the tester knows about the
structure stays hidden, and the tester code or the internal structure and
has no knowledge about it. the program involved.
Type of Testers Mostly, software testers do this. Mostly, hardware developers do
this.
Knowledge The user doesn’t require knowledge A user requires knowledge for
Required regarding implementation. implementation.
Type of Testing It is a form of external or outer It’s the inner or internal way of
software testing. software testing.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

Source Code The tester cannot access the source The tester is aware of the source
Access code of the software. code and internal workings of the
software.
Interface of You can conduct Black box testing at You can conduct White box testing
Operation the software interface. It requires no by ensuring that all the internal
concern with the software’s internal operations take place according
logical structure. to the specifications.
Purpose of It tests the functions of the software. It tests the structure of the
Testing software.

Basis of You can initiate this test on the basis You can only start this type of
Initiation of the requirement specifications testing software after a detailed
document. design document.
Programming Testers don’t require a knowledge of Testers mandatorily require a
Knowledge programming. knowledge of programming.
Assessment This testing assesses software This testing assesses software
behavior. logic.
Level of Testing Higher levels of software testing Lower levels of software testing
generally involve Black Box testing. usually involve White Box testing.
Other Names You can also call it closed testing. You can also call it clear box
testing.
Time It consumes less time. It consumes more time.
Consumed
Algorithm It does not work well for algorithm It is completely suitable and
Testing testing. preferable for algorithm testing.
Methods of One can perform it using various trial You can better test data domains
Testing and error methods and ways. and internal or inner boundaries.
Types of Black Box Testing types: White Box Testing types:
Testing
• Regression Testing • Condition Testing
• Functional Testing • Path Testing
• Non-Functional Testing • Loop Testing
Examples Example: A user searching Example: When a user inputs to
something on a search engine like check and verify the loops.
Google using certain keywords.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

6.3 Unit Testing

Unit testing, is a testing technique using which individual modules are tested to determine if
there are any issues by the developer himself. It is concerned with functional correctness of
the standalone modules.
• The main aim is to isolate each unit of the system to identify, analyze and fix the defects.
• A unit is the smallest testable part of any software. It usually has one or a few inputs and
usually a single output.
• In procedural programming, a unit may be an individual program,
function, Procedure, etc.
• In object-oriented programming, the smallest unit is a method, which may belong to a
base/ super class, abstract class or derived/ child class. Unit testing frameworks, drivers,
stubs, and mock/ fake objects are used to assist in unit testing.

Unit Testing - Advantages:

• Reduces Defects in the newly developed features or reduces bugs when changing the
existing functionality.
• Reduces Cost of Testing as defects are captured in very early phase.
• Improves design and allows better refactoring of code.
• Unit Tests, when integrated with build gives the quality of the build as
well. Unit Testing Techniques:
• Black Box Testing - Using which the user interface, input and output are tested.
• White Box Testing - used to test each one of those functions behavior is tested.
• Gray Box Testing - Used to execute tests, risks and assessment methods.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

6.4 Integration Testing

Integration testing is a critical phase in software development, focusing on testing the

interactions between integrated components to ensure they work together as intended.
Definition (1 mark): Integration testing is a software testing technique where individual
software modules or components are combined and tested as a group to validate their
interactions and interfaces.
1. Purpose: Integration testing verifies that integrated components work together correctly,
detecting issues such as communication errors, data exchange problems, and interface
mismatches early in the development process.

2. Types:

• Top-Down Integration: Testing starts with high-level modules and moves

down, using stubs to simulate lower-level modules.
• Bottom-Up Integration: Testing begins with low-level modules and moves up,
using drivers to simulate higher-level modules.
• Big Bang Integration: All modules are integrated simultaneously and tested as a
whole.
• Incremental Integration: Modules are integrated and tested incrementally in
small increments.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

3. Test Scenarios : Integration test scenarios are based on the interactions and data flow
between modules, including validating input/output interfaces, data exchange, and error
handling.
4. Test Techniques:
• Black Box Testing: Focuses on testing functionality without knowledge of
internal structures.
• White Box Testing: Examines internal logic and code paths to ensure correct
interactions.
• Interface Testing: Verifies communication and data exchange between modules.
• Error Handling Testing: Ensures modules handle errors and exceptions
correctly.

Advantages:

• Early detection of defects related to module interactions and interface

communication.
• Verification of correct communication and interaction between integrated
components.
• Improved overall reliability and stability of the system.
• Mitigation of risks associated with integrating complex systems.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

6.7 Test Data Preparation

Test data refers to the input data and conditions that are used during software testing to verify
the correctness, completeness, and quality of a software application or system.
It includes various types of data such as:
1. Input Data: Data provided to the software under test to simulate real-world usage
scenarios. This can include user inputs, API calls, database entries, file inputs, and system
configurations.
2. Expected Outputs: The expected results or behaviors of the software under test for a
given set of input data. These expected outcomes are used to validate the correctness of
the software's responses.
3. Boundary Conditions: Data representing the boundaries or limits of valid input ranges.
Testing with boundary conditions helps identify potential issues at the edges of acceptable
values.
4. Error Conditions: Data designed to trigger error-handling mechanisms within the
software. Testing with error conditions helps ensure that the software behaves
appropriately when encountering unexpected or invalid input.
5. Edge Cases: Uncommon or extreme scenarios that are unlikely to occur during normal
usage but may reveal vulnerabilities or weaknesses in the software. Testing with edge
cases helps improve the robustness and reliability of the software.
Test data is essential for conducting effective software testing, as it enables testers to evaluate
the behavior and performance of the software under various conditions.
By carefully selecting and preparing test data, testers can uncover defects, validate
functionality, and ensure that the software meets the desired quality standards before
deployment.

Example:
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

Here’s the example of test data for the calculator application presented in a
table format:
Test Scenario Operand 1 Operand 2 Expected Output

Addition Operation 5 3 8
Subtraction Operation 10 7 3
Multiplication Operation -4 6 -24
Division Operation 12 4 3
Division by Zero Error 8 0 Error: Division by zero

Floating Point Arithmetic 3.5 2.5 6.0

Large Numbers 999999999 888888888 1888888887
Negative Numbers -10 -5 -15
Zero Input 0 0 0
Overflow/Underflow 2147483647 1 Error: Overflow

This table organizes the test scenarios, input data, and expected outputs in a
clear and concise format, making it easy to understand and reference during
testing.

Test Data preparation :

Here are the steps to prepare test data in software engineering, summarized:
1. Understand Requirements: Know what needs to be tested.
2. Identify Test Scenarios: Determine the different conditions to be tested.
3. Define Inputs and Outputs: Specify the required inputs and expected outputs
for each scenario.
4. Identify Data Requirements: Figure out what data is needed for testing.
5. Generate Test Data: Create or obtain the necessary data for testing.
6. Ensure Data Quality: Validate data accuracy, completeness, and relevance.
7. Handle Privacy and Security: Protect sensitive information in the data.
8. Organize Test Data: Arrange data in a structured format for easy management.
9. Document Test Data: Clearly document the purpose and details of each set of data.
10. Validate Test Data: Confirm that the data aligns with test scenarios and objectives.
11. Maintain and Update: Regularly review and update test data to reflect
changes and improvements.

Example :
Let's walk through an example of test data preparation in software engineering using a simple
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

scenario of testing a login functionality for a web application:

Test Scenario Input Data Expected Outcome
Valid Login Username: user123, Password: pass123 Successful Login

Invalid Username Username: invaliduser, Password: Error: Invalid Username

pass123
Invalid Password Username: user123, Password: Error: Invalid Password
invalidpass
Empty Username Username: "", Password: pass123 Error: Username
required
Empty Password Username: user123, Password: "" Error: Password
required
SQL Injection Username: ' OR 1=1 -- , Password: any Error: Invalid
Attempt Username/Password

In this table:
• Test Scenario: Describes the specific scenario being tested.

• Input Data: Specifies the data provided for the test scenario.
• Expected Outcome: Defines the expected result or behavior when the provided
input data is used.
This table organizes the test scenarios, input data, and expected outcomes in a structured
manner, making it easier to plan and execute testing activities for the login functionality of
the web application.

Verification and Validation

Verification is the process of checking that a software achieves its goal without any bugs. It
is the process to ensure whether the product that is developed is right or not. It verifies
whether the developed product fulfills the requirements that we have. Verification is static
testing.

Validation is the process of checking whether the software product is up to the mark or in
other words product has high level requirements. It is the process of checking the validation of
product i.e. it checks what we are developing is the right product. it is validation of actual and
expected product. Validation is the dynamic testing.

Verification means Are we building the

product right?

Validation means Are we building the right

product?
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

Verification Validation
It includes checking documents, design, It includes testing and validating the actual product.
codes and programs.
Verification is the static testing. Validation is the dynamic testing.
It does not include the execution of the
It includes the execution of the code.
code.
Methods used in verification are Methods used in validation are Black Box Testing,
reviews, walkthroughs, inspections and White Box Testing and non- functional testing.
desk- checking.
It checks whether the software meets the
It checks whether the software
requirements and expectations of a customer or not.
conforms to specifications or not.
It can find the bugs in the early stage of It can only find the bugs that could not be found by the
the development. verification process.
The goal of verification is application
The goal of validation is an actual product.
and software architecture and
specification.