Software Engineering 3 Coding Testing PDF

IT3205: Fundamentals of
Software Engineering
(Compulsory)
IT3205 - Software Design
IT3205: Fundamentals of Software

Engineering
Coding
Duration: 3 hours
UCSC - 2014 2
Learning Objectives
• Select appropriate programming language and
development tools for a given problem •
Identify the features of a good program, good
programming practices and program
documentation
UCSC - 2014 3
Detailed Syllabus
5.1 Programming languages and development tools
5.2 Selecting languages and tools
5.3 Good programming practices
What is Coding (Implementation)?

UCSC - 2014 4
• Transforms the design specification to source code that can

be executed on a computer.
• This is the final stage of the series of front end activities we
have been dealing with.
• Coding is relatively straight forward given a design
specification.
• Coding is a minor activity compared to the other phases of
development.
• A good design may be spoiled by the bad choice of a
language.
• However, a bad design cannot be corrected through coding.
UCSC - 2014 5
What is Coding (Implementation)?

• Choice of the language and the coding style are important
issues to consider.
• The programmer translates the design into source code of the
chosen programming language.
• The language translator converts the source code in to
executable code in several steps.
• Certain design issues may not be supported by the language
in which case the coder may choose to violate design.
UCSC - 2014 6
• Although design quality should not be compromised because

of a language issue, design approach may depend on the
language choice.
Coding
• The goal of the coding is to implement the design in
the best possible manner.
• Coding activity affects both testing and maintenance
phases.
UCSC - 2014 7
• Time spent in coding is a small percentage of the

total software cost, but the goal should be to reduce
the cost of later phases.
• Having readability and understandability as a clear
objective of the coding activity can itself help in
producing software that is more maintainable.
5.1 PROGRAMMING
UCSC - 2014 8
LANGUAGES AND DEVELOPMENT
TOOLS
UCSC - 2014 9
Language
Features
This table describes the strengths and weaknesses of some of the more important
languages in current use.
Language Features Strengths Weaknesses
Ada - Procedural - Strong type checking - Large run time system - Some object
reduces errors on requires. orientation built in applications. -
Expensive to develop exception handling. - US DOS support applications.
- Strong type checking - Good for safety critical - Requires powerful
- No pointers and military machine to run on.
- Defined standards applications. - Compliers meet the defined standards.
C - Procedural - Widely used different, don’t meet
- Weak type checking - Poor exception standard.
- Very low level pointers handling support. -
- Flexible Memory handling
- Close to hardware/OS - Fast and leads to unreliable
efficient applications can be built. code. - Compilers all
UCSC - 2014 10
Language
Features
C++ - OO extension to C. - All those of C and OO - As for C and can simple
- Weak type checking concepts of write C.
- Flexible Polymorphism,
- Pointers Inheritance (single &
multiple), Encapsulation
etc.
COBOL - Procedural - Suited to batch TP - Large run time system
- Strong I/O handling for applications required.
transaction processing - Widely used - Old - many features
(TP). - Most 4GLs interface to simply added on later.
- Defined standards COBOL. - Not all compilers meet
standard.
Fortran - Procedural - Suited to data analysis - Old - more modern
- Strong arithmetic where significant languages provide most of
support through arithmetic processing the features.
libraries. required.
Language
Features
Java - Object Oriented - Good user interface Controlled by a
- Better type checking than C but and network support commercial
still reasonably weak. - Standard through libraries. - organization.
defined by Sun Microsystems. Ideal for network
- Platform independent. - Dynamic - Requires own run
downloading of classes. time environment. -
Pascal - Procedural applications. Good OO concepts in user
- Strong type checking teaching language interface handling.
- Defined standard - Widely usedUCSC - 2014
- Not widely used in
Visual - Simple procedural industry - Poor
- Suited to small
Basic language. environment support
applications and
- Interpreted - Extensive Windows - Performance
prototyping. - Some
programming support
UCSC - 2014 12
Language
Features
- Complex data structures cannot 11
be modeled.
Language
Features

UCSC - 2014 14
Visual - C++ programming - Support for windows - Portability of code.
C++ environment for MS programming.
5.2 SELECTING LANGUAGES AND
TOOLS
Selecting Languages and Tools
• There's no language suitable for all tasks, and there probably won't ever
be one.
UCSC - 2014 15
• When choosing a programming language, you have to balance

programmer productivity, maintainability, efficiency, portability, tool
support, and software and hardware interfaces.
• Often, one of these factors will shape your decision. In other cases, the
choice depends on the productivity you gain from certain language
features, such as modularity and type checking, or external factors, such
as integrated development environment support.
• Finally, for some tasks, adopting an existing domain-specific language,
building a new one, or using a general-purpose declarative language can
be the right choice.
Coding Practices
• Allow code to be written in a more predictable and
maintainable fashion.
UCSC - 2014 16
• While working code can be written without these

techniques it is rare for such code to be maintainable other
than by the original author.
• There are three main areas to consider;
– Reliability ->Is the software fault free?
Two complementary approaches:
1. Fault avoidance-develop so that errors are not introduced.
2. Fault tolerance-develop so that the program continues when faults
occur.
– Readability ->can be code to be easily maintained.
– Reuse ->can the code be used again.
UCSC - 2014 17
Programming for reliability

• Reliable code is that which conforms to its
specification and continues in operation in all but
most extreme circumstances.
• There are two techniques used to increase the
reliability of code,
1. avoidance and
2. tolerance
UCSC - 2014 18
Programming for reliability

