Unit 4 Software Engineering-204

Chanderprabhu Jain College of Higher Studies & School of Law
Plot No. OCF, Sector A-8, Narela, New Delhi – 110040

(Affiliated to Guru Gobind Singh Indraprastha University and Approved by Govt of NCT of Delhi & Bar Council of India)
COURSE : BCA
SEMESTER : FOURTH SEMESTER
SUBJECT CODE : BCA-204
NAME OF SUBJECT : S/W ENGINEERING
UNIT-4
CODE REVIEW
Code Review is a systematic examination, which can find and remove the
vulnerabilities in the code such as memory leaks and buffer overflows.
Technical reviews are well documented and use a well-defined defect detection
process that includes peers and technical experts.
•It is ideally led by a trained moderator, who is NOT the author.
•This kind of review is usually performed as a peer review without management
participation.
•Reviewers prepare for the review meeting and prepare a review report with a list
of findings.
•Technical reviews may be quite informal or very formal and can have a number of
purposes but not limited to discussion, decision making, evaluation of alternatives,
finding defects and solving technical problems.
Software Testing Process

Agile or Waterfall, Scrum or RUP, traditional or exploratory, there is a fundamental
process to software testing. Let’s take a look at the components that make up the
whole.
1: Test Strategy and Test Plan
Every project needs a Test Strategy and a Test Plan. These artefacts describe the
scope for testing for a project:
•The systems that need to be tested, and any specific configurations
•Features and functions that are the focus of the project
•Non-functional requirements
•Test approach—traditional, exploratory, automation, etc.—or a mix
•Key processes to follow – for defects resolution, defects triage
•Tools—for logging defects, for test case scripting, for traceability
•Documentation to refer, and to produce as output
•Test environment requirements and setup
•Risks, dependencies and contingencies
•Test Schedule
•Approval workflows
•Entry/Exit criteria
2: Test Design
Now that you have a strategy and a plan, the next step is to dive into creating a test
suite. A test suite is a collection of test cases that are necessary to validate the
system being built, against its original requirements.
Test design as a process is an amalgamation of the Test Manager’s experience of
similar projects over the years, testers’ knowledge of the system/functionality being
tested and prevailing practices in testing at any given point. For instance, if you
work for a company in the early stages of a new product development, your focus
will be on uncovering major bugs with the alpha/beta versions of your software,
and less on making the software completely bug-proof.
The product may not yet have hit the critical “star” or “cash cow” stages of its
existence—it’s still a question mark. And you probably have investors backing you,
or another product of your own that is subsidising this new initiative.
3: Test Execution
You can execute tests in many different ways—as single, waterfall SIT (System
Integration Test) and UAT (User Acceptance Test) phases; as part of Agile sprints;
supplemented with exploratory tests; or with test-driven development. Ultimately,
you need to do adequate amount of software testing to ensure your system is
(relatively) bug-free.
Let’s set methodology aside for a second, and focus on how you can clock adequate
testing. Let’s go back to the example of building a mobile app that can be supported
across operating systems, OS versions, devices. The most important question that
will guide your test efforts is “what is my test environment?”.
You need to understand your test environment requirements clearly to be able to
decide your testing strategy. For instance, does your app depend on integration with
a core system back end to display information and notifications to customers? If yes,
your test environment needs to provide back end integration to support meaningful
functional tests.
4: Test Closure
Right—so you have done the planning necessary, executed tests and now want to
green-light your product for release. You need to consider the exit criteria for
signalling completion of the test cycle and readiness for a release. Let’s look at the
components of exit criteria in general:
100% requirements coverage: all business and technical requirements have to be
covered by testing.
Minimum % pass rate: targeting 90% of all test cases to be passed is best practice.
All critical defects to be fixed: self-explanatory. They are critical for a reason.
As a rule of thumb, I’ve seen projects mandate 90% pass rate and all critical
defects being fixed before the team can move on to the next phase of the project.
And on big transformation initiatives, I’ve seen individual releases move to the
next phase (to aid beta pilots) with as little as 80%, with the understanding that the
product won’t reach the customer until mandatory exit criteria are met. Ultimately,
what works for your team is down to your circumstances and business demands.
Types of Testing
Introduction:-
Testing is the process of executing a program with the aim of finding 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.
Principles of Testing:-
(i) All the test should meet the customer requirements
(ii) To make our software testing should be performed by a third party
(iii) Exhaustive testing is not possible. As we need the optimal amount of testing
based on the risk assessment of the application.
(iv) All the test to be conducted should be planned before implementing it
(v) It follows the Pareto rule(80/20 rule) which states that 80% of errors come from
20% of program components.
(vi) Start testing with small parts and extend it to large parts.
Functional Testing types include: Non-functional Testing types

