Unit 3-2
Unit 3-2
Unit 3-2
Coding
The coding is the process of transforming the design of a system into a computer
language format. This coding phase of software development is concerned with
software translating design specification into the source code. It is necessary to write
source code & internal documentation so that conformance of the code to its
specification can be easily verified.
Coding is done by the coder or programmers who are independent people than the
designer. The goal is not to reduce the effort and cost of the coding phase, but to cut
to the cost of a later stage. The cost of testing and maintenance can be significantly
reduced with efficient coding.
Goals of Coding:
1. To translate the design of system into a computer language format:
The coding is the process of transforming the design of a system into a computer
language format, which can be executed by a computer and that perform tasks as
specified by the design of operation during the design phase.
2. To reduce the cost of later phases:
The cost of testing and maintenance can be significantly reduced with efficient
coding.
3. Making the program more readable:
Program should be easy to read and understand. It increases code understanding
having readability and understand ability as a clear objective of the coding activity can
itself help in producing more maintainable software.
For implementing our design into code, we require a high-level functional language.
A programming language should have the following characteristics:
Coding Standards
General coding standards refers to how the developer writes code, so here we will
discuss some essential standards regardless of the programming language being used.
The following are some representative coding standards:
Indentation: Proper and consistent indentation is essential in producing easy to
read and maintainable programs.
Indentation should be used to:
o Emphasize the body of a control structure such as a loop or a select
statement.
o Emphasize the body of a conditional statement
o Emphasize a new scope block
Inline comments: Inline comments analyze the functioning of the subroutine, or
key aspects of the algorithm shall be frequently used.
Rules for limiting the use of global: These rules file what types of data can be
declared global and what cannot.
Structured Programming: Structured (or Modular) Programming methods shall
be used. "GOTO" statements shall not be used as they lead to "spaghetti" code,
which is hard to read and maintain, except as outlined line in the FORTRAN
Standards and Guidelines.
Naming conventions for global variables, local variables, and constant
identifiers: A possible naming convention can be that global variable names
always begin with a capital letter, local variable names are made of small letters,
and constant names are always capital letters.
Error return conventions and exception handling system: Different functions
in a program report the way error conditions are handled should be standard within
an organization. For example, different tasks while encountering an error condition
should either return a 0 or 1 consistently.
Coding Guidelines
General coding guidelines provide the programmer with a set of the best methods
which can be used to make programs more comfortable to read and maintain. Most of
the examples use the C language syntax, but the guidelines can be tested to all
languages.
The following are some representative coding guidelines recommended by many
software development organizations.
1. Line Length: It is considered a good practice to keep the length of source code
lines at or below 80 characters. Lines longer than this may not be visible properly on
some terminals and tools. Some printers will truncate lines longer than 80 columns.
2. Spacing: The appropriate use of spaces within a line of code can improve
readability.
3. 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.
4. The length of any function should not exceed 10 source lines: A very
lengthy function is generally very difficult to understand as it possibly carries out many
various functions. For the same reason, lengthy functions are possible to have a
disproportionately larger number of bugs.
5. Do not use goto statements: Use of goto statements makes a program
unstructured and very tough to understand.
6. Inline Comments: Inline comments promote readability.
7. Error Messages: Error handling is an essential aspect of computer
programming. This does not only include adding the necessary logic to test for and
handle errors but also involves making error messages meaningful.
Code Review:
What is Code Review?
Code review is a systematic and collaborative process in software development
where one or more developers examine and evaluate another developer’s code to
identify any issues, provide any feedback, and ensure that the code meets quality
standards. The primary goal is to improve the maintainability, quality, and reliability
of the codebase resulting in the overall success of a project while also promoting
knowledge sharing and learning among team members.
Bug Detection and Prevention: Code review helps detect and address errors, bugs,
and issues in the code before they propagate to production. This early detection
significantly helps in reducing the cost and effort required to fix problems later in the
development process or after deployment.
Improved Quality of Code: Code review encourages writing of clean,
maintainable, and efficient code. Reviewers can suggest enhancements, recommend
best practices, and ensure that the code aligns with the established coding standards
and guidelines.
Consistency: Code review enforces consistency in coding style and practices across
the team which makes the codebase easier to maintain and understand.
Knowledge Sharing and Learning: Code reviews offer opportunities for knowledge
sharing among team members to learn from one another. Discussions during these
reviews can help spread domain knowledge and best practices.
Code Ownership: Code reviewers take partial ownership of the code they review
thereby encouraging collective responsibility for the software’s quality.
Collaboration: Reviewers can collaborate during the review process, discussing
design decisions, trade-offs, and alternative solutions which can lead to improved
design decisions and more robust solutions.
Documentation: Code reviews can also serve as a form of documentation. Review
comments and discussions capture insights and decisions that may not be noticeable
from the code itself.
Quality Assurance: Code review is a critical part of quality assurance processes. By
thoroughly analyzing the code changes, teams can ensure that the software meets
the functional requirements and user expectations.
Continuous Improvement: Teams can often use code review as a tool for continuous
improvement. By analyzing the patterns of the feedback of code review, teams can
identify recurring issues and work on addressing them through training or process
improvements.
Performing code review involves a structured and collaborative process. The following
steps are involved in reviewing code:
1. Preparation: The developer who has completed a piece of code or feature initiates
the code review by creating a review request or notifying the team.
2. Reviewer Selection: One or more team members are assigned as reviewers.
Reviewers must have the relevant expertise to assess the code properly.
3. Code Review Environment or Tools: Code reviews are often facilitated using
specialized tools or integrated development environments (IDEs) that allow reviewers to
view the code changes and leave feedback.
4. Code Review Checklist: Reviewers may refer to a code review checklist or coding
standards to ensure that the code follows established guidelines.
5. Code Inspection: Reviewers examine the code thoroughly, looking for issues such
as: syntax errors, logic errors, performance bottlenecks, security vulnerabilities, coding
standard consistencies, adherence to best practices along with the code’s overall design,
scalability, and maintainability.
6. Feedbacks and Comments: Reviewers provide comments within the code review
tool, explaining any issues they find. These comments should be clear, constructive, and
specific, making it easier for the author to understand the feedback.
7. Discussion: The author and reviewers engage in a discussion about the code
changes. This dialogue can involve clarifications, explanations, and suggestions for
improvement.
8. Revisions: The author makes necessary changes based on the feedback received
and continues to engage in discussions until all concerns are addressed. This may
involve multiple review iterations.
9. Approval: Once reviewers are satisfied with the code changes and all concerns have
been resolved, they approve the code for integration.
10. Integration: The approved code changes are integrated into the main codebase,
typically using version control systems.
11. Follow-Up: After integration, it’s crucial to monitor the code in the production
environment to ensure that the changes work as expected and do not introduce new
issues.
12. Documentation and Closure: The code review process is documented for future
reference, and the review is officially closed. This documentation may include the review
comments, decisions made, and any action items.
Enhanced Code Quality: Code review helps identify and correct bugs early in the
development process, resulting in higher code quality.
Knowledge Sharing: Code reviews facilitate knowledge sharing among team members.
Consistency: Code reviews enforce coding standards and guidelines, ensuring that the
codebase is consistent and easier to maintain.
Security Improvements: Code review can help identify and mitigate security
vulnerabilities, improving the overall security of the software.
Team Collaboration: Code reviews encourage collaboration and communication among
team members. They provide a structured forum for discussing code changes and
making collective decisions.
Ownership: Code ownership becomes collective, reducing dependencies on specific
individuals since the reviews take partial ownership of the code being reviewed.
Documentation: Code reviews often involve discussions and comments, which can
serve as a form of documentation.
Code Reusability: By examining code thoroughly, developers can identify opportunities
for code reuse, leading to more efficient and maintainable software development.
Testing:
Software Testing is a method to assess the functionality of the software program.
The process checks whether the actual software matches the expected requirements and
ensures the software is bug-free. The purpose of software testing is to identify the
errors, faults, or missing requirements in contrast to actual requirements. It mainly aims
at measuring the specification, functionality, and performance of a software program or
application.
Software testing can be divided into two steps:
o Verification: It refers to the set of tasks that ensure that the software
correctly implements a specific function. It means “Are we building the
product right?”
o Validation: It refers to a different set of tasks that ensure that the
software that has been built is traceable to customer requirements. It
means “Are we building the right product?”
Principles of Testing
o All the tests should meet the customer’s requirements.
o To make our software testing should be performed by a third party.
o Exhaustive testing is not possible. As we need the optimal amount of
testing based on the risk assessment of the application.
o All the tests to be conducted should be planned before implementing it
o It follows the Pareto rule (80/20 rule) which states that 80% of errors
come from 20% of program components.
o Start testing with small parts and extend it to large parts.
o Types of Testing
Unit Testing:
Unit Testing is a software testing technique using which individual units of
software i.e. group of computer program modules, usage procedures, and operating
procedures are tested to determine whether they are suitable for use or not. It is a
testing method using which every independent module is tested to determine if there is
an issue by the developer himself. It is correlated with the functional correctness of the
independent modules. Unit testing is defined as a type of software testing where
individual components of a software are tested. Unit testing of the software product is
carried out during the development of an application. An individual component may be
either an individual function or a procedure. Unit testing is typically performed by the
developer. In SDLC or V Model, Unit testing is the first level of testing done before
integration testing. Unit testing is a type of testing technique that is usually performed
by developers. Although due to the reluctance of developers to test, quality assurance
engineers also do unit testing.
Objective of Unit Testing:
The objective of Unit Testing is:
o To isolate a section of code.
o To verify the correctness of the code.
o To test every function and procedure.
o To fix bugs early in the development cycle and to save costs.
o To help the developers understand the code base and enable them to
make changes quickly.
o To help with code reuse
3. Boundary value analysis – Boundaries are very good places for errors to occur.
Hence, if test cases are designed for boundary values of the input domain then the
efficiency of testing improves and the probability of finding errors also increases. For
example – If the valid range is 10 to 100 then test for 10,100 also apart from valid and
invalid inputs.
6. Compatibility testing – The test case results not only depends on the product but is
also on the infrastructure for delivering functionality. When the infrastructure parameters
are changed it is still expected to work properly. Some parameters that generally affect
the compatibility of software are:
o Processor (Pentium 3, Pentium 4) and several processors.
o Architecture and characteristics of machine (32-bit or 64-bit).
o Back-end components such as database servers.
o Operating System (Windows, Linux, etc).
White box testing techniques analyse the internal structures the used data
structures, internal design, code structure, and the working of the software rather
than just the functionality as in black box testing. It is also called glass box testing
or clear box testing or structural testing. White Box Testing is also known as
transparent testing or open box testing.
White box testing is a software testing technique that involves testing the
internal structure and workings of a software application. The tester has access to
the source code and uses this knowledge to design test cases that can verify the
correctness of the software at the code level.
White box testing is also known as structural testing or code-based testing, and
it is used to test the software’s internal logic, flow, and structure. The tester creates
test cases to examine the code paths and logic flows to ensure they meet the
specified requirements.
2. Branch Coverage:
In this technique, test cases are designed so that each branch from all
decision points is traversed at least once. In a flowchart, all edges must be
traversed at least once. This is like exploring all possible routes on a GPS. If
you’re at an intersection, branch testing involves going straight, turning left, and
turning right to ensure all paths lead to valid destinations. This technique checks
every possible path (if-else and other conditional loops) of a software application.
In a programming language, "branch" is equivalent to "IF statements." True
and False are the two branches of an IF statement. Therefore, in branch
coverage, we verify if each branch is executed at least once. Branch coverage is
also known as decision coverage.
There are two test criteria for an "IF statement":
1. To authenticate the actual branch.
2. To authenticate the false branch.
3.Path testing
In the path testing, we will write the flow graphs and test all independent
paths. Here writing the flow graph implies that flow graphs are representing the
flow of the program and also show how every program is added with one another
as we can see in the below image:
And test all the independent paths implies that suppose a path from main() to
function G, first set the parameters and test if the program is correct in that
particular path, and in the same way test all other paths and fix the bugs. Path
coverage analyzes all of the program's pathways. This robust strategy ensures that
all program routes are traversed at least once. Its coverage is more effective than
branch coverage. This method is handy for testing sophisticated applications.
4. Data Flow Testing (DFT): In this approach, you track the specific variables
through each possible calculation, thus defining the set of intermediate paths through
the code. DFT tends to reflect dependencies but it is mainly through sequences of
data manipulation. In short, each data variable is tracked and its use is verified. This
approach tends to uncover bugs like variables used but not initialize, or declared but
not used, and so on. Keeping with a proper testing technique, we write methods to
ensure they are testable – most simply by having the method return a value.
Additionally, we predetermine the “answer” that is returned when the method is
called with certain parameters so that our testing returns that predetermined value.
o Code implementation is
o Implementation of code is not
necessary for white box
needed for black box testing.
testing.
Integration testing
Integration testing is the process of testing the interface between two software
units or modules. It focuses on determining the correctness of the interface. The
purpose of integration testing is to expose faults in the interaction between
integrated units. Once all the modules have been unit-tested, integration testing is
performed.
Integration testing is a software testing technique that focuses on verifying the
interactions and data exchange between different components or modules of a
software application. The goal of integration testing is to identify any problems or
bugs that arise when different components are combined and interact with each
other. Integration testing is typically performed after unit testing and before system
testing. It helps to identify and resolve integration issues early in the development
cycle, reducing the risk of more severe and costly problems later on.
Integration testing can be done by picking module by module. This can be done
so that there should be a proper sequence to be followed. And also if you don’t want
to miss out on any integration scenarios then you have to follow the proper
sequence. Exposing the defects is the major focus of the integration testing and the
time of interaction between the integrated units. Integration test approaches – There
are four types of integration testing approaches.
Disadvantages:
o There will be quite a lot of delay because you would have to wait for all
the modules to be integrated.
o High-risk critical modules are not isolated and tested on priority since all
modules are tested at once.
o Not Good for long projects.
o High risk of integration problems that are difficult to identify and diagnose.
o This can result in long and complex debugging and troubleshooting efforts.
o This can lead to system downtime and increased development costs.
o May not provide enough visibility into the interactions and data exchange
between components.
o This can result in a lack of confidence in the system’s stability and
reliability.
o This can lead to decreased efficiency and productivity.
o This may result in a lack of confidence in the development team.
o This can lead to system failure and decreased user satisfaction.
Applications:
o Identify the components: Identify the individual components of your
application that need to be integrated. This could include the frontend,
backend, database, and any third-party services.
o Create a test plan: Develop a test plan that outlines the scenarios and
test cases that need to be executed to validate the integration points
between the different components. This could include testing data flow,
communication protocols, and error handling.
o Set up test environment: Set up a test environment that mirrors the
production environment as closely as possible. This will help ensure that
the results of your integration tests are accurate and reliable.
o Execute the tests: Execute the tests outlined in your test plan, starting
with the most critical and complex scenarios. Be sure to log any defects or
issues that you encounter during testing.
o Analyze the results: Analyze the results of your integration tests to
identify any defects or issues that need to be addressed. This may involve
working with developers to fix bugs or make changes to the application
architecture.
o Repeat testing: Once defects have been fixed, repeat the integration
testing process to ensure that the changes have been successful and that
the application still works as expected.
System Testing
System Testing is a type of software testing that is performed on a complete
integrated system to evaluate the compliance of the system with the
corresponding requirements. In system testing, integration testing passed
components are taken as input. The goal of integration testing is to detect any
irregularity between the units that are integrated together. System testing
detects defects within both the integrated units and the whole system. The result
of system testing is the observed behavior of a component or a system when it is
tested. System Testing is carried out on the whole system in the context of either
system requirement specifications or functional requirement specifications or in
the context of both. System testing tests the design and behavior of the system
and also the expectations of the customer. It is performed to test the system
beyond the bounds mentioned in the software requirements specification (SRS).
System Testing is basically performed by a testing team that is independent of
the development team that helps to test the quality of the system impartial. It
has both functional and non-functional testing. System Testing is a black-box
testing. System Testing is performed after the integration testing and before the
acceptance testing.