• Following structured programming techniques
leads to code that is less likely to have faults and
is easier to correct.
– Fault avoidance
• Aims to ensure the code has few errors as possible.
– Fault tolerance
• Aims to produce code that will continue to function in
the presence of errors.
• Fault tolerance includes:
– Exception Handling
UCSC - 2014 19
– Defensive programming
– Fault recovery
Exception Handling
• An exception is an error or unexpected event.
Traditional languages, Pascal, C etc. have no specific
support for handling exceptions, newer languages,
Ada, Java, have some in built exception handling.
UCSC - 2014 20
Example:
– Procedure A calls Procedure B
– Procedure B calls Procedure C
– An exception occurs in procedure C
– B cannot continue
– Need to signal exception to A
Exception Handling
• With traditional languages we must resort to setting
error or status variables which can be shared or
passed from procedure to procedure, for example:
UCSC - 2014 21
/* allocate an integer array of SIZE elements

*/ int *intArray = (int *)malloc(SIZE); if
(intArray =» NULL)
{
/* no heap memory available
*/ error - MEMORY_ERROR;
return -1;
}
Still have to unwind the nested function calls.
Exception Handling
With Java exception handling is built into the language
UCSC - 2014 22
Throw exception Catch exception

class counter { class myClass {
int total; // Class definition
int number_values; // public void myMethod {

Counter methods counter counterOne; //
public int Average() Method implementation
{ // Get the average try
if (this.number_values == 0) {
throw new DivideException (), counterOne.Average() ;
else } catch ( DivideException e) {
// division code System.out.println("Division by zero");
} }
} }
}
UCSC - 2014 23
Defensive programming
• Assume that there are faults and inconsistencies in the
system and validate data.
• Example checks are:
– internal data states, for example probabilities between 0 and 1,
money = integer + 2 decimal places etc.
– checksums
– array bounds checking
– division by 0
– pointer validation - check that pointer is allocated and points to a data
structure.
– If any problems occur then the system must recover to a safe state.
UCSC - 2014 24
Fault recovery
• Forward recovery, correct damaged system
state • Error detection and correction of
coded data • File or database recovery •
Backward recovery, restore system to a safe
state • Database transaction roll-back
Programming for readability
• One of the major problems with reviewing and
maintaining code is that the code is unreadable.
UCSC - 2014 25
• A number of straight forward techniques are

available for improving the readability of the code
and therefore reducing review and maintenance
effort.
– Naming conventions
– Data types
– Control constructs
Naming conventions
• It is important on projects of more than one person or on the
development of software applications which are to be
UCSC - 2014 26
maintained (all of them!) that some form of naming

conventions are drawn up at the start of the project.
• The naming conventions would cover such things as program
names, function and procedure names, variable names,
constant names source file names and so on.
• This is important in reducing the effort required for anyone
except the author to read and understand the code.
Naming conventions
• This is true during the development phase, when reviews and
such like are carried out, and during the maintenance phase
UCSC - 2014 27
when the code has to be changed by someone

unfamiliar with it.
• Typically large organizations will have company wide naming
standards which must be followed by all projects.
• As well as following the standards laid down, names should
always be meaningful, for example the name of a function
should reflect the purpose of the function.
Naming conventions
• Example naming conventions for the 'C' language might be:
1. All constant names are in upper case and begin C, for example
C_SPEED_OF_LIGHT
UCSC - 2014 28
2. All variable names are in mixed case with each word

beginning with a capital, variable names may be prefixed with a
lower case letter indicating the type of the variable, i for int, l for
long etc., for example, int iCurrentTime;
3. All variable names should reflect the use of the variable, i.e. it
should describe the real world object represented.
for example;
List UnknownWordList; // Good
List u_list; // Bad
Loop indexes can use i, j etc.
Naming conventions
• Example naming conventions for the 'C' language might be:
UCSC - 2014 29
4. Function and procedure names are in mixed case with

each word beginning with a capital, function names may be
prefixed with a lower case letter indicating the return type of the
function, i for int, v for void etc., for example,
void vCalculateTotal(List SubTotalList) {
}
5. Function and procedure names must describe the purpose of the
function or procedure.
6. Source code file names must reflect the contents of the file for
example,
CalculateTotal.c - contains the function CalculateTotal
UCSC - 2014 30
Data types
• Use abstract data types to make the code
clearer.
Example:
Type TrafficLightColour is (red, amber, green);
ColourShowing, NextColour: TrafficLightColour;
UCSC - 2014 31
Control constructs
• Use the standard flow control constructs for
structured programming, sequence, selection
and iteration, flow should be from the top of
the program down.
• Loops, decision statements, routines etc.
should all have single entry and exit points,
avoid gotos, breaks,exits etc.
• Functions should have a single return.
UCSC - 2014 32
Control constructs
• Keep code simple - one possible complexity heuristic
is;
1. Start with 1 for the straight path through the routine
2. Add 1 for each control keyword, if, while, repeat, and, or
etc.
3. Add 1 for each keyword in a case. If the case does not have
a default it should.
– given the above total then judge the complexity as follows:

• 1-5 Routine probably ok
• 6-10 May need some re-design and/or simplification
• >10 Too complex, redesign required.
UCSC - 2014 33
– In addition to the above the amount of data, number of

lines etc.
could be taken into account.
Technical considerations
• Environment
– the language should support the features of the environment in which
the application is to run, for example if the application is to run on the
Windows operating system then the programming language and
development tools should help to reduce the effort required to
produce the user interface, that is use Visual C++ or Borland C++
rather than a basic C compiler and the Windows SDK.
• Language support
UCSC - 2014 34
– the language selected must have good support within the

