Implementation

A Mukuze
Implementation
• Implementing can be defined as putting (a decision, plan, agreement,
etc.) into effect.
• •Systems implementation is the delivery of that system into
production (that is, the day-to-day business or organization operation
• •It is important you understand that Implementation isn't about
BUILDING or PROGRAMMING a system, but rather making the system
live
Main Areas to be covered
• Implementation
• Coding
• Unit testing and debugging
• Conversion methods
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
• 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.
• To reduce the cost of later phases: The cost of testing and maintenance can be
significantly reduced with efficient coding.
• Making the program more readable: Program should be easy to read and
understand. It increases code understanding having readability and
understandability 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:
Characteristics of Programming
Language
 Characteristics of Programming Language
• Readability: A good high-level language will allow programs to be written in some methods that resemble a quite-
English description of the underlying functions. The coding may be done in an essentially self-documenting way.
• Portability: High-level languages, being virtually machine-independent, should be easy to develop portable software.
• Generality: Most high-level languages allow the writing of a vast collection of programs, thus relieving the
programmer of the need to develop into an expert in many diverse languages.
• Brevity: Language should have the ability to implement the algorithm with less amount of code. Programs mean in
high-level languages are often significantly shorter than their low-level equivalents.
• Error checking: A programmer is likely to make many errors in the development of a computer program. Many high-
level languages invoke a lot of bugs checking both at compile-time and run-time.
• Cost: The ultimate cost of a programming language is a task of many of its characteristics.
• Quick translation: It should permit quick translation.
• Efficiency: It should authorize the creation of an efficient object code.
• Modularity: It is desirable that programs can be developed in the language as several separately compiled modules,
with the appropriate structure for ensuring self-consistency among these modules.
• Widely available: Language should be widely available, and it should be feasible to provide translators for all the
major machines and all the primary operating systems.
• A coding standard lists several rules to be followed during coding, such as the way variables are to be named, the
way the code is to be laid out, error return conventions, etc.
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:
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:
• Emphasize the body of a control structure such as a loop or a select statement.
• Emphasize the body of a conditional statement
• 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.
Coding Guidelines
Coding Guidelines
• 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.
• Spacing: The appropriate use of spaces within a line of code can
improve readability.
• Example:
Bad: cost=price+(price*sales_tax)
fprintf(stdout ,"The total cost is %5.2f\n",cost);
Better: cost = price + ( price * sales_tax )
fprintf (stdout,"The total cost is %5.2f\n",cost);
Coding Guidelines
• 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.
Programming Style

• Programming style refers to the technique used in writing the source code
for a computer program. Most programming styles are designed to help
programmers quickly read and understands the program as well as avoid
making errors. (Older programming styles also focused on conserving
screen space.) A good coding style can overcome the many deficiencies of a
first programming language, while poor style can defeat the intent of an
excellent language.
• The goal of good programming style is to provide understandable,
straightforward, elegant code. The programming style used in a various
program may be derived from the coding standards or code conventions of
a company or other computing organization, as well as the preferences of
the actual programmer.
Some general rules or guidelines in respect of
programming style:
Some general rules or
guidelines in respect of
programming style:
• Clarity and simplicity of Expression: The programs should be designed in such a manner so that the objectives of the
program is clear.
• Naming: In a program, you are required to name the module, processes, and variable, and so on. Care should be taken
that the naming style should not be cryptic and non-representative.
• For Example: a = 3.14 * r * r
area of circle = 3.14 * radius * radius;
• 3. Control Constructs: It is desirable that as much as a possible single entry and single exit constructs used.
• 4. Information hiding: The information secure in the data structures should be hidden from the rest of the system where
possible. Information hiding can decrease the coupling between modules and make the system more maintainable.
• 5. Nesting: Deep nesting of loops and conditions greatly harm the static and dynamic behavior of a program. It also
becomes difficult to understand the program logic, so it is desirable to avoid deep nesting.
• 6. User-defined types: Make heavy use of user-defined data types like enum, class, structure, and union. These data
types make your program code easy to write and easy to understand.
• 7. Module size: The module size should be uniform. The size of the module should not be too big or too small. If the
module size is too large, it is not generally functionally cohesive. If the module size is too small, it leads to unnecessary
overheads.
• 8. Module Interface: A module with a complex interface should be carefully examined.
• 9. Side-effects: When a module is invoked, it sometimes has a side effect of modifying the program state. Such side-
effect should be avoided where as possible.
Structured Programming

• Structured Programming
• In structured programming, we sub-divide the whole program into
small modules so that the program becomes easy to understand. The
purpose of structured programming is to linearize control flow
through a computer program so that the execution sequence follows
the sequence in which the code is written. The dynamic structure of
the program than resemble the static structure of the program. This
enhances the readability, testability, and modifiability of the program.
This linear flow of control can be managed by restricting the set of
allowed applications construct to a single entry, single exit formats.
Why we use Structured
Programming?
• We use structured programming because it allows the programmer to
understand the program easily. If a program consists of thousands of
instructions and an error occurs then it is complicated to find that error in
the whole program, but in structured programming, we can easily detect
the error and then go to that location and correct it. This saves a lot of
time.
• These are the following rules in structured programming:
• Structured Rule One: Code Block
• If the entry conditions are correct, but the exit conditions are wrong, the error must
be in the block. This is not true if the execution is allowed to jump into a block. The
error might be anywhere in the program. Debugging under these circumstances is
much harder.
Rule 1 of Structured
Programming
• Rule 1 of Structured Programming: A code block is structured, as
shown in the figure. In flow-charting condition, a box with a single
entry point and single exit point are structured. Structured
programming is a method of making it evident that the program is
correct.
Structure Rule Two: Sequence

• A sequence of blocks is correct if the exit conditions of each block

match the entry conditions of the following block. Execution enters
each block at the block's entry point and leaves through the block's
exit point. The whole series can be regarded as a single block, with an
entry point and an exit point.
• Rule 2 of Structured Programming: Two or more code blocks in the
sequence are structured, as shown in the figure.
Structured Rule Three: Alternation
• If-then-else is frequently called alternation (because there are alternative
options). In structured programming, each choice is a code block. If
alternation is organized as in the flowchart at right, then there is one entry
point (at the top) and one exit point (at the bottom). The structure should be
coded so that if the entry conditions are fulfilled, then the exit conditions are
satisfied (just like a code block).
• Rule 3 of Structured Programming: The alternation of two code blocks is
structured, as shown in the figure.
• An example of an entry condition for an alternation method is: register $8
includes a signed integer. The exit condition may be: register $8 includes the
absolute value of the signed number. The branch structure is used to fulfill the
exit condition.
Rule 3 of Structured
Programming
Structured Rule 4: Iteration

• Iteration (while-loop) is organized as at right. It also has one entry

point and one exit point. The entry point has conditions that must be
satisfied, and the exit point has requirements that will be fulfilled.
There are no jumps into the form from external points of the code.
• Rule 4 of Structured Programming: The iteration of a code block is
structured, as shown in the figure.
Structured Rule 5: Nested Structures
• Structured Rule 5: Nested Structures
• In flowcharting conditions, any code block can be spread into any of the
structures. If there is a portion of the flowchart that has a single entry
point and a single exit point, it can be summarized as a single code block.
• Rule 5 of Structured Programming: A structure (of any size) that has a
single entry point and a single exit point is equivalent to a code block. For
example, we are designing a program to go through a list of signed integers
calculating the absolute value of each one. We may (1) first regard the
program as one block, then (2) sketch in the iteration required, and
finally (3) put in the details of the loop body, as shown in the figure.
 Structured Rule 5: Nested Structures

The other control structures

are the case, do-until, do-
while, and for are not needed.
However, they are sometimes
convenient and are usually
regarded as part of structured
programming. In assembly
language, they add little
convenience.
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. Normally, two types of
reviews are carried out on the code of a module. These two types
code review techniques are code inspection and code walk through.
Code Walk Throughs
• Code walk through is an informal code analysis technique. In this technique, after a module has been
coded, successfully compiled and all syntax errors eliminated. 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 where the coder of the
module is present. Even though a code walk through is an informal analysis technique, several guidelines
have evolved over the years for making this naïve but useful analysis technique more effective. Of course,
these guidelines are based on personal experience, common sense, and several subjective factors.
• Therefore, these guidelines should be considered as examples rather than accepted as rules to be applied
dogmatically. 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.
• In order to foster cooperation and to avoid the feeling among engineers that they are being evaluated in the code walk
through meeting, managers should not attend the walk through meetings.
 Code Inspection
• In contrast to code walk through, the aim of code inspection is to discover some common types of errors caused
due to oversight and improper programming. In other words, during code inspection the code is examined for the
presence of certain kinds of errors, in contrast to the hand simulation of code execution done in code walk
throughs. For instance, consider the classical error of writing a procedure that modifies a formal parameter while
the calling routine calls that procedure with a constant actual parameter.
• It is more likely that such an error will be discovered by looking for these kinds of mistakes in the code, rather than
by simply hand simulating execution of the procedure. In addition to the commonly made errors, adherence 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. Such a list of commonly committed errors can be used during code inspection to look out
for possible errors.
• 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.
Clean Room Testing
• Clean room testing was pioneered by IBM. This type of testing relies heavily on
walk throughs, inspection, and formal verification.
• The programmers are not allowed to test any of their code by executing the code
other than doing some syntax testing using a compiler.
• The software development philosophy is based on avoiding software defects by
using a rigorous inspection process.
• The objective of this software is zero-defect software.
• The name ‘clean room’ was derived from the analogy with semi-conductor
fabrication units. In these units (clean rooms), defects are avoided by
manufacturing in ultra-clean atmosphere. In this kind of development,
inspections to check the consistency of the components with their specifications
has replaced unit-testing.
Clean Room Testing
• This technique reportedly produces documentation and code that is more reliable and
maintainable than other development methods relying heavily on code execution-based
testing. The clean room approach to software development is based on five characteristics:
• Formal specification: The software to be developed is formally specified. A state transition model which
shows system responses to stimuli is used to express the specification.
• Incremental development: The software is partitioned into increments which are developed and
validated separately using the clean room process. These increments are specified, with customer input,
at an early stage in the process.
• Structured programming: Only a limited number of control and data abstraction constructs are used. The
program development process is process of stepwise refinement of the specification.
• Static verification: The developed software is statically verified using rigorous software inspections. There
is no unit or module testing process for code components
• Statistical testing of the system: The integrated software increment is tested statistically to determine its
reliability. These statistical tests are based on the operational profile which is developed in parallel with
the system specification. The main problem with this approach is that testing effort is increased as walk
throughs, inspection, and verification are time-consuming.
 Unit testing and debugging

Implementation
Software Engineering I
What is STLC?
• Software Testing Life Cycle [STLC] is the order of different activities
executed throughout the software testing process. Testing itself has
many phases called STLC, and each activity is done to improve the
quality of the software product.
S.NO Comparison basis SDLC STLC
1. Explanations It is primarily connected to software development, which means It is mainly linked to software testing, which means
that it is the procedure of developing a software application. that it is a software testing process that contains
various phases of the testing process.
2. Representation SDLC stands for Software Development Life Cycle. STLC stands for Software Testing Life cycle.
3. Resources While performing the SDLC process, we needed a greater number of The STLC process needed a smaller number of
developers to complete the development process. testers to complete the testing process.
4. Focuses on Besides the development phase, other phases like testing are also The STLC concentrate only on testing the software.
included.
5. Objective The objective of the Software development life cycle is to The objective of the Software testing life
complete the development of software successfully. cycle is to complete the testing of software
successfully.
6. Help in The SDLC will help us to develop a good quality software product. The STLC will helps to create the software bug-free.
7. Different phases •The various phase includes in Software Development Life •The various phase includes in Software Testing
Cycle are as follows:Requirements Collection Life Cycle are as follows:Requirement collection or
•Feasibility Study System study
•Design •Test Plan
•Programming or Coding •Write test case
•Testing •Traceability Matrix
•Installation •Defect Tracking
•Maintenance •Test Execution Report
•Retrospect meeting
8. Requirement In the SDLC Requirement collection phase, the BA [Business In the Requirement Analysis phase of the STLC, the
collection phase Analyst] and PA [ Product Analyst] will collect the requirements QA [ Quality Assurance]
and interpret business language into software language. team will study requirement documents and
prepare the System Test Plan.
9. Designing phase Based on the requirement understanding, the development team Generally, in STLC, the Test Architect or a Test
will develop the HLD [High-Level Design] and LLD [Low-Level Lead plan the test strategy.
Design] of the software. And also finds the testing points.
10. Coding phase In the SDLC coding phase, the developer will start writing the code In STLC, the QA team writes the test scenarios to
as per the designed document and beginning of building the authenticate the quality of the product.
software.
11. Environment Set up After writing the code, the development team sets up a test Based on the prerequisites, the Test team confirms
environment with the developed product to validate the code. the environment set up. And do one round of
smoke testing to ensure that the environment is
stable for the product and ready for testing.
Testing
• The SDLC and STLC provide a structure to
the development and testing of software.
• Generally, the test engineer may feel that the Software development
life cycle is appropriate to developers only. Still, after understood the
complete process of the development and testing life cycle, we can
say that both life cycles are dependent and time to time performed in
parallel.
• Hence, it is beneficial even to test engineers if they understand
the SDLC phase with STLC.
Testing Strategies
• Software is tested to uncover errors introduced during design and construction. Testing
often accounts for More project effort than other s/e activity. Hence it has to be done
carefully using a testing strategy.
• The strategy is developed by the project manager, software engineers and testing
specialists. Testing is the process of execution of a program with the intention of finding
errors Involves 40% of total project cost
• Testing Strategy provides a road map that describes the steps to be conducted as part of
testing.
• It should incorporate test planning, test case design, test execution and resultant data
collection and execution
• Validation refers to a different set of activities that ensures that the software is traceable
to the Customer requirements.
• V&V encompasses a wide array of Software Quality Assurance
A strategic Approach for Software
testing
• Testing is a set of activities that can be planned in advance and conducted
systematically. Testing strategy Should have the following characteristics:
• -- usage of Formal Technical reviews(FTR)
• -- Begins at component level and covers entire system
• -- Different techniques at different points
• -- conducted by developer and test group
• -- should include debugging Software testing is one element of verification and
validation.
• Verification refers to the set of activities that ensure that software correctly
implements a specific function. ( Ex: Are we building the product right? )
Validation refers to the set of activities that ensure that the software built is
traceable to customer requirements. ( Ex: Are we building the right product ? )
Testing Strategy
• Testing can be done by software developer and independent testing
group. Testing and debugging are different activities.
• Debugging follows testing Low level tests verifies small code
segments.
• High level tests validate major system functions against customer
requirements
Test Strategies for Conventional
Software:
• Testing Strategies for Conventional Software can be viewed as a spiral
consisting of four levels of testing:
• 1) Unit Testing
• 2)Integration Testing
• 3)Validation Testing and
• 4) System Testing
Testing for Conventional Software
Unit Testing
• Unit Testing begins at the vortex of the spiral and concentrates on
each unit of software in source code. It uses testing techniques that
exercise specific paths in a component and its control structure to
ensure complete coverage and maximum error detection. It focuses
on the internal processing logic and data structures. Test cases should
uncover errors.
Unit Testing
Unit Testing
• Boundary testing also should be done as s/w usually fails at its
boundaries. Unit tests can be designed before coding begins or after
source code is generated.
Unit Test Environment
Unit testing tools
• When we have to find and authenticate the particular module or unit of
the code, we need the unit testing tools. With the help of these tools,
we can build secure design and documentation and decrease the bug
count.
• Generally, unit testing is a manual process, but now some of the
organization has automated the unit test with the help of these tools.
By using unit testing tools, we can cover the maximum coverage,
performance, compatibility, and integration testing.
• All the unit testing tool is implemented as a plug-in for the eclipse. Unit
testing tools are used by the developers to test the source code of the
application or to achieve the source code of the application.
Why perform Unit Testing?
• Unit Testing is important because software developers sometimes try
saving time doing minimal unit testing and this is myth because
inappropriate unit testing leads to high cost defect fixing during
System Testing, Integration Testing and even Beta Testing after
application is built. If proper unit testing is done in early development,
then it saves time and money in the end.
Unit Testing
• Unit tests help to fix bugs early in the development cycle and save
costs.
• It helps the developers to understand the testing code base and
enables them to make changes quickly
• Good unit tests serve as project documentation
• Unit tests help with code re-use. Migrate both your code and your
tests to your new project. Tweak the code until the tests run again.
How to execute Unit Testing
• In order to execute Unit Tests, developers write a section of code to test a specific
function in software application. Developers can also isolate this function to test
more rigorously which reveals unnecessary dependencies between function being
tested and other units so the dependencies can be eliminated. Developers
generally use Unit Test Framework to develop automated test cases for unit
testing.
• Unit Testing is of two types
• Manual
• Automated
• Unit testing is commonly automated but may still be performed manually. Software
Engineering does not favor one over the other but automation is preferred. A
manual approach to unit testing may employ a step-by-step instructional
document.
• Under the automated approach-
• A developer writes a section of code in the application just to test the function.
They would later comment out and finally remove the test code when the
application is deployed.
• A developer could also isolate the function to test it more rigorously. This is a more
thorough unit testing practice that involves copy and paste of code to its own
testing environment than its natural environment. Isolating the code helps in
revealing unnecessary dependencies between the code being tested and other
units or data spaces in the product. These dependencies can then be eliminated.
• A coder generally uses a Unit Test Framework to develop automated test cases.
Using an automation framework, the developer codes criteria into the test to verify
the correctness of the code. During execution of the test cases, the framework logs
failing test cases. Many frameworks will also automatically flag and report, in
summary, these failed test cases. Depending on the severity of a failure, the
framework may halt subsequent testing.
• The workflow of Unit Testing is 1) Create Test Cases 2) Review/Rework 3) Baseline
4) Execute Test Cases.
Unit Testing Techniques
• The Unit Testing Techniques are mainly categorized into three parts which
are Black box testing that involves testing of user interface along with
input and output, White box testing that involves testing the functional
behaviour of the software application and Gray box testing that is used to
execute test suites, test methods, test cases and performing risk analysis.
• Code coverage techniques used in Unit Testing are listed below:
• Statement Coverage
• Decision Coverage
• Branch Coverage
• Condition Coverage
• Finite State Machine Coverage
Unit Test Example: Mock Objects
• Unit testing relies on mock objects being created to test sections of
code that are not yet part of a complete application. Mock objects fill
in for the missing parts of the program.
• For example, you might have a function that needs variables or
objects that are not created yet. In unit testing, those will be
accounted for in the form of mock objects created solely for the
purpose of the unit testing done on that section of code.
Most commonly used tools of unit
testing
NUnit
• One of the most commonly used unit testing tools is NUnit. It is an open-source tool
and initially ported from the JUnit, which works for all .Net languages. NUnit was
written entirely in the C# language and fully redesigned to get the advantage of many
.Net language features. Like custom attributes and other reflection related
capabilities.
• Features of NUnit
• It powerfully supports the data-driven tests.
• In this, we can execute the tests parallelly.
• It allows assertions as a static method of the asset class.
• It uses a console runner to load and execute tests.
• NUnit supports various platforms such as Silverlight, Xamarin mobile, .NET core, and
compact framework.
JUnit

