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 in a high level language and
then to unit test this 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 representative coding standards.

1. Rules for limiting the use of global: These rules list what types of data can be declared global and what
cannot.

2. Contents of the headers preceding codes for different modules: The information contained in the headers
of different modules should be standard for an organization. The exact format in which the header
information is organized in the header can also be specified.

The following are some standard header data:

• Name of the module.
• Date on which the module was created.
• Author’s name.
• Modification history.
• Synopsis of the module.
• Different functions supported, along with their input/output parameters.
• Global variables accessed/modified by the module.
3. Naming conventions for global variables, local variables, and constant identifiers: A possible naming
convention can be that –
global variable names always start with a capital letter,
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

local variable names are made of small letters, and

constant names are always capital letters.
4. Error return conventions and exception handling mechanisms: The way error conditions are reported by
different functions in a program are handled should be standard within an organization.

For example, different functions while encountering an error condition should either return a 0 or 1
consistently.

The following are some representative coding guidelines recommended by many software development
organizations.

1. Do not use a coding style that is too clever or too difficult to understand: Code should be easy to
understand.

Many inexperienced engineers actually take pride in writing cryptic and incomprehensible code. Clever
coding can obscure meaning of the code and hamper understanding. It also makes maintenance
difficult.

2. Avoid obscure side effects: The side effects of a function call include modification
of parameters passed by reference, modification of global variables,
and I/O operations.

For example, if a global variable is changed obscurely in a called module or some file I/O is
performed which is difficult to infer from the function’s name and header information, it becomes
difficult for anybody trying to understand the code.

3. Do not use an identifier for multiple purposes: Programmers often use the same identifier to denote
several temporary entities.

For example, three variables use up three memory locations, whereas the same variable used in
three different ways uses just one memory location. However, there are several things wrong with this
approach and hence should be avoided.

Some of the problems caused by use of variables for multiple purposes as follows:

1. Each variable should be given a descriptive name indicating its purpose.

2. Use of a variable for multiple purposes can lead to confusion and make it difficult for somebody
trying to read and understand the code.

4. The code should be well-documented: As a rule of thumb, there must be at least one comment line on the
average for every three-source line.

5. The length of any function should not exceed 10 source lines: A function that is very lengthy is usually very
difficult to understand as it probably carries out many different functions.

For the same reason, lengthy functions are likely to have disproportionately larger number of bugs.

6. Do not use goto statements: Use of goto statements makes a program unstructured and very
difficult to understand.

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.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

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.
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.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

 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:
 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.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

6.2 Testing Fundamentals

Testing process 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
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

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)

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.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

 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.

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.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

6.4 White Box and Black Box Testing

Types of Testing
 UNIT 6. CODE DESIGN & SOFTWARE 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.
 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.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

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.
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.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

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
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
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

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.
 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
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

4. Optimizing the code due to the programming knowledge required

5. Obtaining maximum coverage of the different paths present
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.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

6.5 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.6 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:
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

 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.
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
 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:
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
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

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.
 UNIT 6. CODE DESIGN & SOFTWARE 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
scenario of testing a login functionality for a web application:

Test Scenario Input Data Expected Outcome

Valid Login Username: user123, Password: Successful Login
pass123
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:
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

 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.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

Verification and Validation :

 UNIT 6. CODE DESIGN & SOFTWARE TESTING

Short Questions:

1. List out any four coding standards.

2. Write any four coding guidelines.
3. Explain code review techniques.
4. What is testing? What is objective of testing?
5. List out various phases of STLC.
 UNIT 6. CODE DESIGN & SOFTWARE TESTING

6. What are the differences between SDLC and STLC?

7. List out Black box testing techniques.
8. What are the various techniques for White box testing?
9. Explain Boundary value testing.
10. What is integrated testing, and how does it differ from unit testing?
11. What are the various approaches of Integration testing?
12. What is test data? How many types of data it contains?
13. Describe the difference between validation and verification in testing.
14. What are the advantages and disadvantages of black box testing approach?
15. What are the advantages and disadvantages of white box testing approach?
16. What is unit testing, and why is it important?
17. Give an example of test data preparation in software engineering.

Long Questions:

1. Discuss Coding Standards and Guidelines in detail.

2. What is code review? Discuss two type of code review techniques.
3. What is software testing? Discuss different phases of testing process.
Or Discuss Software Testing Development Life cycle.
4. Differentiate black box and white box testing techniques.
5. Discuss Black Box testing.
6. Discuss White Box testing.
7. Discuss unit testing in detail
8. Discuss Integration testing in detail.
9. Differentiate Unit and Integration testing.
10. Explain test data preparation with example.
11. Differentiate verification and validations in detail.