environment on which development will take place and in which the
application will run. It is much easier to develop mainframe data
processing applications in COBOL or some 4GL rather than 'C' or Ada.
Technical considerations
• Performance
– applications which have critical speed and size performance
requirements cannot usually be built using an interpreted language
such as Basic or a language which requires a complex run time system
such as Smalltalk or Java as the overhead in the run time system is too
great.
• Safety / security
UCSC - 2014 35
– safety critical and secure applications usually require a

programming language which supports these requirements. Thus a
nuclear power station control system might be written in Ada rather
than 'C'.
• Interfaces to other systems

– if the application must interface to other systems then these may
restrict the languages which can be used.
Non-technical considerations
Here we must look at the project as a whole and the business
objectives of the organization. It should be noted that these
considerations are typically more important than the purely
technical factors.
UCSC - 2014 36
• Timescales
– the project timescales may restrict the choice of languages, for
example selecting a language known by the programmers will reduce
timescales, or help to meet timescales.
• Maintenance
– if the application is to be passed on to a maintenance team then the
skills of the maintenance team and the nature of the other
applications being maintained may have a bearing on the language
chosen. Do you want to have to re-train the maintenance staff?
• Other applications
UCSC - 2014 37
– if all other applications built and maintained by the

organization are written in COBOL, for example, then there is a very
strong argument for building new applications in COBOL.
• Available tools
– what compilers, debuggers are currently available in the workplace?
Buying new software to support the development may increase the
development costs significantly.
• Risk
– adopting new technology always carries an associated risk, on a
project which is critical to the business such risks may be
unacceptable.
• Morale
UCSC - 2014 38
– programmers love to use the latest technology, on a non-

critical project it may be beneficial to use an innovative approach to
development to retain the interest of the staff, for example Java could
be used to develop some small in-house utility. This has the added
advantage of bringing new technical knowledge into the organization.
5.3 GOOD PROGRAMMING

PRACTICES
UCSC - 2014 39
Good Programming Practices

Before you write one line of code, be sure you:
– Understand the problem you’re trying to solve
– Understand basic design principles and concepts
– Pick a programming language that meets the needs of
the software to be built and the environment in which
it will operate
– Select a programming environment that provides tools
that will make your work easier
– Create a set of unit tests that will be applied once the
component you code is completed
UCSC - 2014 40
Good Programming Practices

As you begin writing code, be sure you:
– Constrain your algorithms by following structured programming
language
– Select data structures that will meet the needs of the design
– Understand the software architecture and create interfaces that are
consistent with it
– Keep conditional logic as simple as possible
– Create nested loops in a way that makes them easily testable
– Select meaningful variable names and follow other local coding
standards
– Write code that is self-documenting
UCSC - 2014 41
– Create visual layout that aids understanding
Code Reviews
• A code review is also called technical review.
• The code review for a module is carried out after the
module is successfully compiled and all the syntax
errors eliminated.
UCSC - 2014 42
• These are extremely cost effective strategies

for reduction in coding error in order to produce
high quality code.
• In a review, a work product is examined for defects
by individuals other than the person who produced
it.
Code Reviews
• A work product is any important deliverable created
during the requirements, design, coding, or testing
phase of software development.
UCSC - 2014 43
– Examples of work products are phase plans,

requirements models, requirements and design
specifications, user interface prototypes, source code,
architectural models, user documentation, and test
scripts.
• Reviews can be conducted by individuals or group
• There are two types of code reviews;
1. Code walk-throughs
2. Code inspection.
UCSC - 2014 44
Code Reviews
• Code reviews can often find and remove
common vulnerabilities such as format string
exploits, race conditions, memory leaks and
buffer overflows, thereby improving software
security.
• Improve the quality of the code being
reviewed • Improve programmers
UCSC - 2014 45
Code Reviews
• A code review is not a meeting to;
– negatively criticize someone else's code
– criticize architecture or design (unless it is an
architectural or design review)
– criticize a colleague
– determine whether someone is to be removed
from a project or not
UCSC - 2014 46
– determine whether someone is

performing up to standard
Code Walkthrough
• Objectives of Code Walkthrough are;
– To discover algorithmic and logical errors in the
code.
– To consider alternative implementations
UCSC - 2014 47
– To ensure compliance to standards &
specifications
Code Walkthrough
• This an informal code analysis technique. In this
technique when a module has been coded, it is
compiled and eliminate all syntax errors.
UCSC - 2014 48
• Some members of the development team

are given the code few days before the walkthrough
meeting to read and understand the code.
• Each member selects some test cases and simulates
the execution of the code by hand.
• The team performing the code walkthrough consists
of 3-7 members
Code Inspection
• Software maintenance is the general process of
changing a system after it is diverted.
UCSC - 2014 49
• This change includes corrections of coding

errors, design errors, specification errors or
accommodation of new requirements.
• There are three types of software maintenance:
1. repair software faults
2. adapt the software to a different operating system
3. add or modify the system’s functionality
Code Inspection
• Errors detected during code inspection;
– Use of uninitialized variables
UCSC - 2014 50
– Jumps in to loops
– Non terminating loops
– Incompatible assignments
– Array indices out of bounds
– Improper storage allocation and deallocation
– Mismatches between actual and formal parameters in
procedure calls
– Improper modification of loops
UCSC - 2014 51
Software Engineering
(Compulsory)
UCSC - 2014 52
Software
Engineering
Software Testing and Quality