•Unit Testing include:
•Integration Testing •Performance Testing
•System Testing •Load Testing
•Sanity Testing •Stress Testing
•Smoke Testing •Volume Testing
•Interface Testing •Security Testing
•Regression Testing •Compatibility Testing
•Beta/Acceptance Testing •Install Testing
•Recovery Testing
•Reliability Testing
•Usability Testing
•Compliance Testing
•Localization Testing
Functional Testing
FUNCTIONAL TESTING is a type of software testing that validates the software
system against the functional requirements/specifications. The purpose of
Functional tests is to test each function of the software application, by providing
appropriate input, verifying the output against the Functional requirements.
Functional testing mainly involves black box testing and it is not concerned about
the source code of the application. This testing checks User Interface, APIs,
Database, Security, Client/Server communication and other functionality of the
Application Under Test. The testing can be done either manually or using
automation.
What do you test in Functional Testing?

The prime objective of Functional testing is checking the functionalities of the
software system. It mainly concentrates on -
Mainline functions: Testing the main functions of an application
Basic Usability: It involves basic usability testing of the system. It checks whether
a user can freely navigate through the screens without any difficulties.
Accessibility: Checks the accessibility of the system for the user
Error Conditions: Usage of testing techniques to check for error conditions. It
checks whether suitable error messages are displayed.
Examples of Functional testing are

1. Unit Testing
2. Smoke Testing
3. Sanity Testing
4. Integration Testing
5. White box testing
6. Black Box testing
7. User Acceptance testing
8. Regression Testing
STRUCTURAL TESTING
Structural Testing: White box testing technique which takes into account the
internal structure of a system or component and ensures that each program
statement performs its intended function. It is usually performed by the software
developers. Structural testing, also known as glass box testing or white box testing
is an approach where the tests are derived from the knowledge of the software's
structure or internal implementation.
The other names of structural testing includes clear box testing, open box testing,
logic driven testing or path driven testing.
Structural Testing Techniques:

Statement Coverage - This technique is aimed at exercising all programming
statements with minimal tests.
Branch Coverage - This technique is running a series of tests to ensure that all
branches are tested at least once.
Path Coverage - This technique corresponds to testing all possible paths which
means that each statement and branch are covered.
Control Flow Testing:

Control flow testing is a type of structural testing that uses the programs’s control
flow as a model. The entire code, design and structure of the software have to be
known for this type of testing. Often this type of testing is used by the developers
to test their own code and implementation. This method is used to test the logic of
the code so that required result can be obtained.
Data Flow Testing:

It uses the control flow graph to explore the unreasonable things that can happen to
data.
The detection of data flow anomalies are based on the associations between values
and variables. Without being initialized usage of variables. Initialized variables are
not used once.
Slice Based Testing:

It was originally proposed by Weiser and Gallagher for the software maintenance. It
is useful for software debugging, software maintenance, program understanding and
quantification of functional cohesion. It divides the program into different slices and
tests that slice which can majorly affect the entire software.
Mutation Testing:
Mutation Testing is a type of Software Testing that is performed to design new
software tests and also evaluate the quality of already existing software tests.
Mutation testing is related to modification a program in small ways. It focuses to
help the tester develop effective tests or locate weaknesses in the test data used for
the program.
Advantages of Structural Testing:

•Forces test developer to reason carefully about implementation
•Reveals errors in "hidden" code
•Spots the Dead Code or other issues with respect to best programming practices.
Disadvantages of Structural Box Testing:
•Expensive as one has to spend both time and money to perform white box testing.
•Every possibility that few lines of code is missed accidentally.
•Indepth knowledge about the programming language is necessary to perform
white box testing.
Testing Activities
Testing is a process rather than a single activity.Testing must be planned and it
requires discipline to act upon it.The quality and effectiveness of software testing
are primarily determined by the quality of the test processes used.
The activities of testing can be divided into the following basic steps:
•Planning and Control
•Analysis and Design
•Implementation and Execution
•Evaluating exit criteria and Reporting
•Test Closure activities
1) Planning and Control

Test Planning : Test planning involves producing a document that describes an
overall approach and test objectives. It involves reviewing the test basis, identifying
the test conditions based on analysis of test items, writing test cases and Designing
the test environment. Completion or exit criteria must be specified so that we know
when testing (at any stage) is complete.
Purpose
To determine the scope and risks and identify the objectives of testing.
To determine the required test resources like people, test environments etc.
To schedule test analysis and design tasks, test implementation, execution and
evaluation.
2) Analysis and Design

