Chapter SIX

Implementation, Testing and Pragmatics

Making it a reality
 Topics
 Documentation
 Coding, Testing and inspection
 Others
 Installation
 Training
 Maintenance

2
 Introduction
 Pragmatics concerned with how the system
design process we have done so far would be
linked to the reality or how it is would give sense
or meaning to the stakeholders.
 These issues will cover Coding, testing along with
documentation and object oriented benefit
realization.

3
 Documentation

4
 Documentation
 There are various types of documentations required in
object oriented Software engineering
 System Documentation: detailed information about a system’s
design specifications, its inner workings, and its functionality.
 User Documentation: written or other visual information about
an application system, how it works, and how to use it. User
documentation is often in the form of online help, sometimes with
Web connections for further information.

5
 Cont…
 The system documentation can be for internal or
external to the system being developed.
 Internal System Documentation: comments in source code, generated
during the coding process or automatically by software compilers or
documenters are internal to the system.
 External System Documentation: outcomes of all diagrams,
including use cases, design classes, activity and sequence
diagrams, etc are categorized under this sub category.

6
 Coding and Testing

7
 Coding
 Translating the design specification in to a working system (a
reality)
 Two important issues
 Coding style
 To make readable and maintainable
 Adding as much comments as possible, use combination of
uppercase and lower case in naming …
 Programming language selection
 A language that supports features required
 For a web based applications vs window based

8
 Software Testing
Testing is the process of exercising a
A software/program with the specific intent
of finding errors prior to delivery to the end
user.

Testing is Verification and Validation

“Are we building the right system?”
“Are we building the system right ?”
What Testing Shows
errors

requirements conformance

performance

an indication
of quality
 Who Tests the Software?

developer independent tester

Understands the system Must learn about the system,
but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality
 Cont…
 A failure is an unacceptable behaviour exhibited by a system
 The frequency of failures measures the reliability
 An important design objective is to achieve a very low failure rate and hence
high reliability.
 A failure can result from a violation of an explicit or implicit requirement

 A defect is a flaw in any aspect of the system that contributes, or may potentially
contribute, to the occurrence of one or more failures
 could be in the requirements, the design and the code
 It might take several defects to cause a particular failure

 An error is a slip-up or inappropriate decision by a software developer that leads to

the introduction of a defect

12
 Effective and Efficient Testing
 To test effectively, you must use a strategy that uncovers as
many defects as possible.
 To test efficiently, you must find the largest possible number
of defects using the fewest possible tests
 Testing is like detective work:
 The tester must try to understand how programmers and designers think,
so as to better find defects.
 The tester must not leave anything uncovered, and must be suspicious of
everything.
 It does not pay to take an excessive amount of time; tester has to be
efficient.

13
Software Testing

white-box black-box
methods methods

Methods

Strategies
 White-Box Testing

... our goal is to ensure that all

statements and conditions have
been executed at least once ...
 Cont…
 Also called ‘Glass-box testing’ or ‘structural’ testing
 Testers have access to the system design
 They can
 Examine the design documents
 View the code
 Observe at run time the steps taken by algorithms and their internal data
 Individual programmers often informally employ glass-box
testing to verify their own code

16
Black-Box Testing

requirements

output

input events
 Cont…
 Testers provide the system with inputs and observe the
outputs
 They can see none of:
 The source code
 The internal data
 Any of the design documentation describing the system’s internals

18
 Writing Formal Test Cases and Test
Plans
 A test case is an explicit set of instructions designed to detect
a particular class of defect in a software system.
 A test case can give rise to many tests.
 Each test is a particular running of the test case on a particular
version of the system.

19
 Test plans
 A test plan is a document that contains a complete set of test cases for a system
 Along with other information about the testing process.
 The test plan is one of the standard forms of documentation.
 If a project does not have a test plan:
 Testing will inevitably be done in an ad-hoc manner.
 Leading to poor quality software.
 The test plan should be written long before the testing starts.
 You can start to develop the test plan once you have developed the
requirements.

20
 Information to include in a formal test
case
A. Identification and classification:
 Each test case should have a number, and may also be given a descriptive title.
 The system, subsystem or module being tested should also be clearly indicated.
 The importance of the test case should be indicated.
B. Instructions:
 Tell the tester exactly what to do.
 The tester should not normally have to refer to any documentation in order to execute
the instructions.
C. Expected result:
 Tells the tester what the system should do in response to the instructions.
 The tester reports a failure if the expected result is not encountered.
D. Cleanup (when needed):
 Tells the tester how to make the system go ‘back to normal’ or shut down after the test.

21
 The roles of people involved in testing
 The first pass of unit and integration testing is called developer
testing.
 Preliminary testing performed by the software developers who do the
design.

 Independent testing is performed by a separate group.

 They do not have a vested interest in seeing as many test cases pass as
possible.
 They develop specific expertise in how to do good testing, and how to use
testing tools.

22
 Testing performed by users and clients
 Alpha testing
 Performed by the user or client, but under the supervision of the
software development team.
 Beta testing
 Performed by the user or client in a normal work environment.
 Recruited from the potential user population.
 An open beta release is the release of low-quality software to the general
population.
 Acceptance testing
 Performed by users and customers.
 However, the customers do it on their own initiative.

23
Finally
 Software testing is four steps procedure
 Initially, tests focus on each component individually, ensuring
that it functions properly as a unit.
 makes heavy use of white-box testing techniques, exercising
specific paths in a module's control structure to ensure
complete coverage and maximum error detection.
Cont…
 Next, components must be assembled or integrated to form the
complete software package.
 Integration testing addresses the issues associated with the dual
problems of verification and program construction.
 Black-box test case design techniques are the most prevalent during
integration, although a limited amount of white-box testing may be
used to ensure coverage of major control paths.
Cont…
 After the software has been integrated (constructed), a set of
high-order tests are conducted. Validation criteria
(established during requirements analysis) must be tested.
 Validation testing provides final assurance that software meets
all functional, behavioral, and performance requirements.
 Black-box testing techniques are used exclusively during validation.
Cont….
 The last high-order testing step falls outside the boundary of
software engineering and into the broader context of
computer system engineering. Software, once validated, must
be combined with other system elements (e.g., hardware,
people, databases).
 System testing verifies that all elements mesh properly and that
overall system function/performance is achieved.
 Others
 Installation
 Putting the system in to work
 Direct/phased/parallel/ one site
 Training
 Enabling end users and technical personals to work and mange
the system/software
 For whom and how much?
 Maintenance
 Providing continuous support as long as the software/system is
alive.
 Adaptive/perfective/corrective

28
 Summary
 Introduction
 Understanding motivations and basic concepts
 Terminologies , concepts, processes, approaches

 Modeling using UML

 Understanding modeling tools in software development
 Types, categories and structure

 Requirement elicitation
 Collecting and organizing users requirement-WHAT- User needs
 From function, class, and interface points of view

29
 Cont…
 Requirement Analysis
 Analyzing and modeling requirements-WHAT System
 In terms of Function, Logic and Objects (classes)

 System and object design

 Specifying the new system-HOW
 At an architecture level and detail design level

 Implementation, testing and Pragmatic

 Making it a reality
 Coding, testing and documentation

30
 End of Chapter 6
and
End of the Course

31