Assurance
Duration: 8 hours
UCSC - 2014 53
Learning Objectives
• State the software testing process and required
documentation
• Explain the different software testing techniques and
integration strategies
• Design test cases and write test programs for a given simple
software problem
• Describe the code verification techniques
• Describe the importance of software quality
• Distinguish the difference between product quality and
process quality
UCSC - 2014 54
• Describe some important quality standards with

respect to software
Detailed Syllabus
6.1 Verification and Validation
6.2 Techniques of testing
6.2.1 Black-box and White-box testing
6.2.2 Inspections
6.3 Levels of testing
6.3.1 Unit testing
6.3.2 Integration Testing
6.3.3 Interface testing
6.3.4 System testing
UCSC - 2014 55
6.3.5 Alpha and beta testing
Detailed Syllabus
6.3 Levels of testing
6.3.6 Regression testing
6.3.7 Back-to-back testing and Thread testing
6.3.8 Statistical Software Testing
6.3.9 Object Oriented Testing
6.4 Design of test cases
6.5 Quality management activities
6.6 Product and process quality
6.7 Standards
UCSC - 2014 56
6.7.1 ISO9000
6.7.2 Capability Maturity Model (CMM)
6.1 VERIFICATION AND

VALIDATION
UCSC - 2014 57
Validation and Verification

• Validation and Verification ( V & V ) is the name given to
the checking and analysis processes that ensure that
software conforms to its specification and meets the needs
of the customers who are paying for the software.
• V & V is a whole life-cycle process. It starts with
requirements reviews and continues through design reviews
and code inspections to product testing. There should be V&
V activities at each stage of software process.
• Validation: Are we building the right product?
UCSC - 2014 58
• Verification: Are we building the product right?
Validation and Verification

• Within the V & V process, two techniques of system checking and analysis
may be used:
1. Software Inspections
– Analyze and check system representations such as the requirements
documents, design diagrams and program source code. They may be applied
at all stages of the development process. Inspections may be supplemented
by some automated analysis of the source text of a system or associated
documents. Software inspections and automated analysis are static V & V
techniques as they do not require the system to be executed.
2. Software Testing
– Involves executing an implementation of the software with test data and
examining the outputs of the software and its operational behavior to check
UCSC - 2014 59
that it is performing as required. Testing is a dynamic technique

of V & V because it works with an executable representation of the system.
Software Testing Procedure

• Testing procedures should be established at the start of any software
project. All testing carried out should be based on a test plan, this should
detail which tests are to be carried out.
• For each test, the following information should be included in the test
plan:
– the pre-requisites for the test.
– the steps required to carry out the test.
– the expected results of the test.
• The outcome of any tests should be recorded in a test results document

that include whether the test succeeded or failed and a description of the
UCSC - 2014 60
failure. Test results for all passes through the test plan must
be recorded to allow accurate records to be kept of where problems
occur and when they were identified and corrected.
Testing Process
1. Run the tests as defined by the test plan.
Note: Testing should not stop when the first problem is encountered,
unless it is so severe that the rest of the tests would be meaningless.
Rather all testing in the test plan should be carried out and then the
errors addressed.
2. Record the outcome of each test in the test report, both success
and failure should be reported. For failed tests the nature of the
UCSC - 2014 61
problem should be described in sufficient detail to allow it to

be corrected and to allow analysis of the types of errors being found.
3. Correct the errors that were documented from the test run.
4. Repeat the process until no errors are identified or error rate is
sufficiently low. If the error rate is low then it may be sufficient to simply
re-test the failed errors. If the error rate is high then all tests should be
re-run.
Dynamic & Static Verification

• Dynamic verification
– Concerned with exercising and observing
product behavior (testing)
• includes executing the code
UCSC - 2014 62
• Static verification
– Concerned with analysis of the static system
representation to discover problems
• does not include execution
UCSC - 2014 63
Dynamic testing process
UCSC - 2014 64
Unit Testing
UCSC - 2014 65
Sub-System
Testing in the project lifecycle
UCSC - 2014 66
UCSC - 2014 67
6.2 TECHNIQUES OF TESTING
Black-box Testing
• Approach to testing where the program is considered as a
‘black-box’
• The program test cases are based on the system
specification
UCSC - 2014 68
• Inputs from test data may reveal anomalous

outputs, i.e.
defects
• Test planning can begin early in the software process
• Main problem - selection of inputs
– equivalence partitioning
UCSC - 2014 69
Black-box Testing
UCSC - 2014 70
UCSC - 2014 71
White-box Testing
• Sometimes called Structural testing or glass box testing
• Derivation of test cases according to program structure.
• Knowledge of the program used to identify additional test
cases
• Objective is to exercise all program statements (not all path
combinations)
UCSC - 2014 72
UCSC - 2014 73
Structural testing
UCSC - 2014 74
UCSC - 2014 75
Software Inspection
• Inspection techniques include,
– Program inspections
– Automated source code analysis
– Formal verification
• Can only check the correspondence between a
program and its specification (verification)
• Unable to demonstrate that the software is
operationally useful.
UCSC - 2014 76
• Can not check non-functional requirements

(performance, reliability)
Software Inspection
• Inspections not require execution of a system so
may be used before implementation.
• They have been shown to be an effective
technique for discovering program errors.
– Many different defects may be discovered in a single
inspection. In testing, one defect may mask another, so
several executions are required.
UCSC - 2014 77
– The reuse domain and programming