Test analysis and Test Design has the following major tasks:
To review the test basis.
The test basis is the information on which test cases are based, such as
requirements, design specifications, product risk analysis, architecture and
interfaces
•To identify test conditions
•To design the tests
•To design the test environment set-up and identify the required infrastructure and
tools
3) Implementation and Execution
Test execution involves actually running the specified test on a computer system
either manually or by using an automated test tool.It is a Fundamental Test Process
in which actual work is done.
Test implementation has the following major task:

•To develop and prioritize test cases by using techniques and create test data for
those tests.
•To create test suites from the test cases for efficient test execution. Test suite is a
collection of test cases that are used to test a software program
•To re-execute the tests that previously failed in order to confirm a fix.
•To log the outcome of the test execution. A test log is the status of the test case
(pass/fail).
•To compare actual results with expected results.
4) Evaluating Exit criteria and Reporting

Evaluating exit criteria is a process defining when to stop testing. It depends on
coverage of code, functionality or risk. Basically it also depends on business risk,
cost and time and vary from project to project. Exit criteria come into picture, when:
Maximum test cases are executed with certain pass percentage

•Bug rate falls below certain level
•When we achieve the deadlines
•Evaluating exit criteria has the following major tasks:
•To assess if more test are needed or if the exit criteria specified should be changed
•To write a test summary report for stakeholders
5) Test Closure activities:
Test closure activities are done when software is ready to be delivered.
•When a project is cancelled
•When some target is achieved
•When a maintenance release or update is done
Unit Testing
Unit testing ensures that each part of the code developed in a component delivers
the desired output. In unit testing, developers only look at the interface and the
specification for a component. It provides documentation of code development as
each unit of the code is thoroughly tested standalone before progressing to another
unit. Unit tests support functional tests by exercising the code that is most likely to
break. If you use functional tests without unit tests, you may experience several
smells:
•It’s hard to diagnose failed tests
•Test fixtures work around known issues rather than diagnosing and fixing them
Why 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.
In SDLC, STLC, V Model, Unit testing is first level of testing done before
integration testing. Unit testing is a WhiteBox testing technique that is usually
performed by the developer. Though, in a practical world due to time crunch or
reluctance of developers to tests, QA engineers also do unit testing.
Unit Testing Advantage

•Developers looking to learn what functionality is provided by a unit and how to
use it can look at the unit tests to gain a basic understanding of the unit API.
•Unit testing allows the programmer to refactor code at a later date, and make sure
the module still works correctly (i.e. Regression testing). The procedure is to write
test cases for all functions and methods so that whenever a change causes a fault, it
can be quickly identified and fixed.
•Due to the modular nature of the unit testing, we can test parts of the project
without waiting for others to be completed.
Unit Testing Disadvantages
•Unit testing can't be expected to catch every error in a program. It is not possible to
evaluate all execution paths even in the most trivial programs
•Unit testing by its very nature focuses on a unit of code. Hence it can't catch
integration errors or broad system level errors.
Unit Testing Tools

Junit: Junit is a free to use testing tool used for Java programming language. It
provides assertions to identify test method. This tool test data first and then inserted
in the piece of code.
NUnit: NUnit is widely used unit-testing framework use for all .net languages. It
is an open source tool which allows writing scripts manually. It supports data-
driven tests which can run in parallel.
JMockit: JMockit is open source Unit testing tool. It is a code coverage tool with
line and path metrics. It allows mocking API with recording and verification syntax.
This tool offers Line coverage, Path Coverage, and Data Coverage.
EMMA: EMMA is an open-source toolkit for analyzing and reporting code written
in Java language. Emma support coverage types like method, line, basic block.
PHPUnit: PHPUnit is a unit testing tool for PHP programmer. It takes small
portions of code which is called units and test each of them separately. The tool
also allows developers to use pre-define assertion methods to assert that a system
behave in a certain manner.
Integration Testing
INTEGRATION TESTING is defined as a type of testing where software
modules are integrated logically and tested as a group. A typical software project
consists of multiple software modules, coded by different programmers. The
purpose of this level of testing is to expose defects in the interaction between these
software modules when they are integrated
Integration Testing focuses on checking data communication amongst these
modules. Hence it is also termed as 'I & T' (Integration and Testing), 'String
Testing' and sometimes 'Thread Testing'.
Approaches, Strategies, Methodologies of Integration Testing