• It is another open-source unit testing framework, which was written in

Java programing language. It is mainly used in the development of the test-driven
environment. Junit offers the annotation, which helps us to find the test method. This
tool helps us to enhance the efficiency of the developer, which provides the
consistency of the development code and reduces the time of the debugging.
• Feature of JUnit
• It offers the assertions for testing expected results.
• In this tool, we can quickly develop a code that enhances the quality of the code.
• This tool can be structured in the test suites, which have the test cases.
• To run the test, it gives the test runners.
• It will take less time to run the test cases.
TestNG
• It is an open-source tool, which supports Java and .Net programming languages. Test Next
Generation (TestNG) is an advance unit testing tool, which is stimulated from JUnit and NUnit
testing frameworks. Still, few new functionalities (Additional Annotation, Parallel Execution,
Group Execution, Html Report, and Listener) make a TestNG more powerful tool.
• For the automation process, TestNG will be used to handle the framework component and
achieve the batch execution without any human interference.
• Feature of TestNG
• TestNG support various instance of the same test cases, parameterized, annotation, data-driven,
functional, integration, and unit testing.
• In the case of development, TestNG will be used to develop a unit test case, and each unit test case will
test the business logic of the source code.
• It will provide a flexible test configuration.
• It will have the Dependent methods for application server testing
• With the help of TestNG, we have full control over the test cases and the execution of the test cases.
• It is supported by multiple plug-in and tools such as IDEA, Eclipse, and Maven, and so on.
Mockito
• It is a mocking framework that is used in the unit testing, and it was written in the Java
programing language. Mockito is also an open-source tool introduced by the
MIT (Massachusetts Institute of Technology) License.
• With the help of Mockito, we can develop the testable application. The primary objective of
using this tool is to simplify the development of a test by mocking external dependencies and
use them in the test code. It can be used with other testing frameworks such as TestNG and
Junit.
• Feature of Mockito
• It will be used to support exceptions.
• With the help of the annotation feature, we can produce the mocks.
• We do not need to write the mocks object on our own.
• It will support return values.
• It provides multiple methods like verify(), mock(), when(), etc., which are helpful to test Java applications.
PHPUnit
• Another unit testing tool is PHPUnit, which was written in PHP programing
language. It is an instance of the xUnit architecture and based on the JUnit
framework. It can generate the test results output in many various formats
with JSON, JUnit XML, TestDox, and Test anything protocol. We can run the
test cases on the cross-platform operating system.
• Features of PHPUnit
• PHPUnit will provide the logging, code coverage analysis.
• Its development is hosted on GitHub.
• PHPUnit uses assertions to validate the performance of the specific component.
• With the help of this tool, developers can identify the issues in their newly
developed code.
Testing and Debugging
• At the time of development and after the outcome of any application or
the software product established in any programming language,
both Testing and Debugging play a vital role in finding and removing
mistakes.
• Note: Both Testing and Debugging are two words that seem to share a
similar meaning but intensively different from one another.
• They have quite an equivalent function, but they are diverse in terms
of designs, requirements, benefits, and performance.
• Therefore, it is required for us to understand the differences between
testing and debugging properly that will support us in receiving better
software development outcomes.
Testing
Software Testing
• Software testing is a process of identifying defects in the software
product. It is performed to validate the behavior of the software or
the application compared to requirements.
• In other words, we can say that the testing is a collection of
techniques to determine the accuracy of the application under the
predefined specification but, it cannot identify all the defects of the
software.
• Each software or application needs to be tested before delivering to
the clients and checks whether the particular software or the
application is working fine as per the given requirements.
What is Debugging?