knowledge so reviewers are likely to have seen the
types of error that commonly arise.
Program Inspections
• Formalized approach to document reviews
• Intended explicitly for defect detection (not
correction).
• Defects may be logical errors, anomalies in
the code that might indicate an erroneous
UCSC - 2014 78
condition (e.g. an uninitialized

variable) or non-compliance with standards.
Inspection Roles
Inspector Role
Programmer or The programmer or designer responsible for producing the
Designer program or document. Responsible for fixing defects
discovered during the inspection process.
Inspector Finds errors, omissions and inconsistencies in programs and
documents. May also identify broader issues that are
outside the scope of the inspection team.
Reader Presents the code or document at an inspection meeting.
Scribe Records the results of the inspection meeting.
UCSC - 2014 79
Chairman or Manages the process and facilitates the inspection.

Reports Moderator process results to the Chief moderator.
Chief moderator Responsible for inspection process improvements, checklist
updating, standards development etc.
Inspection Pre-conditions
• A precise specification must be available.
• Team members must be familiar with the
organization standards.
• Syntactically correct code or other system
representations must be available.
• An error checklist should be prepared.
UCSC - 2014 80
• Management must accept that inspection

will increase costs early in the software process.
• Management should not use inspections for staff
appraisal i.e. finding out who makes mistakes.
UCSC - 2014 81
The Inspection Process
UCSC - 2014 82
UCSC - 2014 83
The Inspection Process

• System overview presented to inspection team.
• Code and associated documents are distributed to
inspection team in advance.
• Inspection takes place and discovered errors are
noted.
• Modifications are made to repair discovered
errors.
• Re-inspection may or may not be required.
UCSC - 2014 84
Inspection Checks
Data faults Are all program variables initialized before their values are used?
Have all constants been named? Should the upper bound of
arrays be equal to the size of the array or Size -1? If character
strings are used, is a delimiter explicitly assigned? Is there any
possibility of buffer overflow?
Control faults For each conditional statement, is the condition correct? Is each
loop certain to terminate? Are compound statements correctly
bracketed? In case statements, are all possible cases accounted
for? If a break is required after each case in case statements, has
it been included?
Input/output faults Are all input variables used? Are all output variables assigned a
value before they are output? Can unexpected inputs cause
corruption?
UCSC - 2014 85
Inspection Checks
UCSC - 2014 86
Interface faults Do all function and method calls have the correct number of
parameters? Do formal and actual parameter types match? Are
the parameters in the right order? If components access shared
UCSC - 2014 memory, do they have the same model of the shared memory87
6.3 LEVELS OF TESTING
UCSC - 2014 88
Test Phases
UCSC - 2014 89
Test Phase Test Plan Author Technique Run by
Unit Test Code design Designer White box, Black Programmer

UCSC - 2014 box, 90
Test Phases
UCSC - 2014 91
Test Phase Test Plan Author Technique Run by
Acceptance Requirements Analyst / Black box Analyst /

Test
UCSC - 2014 Customer Customer 92
Unit Testing
• Unit Testing is carried out as a part of the coding
task. This phase is based on the design of the
software for a piece of code. Unit testing should
prove the following about the code
– Robust –the code should not fail under any
circumstances.
– Functionally correct –the code should carry out the task
defined by the code design.
– Correct interface –the inputs and outputs from the
code should be as defined in the design.
UCSC - 2014 93
Unit Test Plan

• The unit test plan must be based on the design of
the code and not the code itself. Therefore, the test
plan will be written after the completion of design
but before the start of the coding phase.
• The test plan is the responsibility of the designer of
the code. The testing is usually carried out by the
author of the code.
UCSC - 2014 94
Integration/Sub-systems Testing
• Integration Testing is carried out after the separate
software modules have been unit testing.
Integration testing is based on the functional
specification of the software. Integration testing
should prove the following about the software:
– Integration -the modules of the system should interact
as designed.
– Functionally correct -the system should behave as
defined in the functional specification.
UCSC - 2014 95
Integration test plan

• This is based on the specification of the
system. The test plan is usually written by the
authors of the system specification to avoid
any assumptions made during design from
being incorporated into the test plan.
Incremental Integration Testing
Initially, integrate a minimal system configuration and test the system. Then
add components to this minimal configuration and test after each added
increment.
UCSC - 2014 96
T1,T2 and T3 tests are carried out after integration of components A and B. If
the tests are successful, add C and carry out tests T1,T2,T3 and T4. If new
errors introduced, that is due to the integration of C.
UCSC - 2014 97
Top-Down Integration Testing

• In top-down integration, the high-level components of a system are
integrated and tested before design and implementation of some of the
high-level components has been completed.
UCSC - 2014 98
Bottom-up Integration Testing

• Low-level components are integrated and tested before the higher-level
components have been developed.
UCSC - 2014 99
Interface Testing
• Interface testing takes place when modules or subsystems
are integrated to create large systems.
• Each module or sub-system has a defined interface which is
called by other program components.
• Objectives are to detect faults due to interface errors or
invalid assumptions about interfaces.
• Particularly important for object-oriented development as
objects are defined by their interfaces.
• Cannot be detected by testing the individual objects.
– The errors will occur due to the interaction between objects.
UCSC - 2014 100

Types of Interfaces
• Parameter Interfaces
– These are interfaces where the data or sometimes function references are
passed from one component to another.
• Shared memory Interfaces
– These are interfaces where block of memory is shared between sub-systems.
Data is placed in memory by one sub-system and retrieved from there by
other sub-system.
• Message passing Interfaces
– These are interfaces where one subsystem request a service from another
sub-system by passing a message to it.
UCSC - 2014 101