Software Engineering defines variety of strategies to execute Integration testing,
viz.
• Big Bang Approach :
• Incremental Approach: which is further divided into the following
• Top Down Approach
• Bottom Up Approach
• Sandwich Approach - Combination of Top Down and Bottom Up
How to do Integration Testing?
•The Integration test procedure irrespective of the Software testing strategies
•Prepare the Integration Tests Plan
•Design the Test Scenarios, Cases, and Scripts.
•Executing the test Cases followed by reporting the defects.
•Tracking & re-testing the defects.
•Steps 3 and 4 are repeated until the completion of Integration is successful.
Brief Description of Integration Test Plans:

It includes the following attributes:
•Methods/Approaches to testing (as discussed above).
•Scopes and Out of Scopes Items of Integration Testing.
•Roles and Responsibilities.
•Pre-requisites for Integration testing.
•Testing environment.
•Risk and Mitigation Plans.
Entry and Exit Criteria of Integration Testing
Entry Criteria:
•Unit Tested Components/Modules
•All High prioritized bugs fixed and closed
•All Modules to be code completed and integrated successfully.
•Integration tests Plan, test case, scenarios to be signed off and documented.
•Required Test Environment to be set up for Integration testing
Exit Criteria:
•Successful Testing of Integrated Application.
•Executed Test Cases are documented
•All High prioritized bugs fixed and closed
•Technical documents to be submitted followed by release Notes.
Best Practices/ Guidelines for Integration Testing
•First, determine the Integration Test Strategy that could be adopted and later
prepare the test cases and test data accordingly.
•Study the Architecture design of the Application and identify the Critical
Modules. These need to be tested on priority.
•Obtain the interface designs from the Architectural team and create test cases to
verify all of the interfaces in detail. Interface to database/external
hardware/software application must be tested in detail.
•After the test cases, it's the test data which plays the critical role.
•Always have the mock data prepared, prior to executing. Do not select test data
while executing the test cases.
System Testing
SYSTEM TESTING is a level of testing that validates the complete and fully
integrated software product. The purpose of a system test is to evaluate the end-to-
end system specifications. Usually, the software is only one element of a larger
computer-based system. Ultimately, the software is interfaced with other
software/hardware systems. System Testing is actually a series of different tests
whose sole purpose is to exercise the full computer-based system.
System Testing is Blackbox

Two Category of Software Testing
Black Box Testing
White Box Testing
System test falls under the black box testing category of software testing.
White box testing is the testing of the internal workings or code of a software
application. In contrast, black box or System Testing is the opposite. System test
involves the external workings of the software from the user's perspective.
System testing falls under Black box testing as it includes testing of the external
working of the software. Testing follows user's perspective to identify minor
defects.
System Testing includes the following steps.
Verification of input functions of the application to test whether it is producing the
expected output or not.
Testing of integrated software by including external peripherals to check the
interaction of various components with each other.
Testing of the whole system for End to End testing.
Behavior testing of the application via auser's experience
Different Types of System Testing

There are more than 50 types of System Testing. For an exhaustive list of software
testing types Below we have listed types of system testing a large software
development company would typically use:
• Usability Testing- mainly focuses on the user's ease to use the application,
flexibility in handling controls and ability of the system to meet its objective
• Load Testing- is necessary to know that a software solution will perform under
real-life loads.
• Regression Testing- involves testing done to make sure none of the changes made
over the course of the development process have caused new bugs. It also makes
sure no old bugs appear from the addition of new software modules over time.
• Recovery testing - is done to demonstrate a software solution is reliable,
trustworthy and can successfully recoup from possible crashes.
• Migration testing- is done to ensure that the software can be moved from older
system infrastructures to current system infrastructures without any issues.
•Functional Testing - Also known as functional completeness testing, Functional

Testing involves trying to think of any possible missing functions. Testers might
make a list of additional functionalities that a product could have to improve it
during functional testing.
•Hardware/Software Testing - IBM refers to Hardware/Software testing as
"HW/SW Testing". This is when the tester focuses his/her attention on the
interactions between the hardware and software during system testing.
What Types of System Testing Should Testers Use?
There are over 50 different types of system testing. The specific types used by a
tester depend on several variables. Those variables include:
•Who the tester works for - This is a major factor in determining the types of
system testing a tester will use. Methods used by large companies are different than
that used by medium and small companies.
•Time available for testing - Ultimately, all 50 testing types could be used. Time is
often what limits us to using only the types that are most relevant for the software
project.
Performance Testing
Performance Testing is a software testing process used for testing the speed,
response time, stability, reliability, scalability and resource usage of a software
application under particular workload. The main purpose of performance testing is
to identify and eliminate the performance bottlenecks in the software application. It
is a subset of performance engineering and also known as “Perf Testing”.
The focus of Performance Testing is checking a software program's
Speed - Determines whether the application responds quickly
Scalability - Determines maximum user load the software application can handle.
Stability - Determines if the application is stable under varying loads
Types of Performance Testing