• As opposed to Testing, Debugging is the action where the development team or a developer
implements after receiving the test report related to the bugs in the software from the testing team.
• In the software development process, debugging includes detecting and modifying code errors in a
software program.
• In debugging process, the developer needs to identify the reason behind the particular bug or
defect, which is carried out by analyzing the coding rigorously.
• The developer changes the code and then rechecks whether the defect has been deleted whenever
the bug or error is found.
• Once the debugging is successfully finished, the application is again sent back to the test engineers,
who remain in the process of testing.
• The debugging process allows us an earlier finding of an error and makes software development
stress-free and easy.
• Now, based on features and technique of practice, we can distinguish between Testing and
Debugging.
Testing vs Debugging
S.NO Testing Debugging
1. It is the implementation of the software with the intent of identifying The process of fixing and resolving the defects is known as
the defects debugging.
2. Testing can be performed either manually or with the help of some The debugging process cannot be automated.
automation tools.
3. A group of test engineers executes testing, and sometimes it can be Debugging is done by the developer or the programmer.
performed by the developers.
4. The test engineers perform manual and automated test cases on the The developers will find, evaluates, and removes the software
application, and if they detect any bug or error, they can report back errors.
to the development team for fixing.
5. Programming knowledge is not required to perform the testing Without having an understanding of the programming
process. language, we cannot proceed with the debugging process.
6. Once the coding phase is done, we proceed with the testing process. After the implementation of the test case, we can start the
Debugging process.
7. Software Testing includes two or more activities such as validation and Debugging tries to match indication with cause, hence leading
verification of the software. to the error correction.
8. It is built on different testing levels such as Unit Testing, Integration It is built on different kinds of bugs because there is no such
Testing, System Testing, etc. level of debugging is possible.
9. Software testing is the presentation of defects. It is a logical procedure.
10. Software testing is the vital phase of SDLC (Software Development It is not a part of SDLC because it occurs as a subset of testing.
Life Cycle).
11. •Some advantages of software testing are as below:It can easily •Some advantages of debugging process are as follows:It
understand by the new test engineers or the beginner. supports the developer in minimizing the data.
•The test engineer can interact with software as a real end-user to •If the perform the debugging, we can report the error
check the usability and user interface issues. condition directly.
•It is used to test dynamically altering GUI designs. •During the debugging process, the developer can avoid
•Testing is a cost-effective and time-saving process. complex one-use testing code thathelps the developer save
•Software testing delivers a consistence software. time and energy.
•It will help us to execute the root cause analysis that will enhance the •Debugging delivers maximum useful information of data
software's productivity. structures and allows its informal understanding.
•The testing process also helps detect and fixing the bugs before the
software becomes active, which significantly reduces the risk of
failure.
12. •Software testing contains various type of testing methods, which are •Debugging involves a various type of approaches, which are
as follow:Black-box testing as follows:Induction
•White-box testing •Brute Force
•Grey-box testing •Deduction
DEBUGGING
Software Engineering I
DEBUGGING
• Need for Debugging Once errors are identified in a program code, it is
necessary to first identify the precise program statements responsible
for the errors and then to fix them. Identifying errors in a program
code and then fix them up are known as debugging.
Debugging Approaches
• Debugging Approaches The following are some of the approaches
popularly adopted by programmers for debugging.
• Brute Force Method:
• This is the most common method of debugging but is the least efficient
method. In this approach, the program is loaded with print statements to
print the intermediate values with the hope that some of the printed values
will help to identify the statement in error. This approach becomes more
systematic with the use of a symbolic debugger (also called a source code
debugger), because values of different variables can be easily checked and
break points and watch points can be easily set to test the values of variables
effortlessly.
Debugging Approaches
• Backtracking: This is also a fairly common approach. In this approach, beginning from
the statement at which an error symptom has been observed, the source code is
traced backwards until the error is discovered. Unfortunately, as the number of source
lines to be traced back increases, the number of potential backward paths increases
and may become unmanageably large thus limiting the use of this approach.
• Cause Elimination Method: In this approach, a list of causes which could possibly have
contributed to the error symptom is developed and tests are conducted to eliminate
each. A related technique of identification of the error from the error symptom is the
software fault tree analysis.
• Program Slicing: This technique is similar to back tracking. Here the search space is
reduced by defining slices. A slice of a program for a particular variable at a particular
statement is the set of source lines preceding this statement that can influence the
value of that variable.
Debugging Guidelines
• Debugging is often carried out by programmers based on their ingenuity.
• The following are some general guidelines for effective debugging:
• Many times debugging requires a thorough understanding of the program
design. Trying to debug based on a partial understanding of the system design
and implementation may require an inordinate amount of effort to be put into
debugging even simple problems.
• Debugging may sometimes even require full redesign of the system. In such
cases, a common mistake that novice programmers often make is attempting
not to fix the error but its symptoms.
• One must be beware of the possibility that an error correction may introduce
new errors. Therefore after every round of error-fixing, regression testing must
be carried out.
Program Analysis Tools
• A program analysis tool means an automated tool that takes the
source code or the executable code of a program as input and
produces reports regarding several important characteristics of the
program, such as its size, complexity, adequacy of commenting,
adherence to programming standards, etc.
• We can classify these into two broad categories of program analysis
tools:
• Static Analysis tools
• Dynamic Analysis tools
• Static program analysis tools
Static Analysis Tool
• Static Analysis Tool is also a program analysis tool. It assesses and computes various
characteristics of a software product without executing it. Typically, static analysis
tools analyze some structural representation of a program to arrive at certain
analytical conclusions, e.g. that some structural properties hold.
• The structural properties that are usually analyzed are:
•  Whether the coding standards have been adhered to?
•  Certain programming errors such as uninitialized variables and mismatch between actual
and formal parameters, variables that are declared but never used are also checked.
• Code walk throughs and code inspections might be considered as static analysis
methods. But, the term static program analysis is used to denote automated analysis
tools. So, a compiler can be considered to be a static program analysis tool.
Dynamic program analysis tools
• Dynamic program analysis techniques require the program to be executed and its actual behavior
recorded. A dynamic analyzer usually instruments the code (i.e. adds additional statements in the
source code to collect program execution traces). The instrumented code when executed allows
us to record the behavior of the software for different test cases. After the software has been
tested with its full test suite and its behavior recorded, the dynamic analysis tool caries out a post
execution analysis and produces reports which describe the structural coverage that has been
achieved by the complete test suite for the program. For example, the post execution dynamic
analysis report might provide data on extent statement, branch and path coverage achieved.
• Normally the dynamic analysis results are reported in the form of a histogram or a pie chart to
describe the structural coverage achieved for different modules of the program. The output of a
dynamic analysis tool can be stored and printed easily and provides evidence that thorough
testing has been done. The dynamic analysis results the extent of testing performed in white-box
mode. If the testing coverage is not satisfactory more test cases can be designed and added to
the test suite. Further, dynamic analysis results can help to eliminate redundant test cases from
the test suite
Conversion Methods
Software Engineering I
Conversion
• It is a process of migrating from the old system to the new one. It
provides understandable and structured approach to improve the
communication between management and project team.
Conversion Plan
• It contains description of all the activities that must occur during
implementation of the new system and put it into operation. It
anticipates possible problems and solutions to deal with them.
• It includes the following activities −
• Name all files for conversions.
• Identifying the data requirements to develop new files during conversion.
• Listing all the new documents and procedures that are required.
• Identifying the controls to be used in each activity.
• Identifying the responsibility of person for each activity.
• Verifying conversion schedules.
Conversion Methods
• The four methods of conversion are −
• Parallel Conversion
• Direct Cutover Conversion
• Pilot Approach
• Phase-In Method
Conversion Methods
Method Description Advantages Disadvantages
Provides fallback when new system Causes cost overruns.
fails. New system may not get fair trail.
Parallel Conversion Old and new systems are used Offers greatest security and
simultaneously. ultimately testing of new system.

Forces users to make new system No fall back if problems arise with
New system is implemented and old work new system
Direct Cutover Conversion Immediate benefit from new Requires most careful planning
system is replaced completely.
methods and control.
Allows training and installation A long term phase in causes a
without unnecessary use of problem of whether conversion
Supports phased approach that resources. goes well or not.
Pilot Approach gradually implement system across Avoid large contingencies from risk
all users management.

Provides experience and line test Gives impression that old system is
Working version of system before implementation erroneous and it is not reliable.
implemented in one part of When preferred new system
organization based on feedback, it is involves new technology or drastic
Phase-In Method changes in performance.
installed throughout the
organization all alone or stage by
stage.
References
• SDLC vs STLC – javatpoint -https://www.javatpoint.com/sdlc-vs-stlc