• Procedural Interfaces
– These are interfaces where one sub-system encapsulates a set of procedures
which can be called by other subsystem. Objects and abstract data types
have this form of interface.
System Testing
• System testing is carried out at the completion
of the integration testing. The purpose of
system testing is to prove that the software
meets the agreed user requirements and
works in the target environment. System
UCSC - 2014 102

testing covers both functional and

nonfunctional requirements.
System Test Plan
• The system test plan is based around the agreed requirements. Test
plan covers functional requirements and non-functional requirements
such as performance. The system test plan is written by the author of the
requirements document to avoid assumption introduced during
specification.
• The system test plan will also include tests to cover
– Recovery – Force the system to crash and then try to recover to a sensible
state.
– Security – Attempt to access the system without the correct authority, or
attempt to carry out restricted functions.
UCSC - 2014 103

– Stress – Attempt to break the system by overloading it.

– Performance – Ensure the system meets the performance requirements.
Acceptance Testing
• Acceptance testing is carried out at the
customers site with the customer in
attendance. The purpose of the acceptance
test is to show to the customer that the
software does indeed work. These tests are
usually a sub set of the system test.
UCSC - 2014 104

Acceptance test plan

• This should be agreed with the customer after
the requirements for the software have been
agreed. Sometimes the customer will write
the test plan in which case it must be agreed
with the software developers.
Alpha Testing
• Alpha testing is the first real use of the
software product. Having completed system
UCSC - 2014 105

testing the product will be given to a

small number of selected customers or
possible just distributed within the company
itself. The software will be used ‘in anger’ and
errors reported to the development and
maintenance team.
Beta Testing
• After alpha testing has been completed and
any changes made a new version of the
UCSC - 2014 106

product will be released to much wider

audience. The objective of Beta testing is to
iron out the remaining problems with the
product before it is put on the general
release.
Regression Testing
• Regression testing carried out after any changes
are made to a software application. The purpose of
regression test is to prove that the change has been
UCSC - 2014 107

made correctly and that the change has not

introduced any new errors.
• Regression test plans are usually a sub-set of the
integration or systems test plans. It is designed to
cover enough functionality to give confidence that
the change has not effected any other part of the
system.
Back-to-back testing
• Back-to-back testing means that multiple
versions of the software are executed on the
UCSC - 2014 108

same test data. If they all agree on the

answer, it is assumed that they are all correct.
Thread testing
• Based on testing an operation which involves a
sequence of processing steps which thread their
way through the system
UCSC - 2014 109

• Start with single event threads then go

on to multiple event threads
– Advantages
• Suitable for real-time and object-oriented systems
– Disadvantage
• Difficult to assess test adequacy, because of large number of event
combinations
Statistical Software Testing

• Statistical testing involves exercising a program
with generated random inputs, the test profile and
the number of generated inputs being determined
UCSC - 2014 110

according to criteria based on program

structure or software functionality.
• In case of complex programs, the probabilistic
generation must be based on a black box analysis,
the adopted criteria being defined from behavior
models deduced from the specification.
Object Oriented Testing

In an object oriented system, four levels of testing can be identified:
1. Testing the individual operations associated with objects – These
are functions or procedures and the black-box and white-box
approaches may be used.
UCSC - 2014 111

2. Testing individual object classes – The principle of

black-box testing is unchanged but the notion of an equivalence class
must be extended to cover related operation sequences.
3. Testing clusters of objects – Strict top-down or bottom-up
integration may be inappropriate to create groups of related objects.
Other approaches such as scenario based testing should be used.
4. Testing the object oriented system – V & V against the systems
requirements specification is carried out in exactly the same way as for
any other type of system.
Object Class Testing

• When testing objects, complete test coverage should
include:
UCSC - 2014 112

1. the testing in isolation of all operations

associated with the object;
2. the setting and interrogation of all attributes
associated with the object;
3. the exercise of the object in all possible states. This
means that all events that cause a state change in the
object should be simulated.
Object Integration
• In object oriented systems, there is no obvious
‘top’ that provides for the integration nor is there a
clear hierarchy of objects that can be created.
UCSC - 2014 113

• Clusters therefore have to be created using

knowledge of there operation and the features of
the system that are implemented by these clusters.
Object Integration
• There are three possible approaches to integration
testing that may be used:
1. Use-case or scenario-based testing – Testing can be based on
the scenario descriptions and object clusters created to support the
usecases that relate to that mode of use.
2. Thread testing – Thread testing is based on testing the
system’s response to a particular input or set of input events.
UCSC - 2014 114

3. Object interaction testing – An intermediate level

of integration testing can be based on identifying ‘method –
message ‘ paths. These are traces through a sequence of object
interactions which stop when an object operation does not call on
the services of any other object.
6.4 DESIGN OF TEST CASES
UCSC - 2014 115

Design of Test Cases

• Test case design is a part of system and
component testing.
• The objective of the test case designing
process is to develop test cases.
• These test cases are used to detect program
defects and also it detects whether the
system meets its requirements.
UCSC - 2014 116

Design of Test Cases

• When designing a test case,
– select a particular feature of the system.
– Select set of inputs that execute that feature.
– Decide possible outputs of the test case.
– Check the difference between actual and the
expected out comes after the testing procedure.
UCSC - 2014 117

Test case designing approaches

• Requirements-based testing -Test cases are designed to
test the system requirements. Mostly used at the system
testing stage. Test cases should be created for each
requirement to verify that the system meets requirements.
• Partition testing - Identify input and output partitions. The
system execute inputs from all partitions.
• Structural testing - Use the knowledge of program
structure to design tests that exercise all parts of the
program. When testing a program, each statement should be
execute at least once.
UCSC - 2014 118