•Load testing - checks the application's ability to perform under anticipated user loads.
The objective is to identify performance bottlenecks before the software application
goes live.
•Stress testing - involves testing an application under extreme workloads to see how it
handles high traffic or data processing. The objective is to identify the breaking point of
an application.
•Endurance testing - is done to make sure the software can handle the expected load
over a long period of time.
•Spike testing - tests the software's reaction to sudden large spikes in the load
generated by users.
•Volume testing - Under Volume Testing large no. of. Data is populated in a database
and the overall software system's behavior is monitored.
•Scalability testing - The objective of scalability testing is to determine the software
application's effectiveness in "scaling up" to support an increase in user load. It helps
plan capacity addition to your software system.
Performance Testing Process

The methodology adopted for performance testing can vary widely but the objective
for performance tests remain the same. It can help demonstrate that your software
system meets certain pre-defined performance criteria.
1.Identify your testing environment - Know your physical test environment,

production environment and what testing tools are available. Understand details of the
hardware, software and network configurations used during testing before you begin
the testing process. It will help testers create more efficient tests. It will also help
identify possible challenges that testers may encounter during the performance testing
procedures.
Identify the performance acceptance criteria - This includes goals and constraints for
throughput, response times and resource allocation. It is also necessary to identify project
success criteria outside of these goals and constraints. Testers should be empowered to set
performance criteria and goals because often the project specifications will not include a wide
enough variety of performance benchmarks. Sometimes there may be none at all. When
possible finding a similar application to compare to is a good way to set performance goals.
Plan & design performance tests - Determine how usage is likely to vary amongst end users
and identify key scenarios to test for all possible use cases. It is necessary to simulate a
variety of end users, plan performance test data and outline what metrics will be gathered.
Configuring the test environment - Prepare the testing environment before execution. Also,
arrange tools and other resources.
Implement test design - Create the performance tests according to your test design.
Run the tests - Execute and monitor the tests.
Analyze, tune and retest - Consolidate, analyze and share test results. Then fine tune and test
again to see if there is an improvement or decrease in performance. Since improvements
generally grow smaller with each retest, stop when bottlenecking is caused by the CPU. Then
you may have the consider option of increasing CPU power.
Example Performance Test Cases

•Verify response time is not more than 4 secs when 1000 users access the website
simultaneously.
•Verify response time of the Application Under Load is within an acceptable range
when the network connectivity is slow
•Check the maximum number of users that the application can handle before it
crashes.
•Check database execution time when 500 records are read/written simultaneously.
•Check CPU and memory usage of the application and the database server under
peak load conditions
•Verify response time of the application under low, normal, moderate and heavy
load conditions.
•During the actual performance test execution, vague terms like acceptable range,
heavy load, etc. are replaced by concrete numbers. Performance engineers set these
numbers as per business requirements, and the technical landscape of the
application.
Performance Test Tools

There are a wide variety of performance testing tools available in the market. The tool you
choose for testing will depend on many factors such as types of the protocol supported,
license cost, hardware requirements, platform support etc. Below is a list of popularly used
testing tools.
•LoadNinja – is revolutionizing the way we load test. This cloud-based load testing tool
empowers teams to record & instantly playback comprehensive load tests, without complex
dynamic correlation & run these load tests in real browsers at scale. Teams are able to
increase test coverage. & cut load testing time by over 60%.
•NeoLoad - is the performance testing platform designed for DevOps that seamlessly
integrates into your existing Continuous Delivery pipeline. With NeoLoad, teams test 10x
faster than with traditional tools to meet the new level of requirements across the full Agile
software development lifecycle - from component to full system-wide load tests.
•HP LoadRunner - is the most popular performance testing tools on the market today. This
tool is capable of simulating hundreds of thousands of users, putting applications under real-
life loads to determine their behavior under expected loads. Loadrunner eatures a virtual user
generator which simulates the actions of live human users.
•Jmeter - one of the leading tools used for load testing of web and application servers.
Common Performance Problems