6.5 QUALITY MANAGEMENT

ACTIVITIES
Quality Management
• Software quality management can be structured into three
principal activities:
UCSC - 2014 119

1. Quality assurance
• The establishment of a framework of organizational procedures and
standards which lead to high quality software.
2. Quality planning
• The selection of appropriate procedures and standards from this
framework and adaptation of these for a specific software project.
3. Quality control
• The definition and enactment of processes which ensure that the project
quality procedures and standards are followed by the software
development team.
Software Quality Management

• Quality management provides an independent check on the
software development process. The deliverables from the
software process are input to the quality management
UCSC - 2014 120

process and are checked to ensure that they are

consistent with organizational standards and goals.
• Quality management should be separated from project
management so that quality is not compromised by
management responsibilities for project budget and
schedule.
• An independent team should responsible for quality
management and should report to the management above
the project management level.
Software Quality Management

• There must be a management commitment to quality.
UCSC - 2014 121

• Concerned with ensuring that the required level of

quality is achieved in a software product.
• Involves defining appropriate quality standards and
procedures and ensuring that these are followed.
• Should aim to develop a ‘quality culture’ where quality is
seen as everyone’s responsibility.
What is Quality?
• Quality, simplistically, means that a product should
meet its specification.
• This is problematical for software systems
UCSC - 2014 122

– There is a tension between customer quality

requirements
(efficiency, reliability, etc.) and developer quality
requirements (maintainability, reusability, etc.);
– Some quality requirements are difficult to specify in an
unambiguous way;
– Software specifications are usually incomplete and
often inconsistent.
What is Quality?
• Traditional view
UCSC - 2014 123

– quality is about perfection/bug free code.

Generally associated with testing at the end of
development. Testing cannot introduce quality to a
product, it can only reduce the number of defects in the
product.
• Modern view (ISO 9000)
– Good quality is not perfection but fit for the purpose.
Build the right product in the right way. Do not over
engineer (too expensive). Do not under engineer (not fit
for the purpose).
UCSC - 2014 124

Scope of Quality Management

• Quality management is particularly
important for large, complex systems. The
quality documentation is a record of progress
and supports continuity of development as
the development team changes.
• For smaller systems, quality management
needs less documentation and should focus
on establishing a quality culture.
UCSC - 2014 125

Quality Management Activities

• Quality assurance
– Establish organizational procedures and standards for quality.
• Quality planning
– Select applicable procedures and standards for a particular project
and modify these as required.
• Quality control
– Ensure that procedures and standards are followed by the software
development team.
Quality management should be separate from project

management to ensure independence.
UCSC - 2014 126

Quality Management and Software

Development
UCSC - 2014 127

Standards & Quality plan Quality review reports procedures

6.6 PRODUCT AND PROCESS
QUALITY
UCSC - 2014 128

Process and Product Quality

• The quality of a developed product is
influenced by the quality of the production
process.
• This is important in software development
as some product quality attributes are hard to
assess.
UCSC - 2014 129

• However, there is a very complex and

poorly understood relationship between
software processes and product quality.
Process-based Quality
• There is a straightforward link between process
and product in manufactured goods.
• More complex for software because:
– The application of individual skills and experience is
particularly important in software development;
UCSC - 2014 130

– External factors such as the novelty of an

application or the need for an accelerated development
schedule may impair product quality.
• Care must be taken not to impose inappropriate
process standards - these could reduce rather than
improve the product quality.
UCSC - 2014 131

Process-based Quality
UCSC - 2014 132

Practical Process Quality

• Define process standards such as how reviews
should be conducted, configuration management,
etc.
• Monitor the development process to ensure that
standards are being followed.
• Report on the process to project management and
software procurer.
• Don’t use inappropriate practices simply because
standards have been established.
UCSC - 2014 133

6.7 STANDARDS
Quality Assurance and Standards

• Quality assurance(QA) activities define a framework for achieving
software quality.
• There are two types of standards that may be established as a part of
the quality assurance process:
• Product standards
– These are standards that apply to the software product being developed.
They include standards such as document standards (eg. Specification of a
UCSC - 2014 134

class), coding standards and user interface standards. Product

quality includes reusability, usability, portability, maintainability etc.
• Process standards
– These are standards that define the processes which should be followed
during software development. They may include definitions of specification,
design and validation processes and a description of the documents which
must be generated in the course of these processes.
Importance of Standards
• Encapsulation of best practice
– avoids repetition of past mistakes.
UCSC - 2014 135

• They are a framework for quality

assurance processes
– they involve checking compliance to standards.
• They provide continuity
– new staff can understand the organization by
understanding the standards that are used.
UCSC - 2014 136

Product and Process Standards
UCSC - 2014 137

Product standards Process standards

Design review form Design review conduct
UCSC - 2014 138
Requirements document structure Submission of documents to CM
Problems with Standards

• They may not be seen as relevant and up-
todate by software engineers.
• They often involve too much bureaucratic
form filling.
• If they are unsupported by software tools,
tedious manual work is often involved to
maintain the documentation associated with
the standards.
UCSC - 2014 139

ISO9000
• ISO9000 is a set of international standards that can be
applied to a range of organizations from manufacturing
through to service industries.
• ISO9001 is the most general of these standards and applies
to organizations concerned with quality processes regarding
design, development and maintain products. This is a generic
model of a quality process which describes various aspects of
that process and defines which standards and procedures
could exist within an organization.
• ISO 9000-3 interprets ISO 9000 for software development.
UCSC - 2014 140