Performance testing is done to make sure an app runs fast enough to keep a user's attention
and interest.
Long Load time - Load time is normally the initial time it takes an application to start. This
should generally be kept to a minimum. While some applications are impossible to make
load in under a minute, Load time should be kept under a few seconds if possible.
Poor response time - Response time is the time it takes from when a user inputs data into
the application until the application outputs a response to that input. Generally, this should be
very quick. Again if a user has to wait too long, they lose interest.
Poor scalability - A software product suffers from poor scalability when it cannot handle the
expected number of users or when it does not accommodate a wide enough range of users.
Bottlenecking - Bottlenecks are obstructions in a system which degrade overall system
performance. Bottlenecking is when either coding errors or hardware issues cause a decrease
of throughput under certain loads. Bottlenecking is generally fixed by either fixing poor
running processes or adding additional Hardware. Some common performance
bottlenecks are
CPU utilization, Memory utilization, Network utilization, Operating System limitations,Disk
usage
ERROR SEEDING
Error Seeding is the process of deliberately introducing errors within a program to
check whether the test cases are able to capture the seeded errors. This technique
aims to detect errors in order to find out the ratio between the actual and artificial
errors. Mills’error seeding model proposed an error seeding method to estimate
the number of errors in a program by introducing seeded errors into the program.
From the debugging data, which consist of inherent errors and induced errors, the
unknown number of inherent errors could be estimated. If both inherent errors and
induced errors are equally likely to be detected, then the probability of k induced
errors in r removed errors follows a hypergeometric distribution which is given by
Drawbacks:
1. It is expensive to conduct testing of the software and at the same time, it
increases the testing effort.
2. This method was also criticized for its inability to determine the type, location,
and difficulty level of the induced errors such that they would be detected
equally likely as the inherent errors.
DEBUGGING ACTIVITIES
In the context of software engineering, debugging is the process of fixing a bug in

the software. In other words, it refers to identifying, analyzing and removing errors.
This activity begins after the software fails to execute properly and concludes by
solving the problem and successfully testing the software. It is considered to be an
extremely complex and tedious task because errors need to be resolved at all stages
of debugging. Debugging is the process of detecting and removing of existing and
potential errors (also called as ‘bugs’) in a software code that can cause it to behave
unexpectedly or crash. To prevent incorrect operation of a software or system,
debugging is used to find and resolve bugs or defects. When various subsystems or
modules are tightly coupled, debugging becomes harder as any change in one
module may cause more bugs to appear in another. Sometimes it takes more time to
debug a program than to code it.
Debugging Process:
Steps involved in debugging are:
•Problem identification and report preparation.
•Assigning the report to software engineer to the defect to verify that it is genuine.
•Defect Analysis using modeling, documentations, finding and testing candidate
flaws, etc.
•Defect Resolution by making required changes to the system.
•Validation of corrections.
Debugging Strategies:
•Study the system for the larger duration in order to understand the system. It helps
debugger to construct different representations of systems to be debugging depends
on the need. Study of the system is also done actively to find recent changes made
to the software.
•Backwards analysis of the problem which involves tracing the program backward
from the location of failure message in order to identify the region of faulty code. A
detailed study of the region is conducting to find the cause of defects.
•Forward analysis of the program involves tracing the program forwards using
breakpoints or print statements at different points in the program and studying the
results. The region where the wrong outputs are obtained is the region that needs to
be focused to find the defect.
•Using the past experience of the software debug the software with similar
problems in nature. The success of this approach depends on the expertise of the
debugger.
Debugging Tools:
Debugging tool is a computer program that is used to test and debug other
programs. A lot of public domain software like gdb and dbx are available for
debugging. They offer console-based command line interfaces. Examples of
automated debugging tools include code based tracers, profilers, interpreters, etc.
Some of the widely used debuggers are:
•Radare2
•WinDbg
•Valgrind
MANAGEMENT OF MAINTENANCE
Software Maintenance is the process of modifying a software product after it has
been delivered to the customer. The main purpose is to modify and update software
application after delivery to correct faults and to improve performance.
Maintenance management – The versions, semi-versions and patch management
are added with the configuration management an then maintenance is carried out.
Need for Maintenance –
Software Maintenance must be performed in order to:
1. Correct faults.
2. Improve the design.
3. Implement enhancements.
4. Interface with other systems.
5. Accommodate programs so that different hardware, software, system features,
and telecommunications facilities can be used.
6. Migrate legacy software.
7. Retire software.
Categories of Software Maintenance –

Maintenance can be divided into the following:
Corrective maintenance:
Corrective maintenance of a software product may be essential either to rectify
some bugs observed while the system is in use, or to enhance the performance of
the system.
Adaptive maintenance:
This includes modifications and updations when the customers need the product to
run on new platforms, on new operating systems, or when they need the product to
interface with new hardware and software.
Perfective maintenance:
A software product needs maintenance to support the new features that the users
want or to change different types of functionalities of the system according to the
customer demands.
Preventive maintenance:
This type of maintenance includes modifications and updations to prevent future
problems of the software. It goals to attend problems, which are not significant at
this moment but may cause serious issues in future.
Maintenance Process Models

The need for maintenance-conscious models has been recognised for some time but
the current situation is that maintenance models are neither so well developed nor so
well understood as models for software development. In the early days, problems
with system development were overwhelming and it is not surprising that the
evolutionary nature of software that is at the heart of maintenance was to an extent
ignored. To attempt to take account of future changes in systems, prior to good
understanding of the development process, was akin to asking for the incorporation
of a crystal ball into the model. However, our understanding of the maintenance
process, just like our understanding of the development process, moved on and
maintenance process and lifecycle models emerged. In software engineering, there is
a great deal of demolition work going on simply because we cannot add the 'extra
room' safely. Predicting every future need is not possible and attempting to do so is
very costly. We can, however, do more to encompass the genuine needs of
maintenance within the models with which we work.
Software maintenance processes

This section describes the six software maintenance processes as:
•The implementation process contains software preparation and transition activities,
such as the conception and creation of the maintenance plan; the preparation for
handling problems identified during development; and the follow-up on product
configuration management.
•The problem and modification analysis process, which is executed once the
application has become the responsibility of the maintenance group. The
maintenance programmer must analyze each request, confirm it (by reproducing the
situation) and check its validity, investigate it and propose a solution, document the
request and the solution proposal, and finally, obtain all the required authorizations
to apply the modifications.
•The process considering the implementation of the modification itself.
•The process acceptance of the modification, by confirming the modified work with
the individual who submitted the request in order to make sure the modification
provided a solution.
•The migration process (platform migration, for example) is exceptional, and is not
part of daily maintenance tasks. If the software must be ported to another platform
without any change in functionality, this process will be used and a maintenance
project team is likely to be assigned to this task.
•Finally, the last maintenance process, also an event which does not occur on a
daily basis, is the retirement of a piece of software.
Reverse Engineering
It is a process to achieve system specification by thoroughly analyzing,
understanding the existing system. This process can be seen as reverse SDLC
model, i.e. we try to get higher abstraction level by analyzing lower abstraction
levels.
An existing system is previously implemented design, about which we know
nothing. Designers then do reverse engineering by looking at the code and try to
get the design. With design in hand, they try to conclude the specifications. Thus,
going in reverse from code to system specification.
Why Reverse Engineering?

•Providing proper system documentatiuon.
•Recovery of lost information.
•Assisting with maintenance.
•Facility of software reuse.
•Discovering unexpected flaws or faults.
Use of Software Reverse Engineering –

•Software Reverse Engineering is used in software design, reverse engineering
enables the developer or programmer to add new features to the existing software
with or without knowing the source code.
•Reverse engineering is also useful in software testing, it helps the testers to study
the virus and other malware code .
Software Re-engineering
When we need to update the software to keep it to the current market, without
impacting its functionality, it is called software re-engineering. It is a thorough
process where the design of software is changed and programs are re-written.
Legacy software cannot keep tuning with the latest technology available in the
market. As the hardware become obsolete, updating of software becomes a
headache. Even if software grows old with time, its functionality does not. For
example, initially Unix was developed in assembly language. When language C
came into existence, Unix was re-engineered in C, because working in assembly
language was difficult. Other than this, sometimes programmers notice that few
Re-Engineering Process
1. Decide what to re-engineer. Is it whole software or a part of it?
2. Perform Reverse Engineering, in order to obtain specifications of existing
software.
3. Restructure Program if required. For example, changing function-oriented
programs into object-oriented programs.
4. Re-structure data as required.
5. Apply Forward engineering concepts in order to get re-engineered software.
Software Configuration Management

In Software Engineering, Software Configuration Management(SCM) is a
process to systematically manage, organize, and control the changes in the
documents, codes, and other entities during the Software Development Life Cycle.
The primary goal is to increase productivity with minimal mistakes. SCM is part of
cross-disciplinary field of configuration management and it can accurately
determine who made which revision.
Why do we need Configuration management?

The primary reasons for Implementing Technical Software Configuration
Management System are:
•There are multiple people working on software which is continually updating