ISO9000
• ISO900-1 is a general guideline which gives background
information about the family of standards.
• ISO9002 and ISO9003 are subsets of ISO9001.
• ISO9002 is used for situations in which there is no design.
• ISO9003 is used for situations in which there is neither
design nor production (eg. Retail).
• ISO9000-3 is a guideline on how to use ISO9001 for
software development.
UCSC - 2014 141

ISO9000
• When asked whether cost, timescale or quality was most important
when completing against another company for a software project Tomoo
Mastubara of Hitachi Software Engineering replied
“Quality is first! Always first. If we deliver bad quality to the customer,
the customer will complain many times, over and over. But if we are
late, he will complain only once and then may be he will forget. And if
we have underestimated the cost, the customer will not complain at
all. – for he will know we have made the mistake. WE will bear the
burden of the cost mistake”
• Any serious quality initiative will repay any set-up costs within the first
years through improved productivity and customer satisfaction.
UCSC - 2014 142

ISO9000 and Quality Management
UCSC - 2014 143

UCSC - 2014 144

Documentation Standards
• Documentation standards in a software project are
particularly important as documents are the only tangible
way of representing the software and the software
process.
• There are three types of documentation standards

1. Documentation Process Standards
• Define the process which should be followed for document production.
2. Document Standards
• Govern the structure and presentation of documents.
3. Document Interchange Standards
UCSC - 2014 145

• Ensure that all electronic copies of documents are compatible.
UCSC - 2014 146

A document production process including quality

checks
UCSC - 2014 147

Incorporate
Create initial Re-draft
Review draft review
UCSC - 2014 draft document 148
Comments
Capability Maturity Model (CMM)

• CMM was developed at the Software
Engineering Institute (SEI) in Pittsburgh, and it
is very much a rival to ISO9001 for software.
• CMM Is a scheme to classify a software
development organization according to its
capability. CMM identifies five different
maturity levels for software developing
organizations.
UCSC - 2014 149

Capability Maturity Model (CMM)

1. Initial - The software development is run informally, and depends
on the competence of some persons.
2. Repeatable - There is a common system for project management
and control.
3. Defined - There is a common system for the software engineering
activities.
4. Managed - The software development process is stable and gives a
consistent product quality. Measurements are used to keep the process
and product under control.
5. Optimizing - The software development process contain its own
improvement process. Process improvement is budgeted and planned
and is an integral part of the organization’s process.
UCSC - 2014 150

Key Points
• Software quality management is concerned with
ensuring that software has a low number of
defects and that it reaches the required standards
of maintainability, reliability, portability and so on
• SQM includes defining standards for processes
and products and establishing processes to check
that these standards have been followed
UCSC - 2014 151

Key Points
• Software standards are important for quality
assurance as they represent an identification of
‘best practice’
• Quality management procedures may be
documented in an organizational quality manual,
based on the generic model for a quality manual
suggested in the ISO 9001 standard
UCSC - 2014 152

• Product quality metrics are particularly

useful for highlighting anomalous components that
may have quality problems
UCSC - 2014 153

Software Engineering 3 Coding Testing PDF

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

Software Engineering 3 Coding Testing PDF

Uploaded by

Copyright:

Available Formats

IT3205: Fundamentals of

IT3205: Fundamentals of Software

5.2 Selecting languages and tools

5.3 Good programming practices

What is Coding (Implementation)?

• Transforms the design specification to source code that can

What is Coding (Implementation)?

• Although design quality should not be compromised because

• Time spent in coding is a small percentage of the

LANGUAGES AND DEVELOPMENT

Language Features Strengths Weaknesses

5.2 SELECTING LANGUAGES AND

• When choosing a programming language, you have to balance

• While working code can be written without these

Programming for reliability

Programming for reliability

/* allocate an integer array of SIZE elements

Still have to unwind the nested function calls.

Throw exception Catch exception

int number_values; // public void myMethod {

• A number of straight forward techniques are

maintained (all of them!) that some form of naming

when the code has to be changed by someone

2. All variable names are in mixed case with each word

4. Function and procedure names are in mixed case with

– given the above total then judge the complexity as follows:

• 6-10 May need some re-design and/or simplification

• >10 Too complex, redesign required.

– In addition to the above the amount of data, number of

– the language selected must have good support within the

– safety critical and secure applications usually require a

• Interfaces to other systems

– if all other applications built and maintained by the

– programmers love to use the latest technology, on a non-

5.3 GOOD PROGRAMMING

Good Programming Practices

Good Programming Practices

– Create visual layout that aids understanding

• These are extremely cost effective strategies

– Examples of work products are phase plans,

– determine whether someone is

– To ensure compliance to standards &

• Some members of the development team

• This change includes corrections of coding

Software Testing and Quality

• Describe some important quality standards with

6.3.5 Alpha and beta testing

6.1 VERIFICATION AND

Validation and Verification

• Validation: Are we building the right product?

• Verification: Are we building the product right?

Validation and Verification

that it is performing as required. Testing is a dynamic technique

Software Testing Procedure

• The outcome of any tests should be recorded in a test results document

problem should be described in sufficient detail to allow it to

Dynamic & Static Verification

Dynamic testing process

Testing in the project lifecycle

6.2 TECHNIQUES OF TESTING

• Inputs from test data may reveal anomalous

• Can not check non-functional requirements

– The reuse domain and programming