•It may be a case where multiple version, branches, authors are involved in a
software config project, and the team is geographically distributed and works
concurrently
•Changes in user requirement, policy, budget, schedule need to be accommodated.
•Software should able to run on various machines and Operating Systems
•Helps to develop coordination among stakeholders
•SCM process is also beneficial to control the costs involved in making changes to
a system
Configuration Identification:
Configuration identification is a method of determining the scope of the software
system. With the help of this step, you can manage or control something even if
you don't know what it is. It is a description that contains the CSCI type (Computer
Software Configuration Item), a project identifier and version information.
Activities during this process:
•Identification of configuration Items like source code modules, test case, and
requirements specification.
•Identification of each CSCI in the SCM repository, by using an object-oriented
approach
•The process starts with basic objects which are grouped into aggregate objects.
Details of what, why, when and by whom changes in the test are made
•Every object has its own features that identify its name that is explicit to all other
objects
•List of resources required such as the document, the file, tools, etc.
Software Configuration Management Plan

•The SCMP (Software Configuration management planning) process planning
begins at the early coding phases of a project. The outcome of the planning phase
is the SCM plan which might be stretched or revised during the project.
•The SCMP can follow a public standard like the IEEE 828 or organization
specific standard
•It defines the types of documents to be management and a document naming.
Example Test_v1
•SCMP defines the person who will be responsible for the entire SCM process and
creation of baselines.
•Fix policies for version management & change control
•Define tools which can be used during the SCM process
•Configuration management database for recording configuration information.
Test Documentation
Test documentation is documentation of artifacts created before or during the
testing of software. It helps the testing team to estimate testing effort needed, test
coverage, resource tracking, execution progress, etc. It is a complete suite of
documents that allows you to describe and document test planning, test design, test
execution, test results that are drawn from the testing activity.
The degree of test formality depends on
•The type of application under test
•Standards followed by your organization
•The maturity of the development process.
Testing activities generally consume 30% to 50% of software development project
effort. Documentations help to identify Test process improvement that can be
applied to future projects.
Why Test Formality?
For a newbie, it's easy to assume that Testing is executing the various section of
code on an ad-hoc basis and verifying the results. But in the real world, Testing is
a very formal activity and is documented in detail. Test Documentation makes
planning, review, and execution of testing easy as well as verifiable.
Advantages of Test Documentation

•The main reason behind creating test documentation is to either reduce or remove
any uncertainties about the testing activities. Helps you to remove ambiguity which
often arises when it comes to the allocation of tasks
•Documentation not only offers a systematic approach to software testing, but it
also acts as training material to freshers in the software testing process
•It is also a good marketing & sales strategy to showcase Test Documentation to
exhibit a mature testing process
•Test documentation helps you to offer a quality product to the client within
specific time limits
•In Software Engineering, Test Documentation also helps to configure or set-up the
program through the configuration document and operator manuals
•Test documentation helps you to improve transparency with the client
Disadvantages of Test Documentation

•The cost of the documentation may surpass its value as it is very time-consuming
•Many times, it is written by people who can't write well or who don't know the
material
•Keeping track of changes requested by the client and updating corresponding
documents is tiring.
•Poor documentation directly reflects the quality of the product as a
misunderstanding between the client and the organization can occur

Unit 4 Software Engineering-204

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 4 Software Engineering-204

Uploaded by

Copyright:

Available Formats

Chanderprabhu Jain College of Higher Studies & School of Law

Plot No. OCF, Sector A-8, Narela, New Delhi – 110040

Software Testing Process

Functional Testing types include: Non-functional Testing types

What do you test in Functional Testing?

Examples of Functional testing are

Structural Testing Techniques:

Control Flow Testing:

Data Flow Testing:

Slice Based Testing:

Advantages of Structural Testing:

1) Planning and Control

2) Analysis and Design

Test implementation has the following major task:

4) Evaluating Exit criteria and Reporting

Maximum test cases are executed with certain pass percentage

Why Unit Testing?

Unit Testing Advantage

Unit Testing Tools

Approaches, Strategies, Methodologies of Integration Testing

Brief Description of Integration Test Plans:

System Testing is Blackbox

Different Types of System Testing

•Functional Testing - Also known as functional completeness testing, Functional

Types of Performance Testing

Performance Testing Process

1.Identify your testing environment - Know your physical test environment,

Example Performance Test Cases

Performance Test Tools

Common Performance Problems

In the context of software engineering, debugging is the process of fixing a bug in

Categories of Software Maintenance –

Maintenance Process Models

Software maintenance processes

Why Reverse Engineering?

Use of Software Reverse Engineering –

Software Configuration Management

Why do we need Configuration management?

•There are multiple people working on software which is continually updating

Software Configuration Management Plan

Why Test Formality?

Advantages of Test Documentation

Disadvantages of Test Documentation

You might also like