0% found this document useful (0 votes)
7 views24 pages

Object-Oriented Coding and Testing Guide

Chapter Eight of the document discusses Object Oriented Implementation and Testing, covering key topics such as coding standards, testing phases, and maintenance of software. It emphasizes the importance of adhering to coding guidelines, conducting thorough testing at various levels, and maintaining software to meet evolving user needs. The chapter also outlines the roles of documentation, training, and inspection in ensuring software quality and functionality.

Uploaded by

...............
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views24 pages

Object-Oriented Coding and Testing Guide

Chapter Eight of the document discusses Object Oriented Implementation and Testing, covering key topics such as coding standards, testing phases, and maintenance of software. It emphasizes the importance of adhering to coding guidelines, conducting thorough testing at various levels, and maintaining software to meet evolving user needs. The chapter also outlines the roles of documentation, training, and inspection in ensuring software quality and functionality.

Uploaded by

...............
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd

Haramaya University

College of Computing and Informatics


Department of Information Systems

Chapter Eight
Object Oriented Implementation and Testing

G..
hak
Yi se
nst:
I
Contents

Coding, Testing and Inspection


Installation
Documentation and Training
Maintenance
Coding, Testing and Inspection
Coding - The objective of the coding is to transform the design of a system into code in a high level
language and then to unit test this code.
 After all the modules of a system have been coded and unit tested, the integration and system
testing phase is undertaken.
 Coding is undertaken once the design phase is complete and the design documents have been
successfully reviewed.
 The programmers adhere to standard and well defined style of coding which they call their
coding standard.
 The main advantages of adhering to a standard style of coding are as follows:
• A coding standard gives uniform appearances to the code written by different engineers
• It facilitates code of understanding.
• Promotes good programming practices.
Coding standards and guidelines
 A coding standard lists several rules to be followed during coding, such as the way variables are to be
named, the way the code is to be laid out, error return conventions, etc.
 Good software development organizations usually develop their own coding standards and guidelines
depending on what best suits their organization and the type of products they develop.
The following are some representative coding standards.
 Rules for limiting the use of global: These rules list what types of data can be declared global and what cannot.
 Contents of the headers preceding codes for different modules.
 The exact format in which the header information is organized in the header can also be specified.
 Naming conventions for global variables, local variables, and constant identifiers: A possible naming convention can be
that global variable names always start with a capital letter, local variable names are made of small letters, and constant
names are always capital letters.
 Error return conventions and exception handling mechanisms: The way error conditions are reported by different
functions in a program are handled should be standard within an organization. For example, different functions while
encountering an error condition should either return a 0 or 1 consistently.
Con’d

The following are some representative coding guidelines recommended by many software
development organizations.
 Do not use a coding style that is too clever or too difficult to understand: Code should be easy
to understand. Many inexperienced engineers actually take pride in writing cryptic and
incomprehensible code. Clever coding can obscure meaning of the code and hamper
understanding. It also makes maintenance difficult.
 Avoid obscure/unclear side effects: The side effects of a function call include modification of
parameters passed by reference, modification of global variables, and I/O operations.
 An obscure side effect is one that is not obvious from a casual examination of the code.
 Obscure side effects make it difficult to understand a piece of code. For example, if a global
variable is changed obscurely in a called module or some file I/O is performed which is
difficult to infer from the function’s name and header information, it becomes difficult for
anybody trying to understand the code.
Con’d

 Do not use an identifier for multiple purposes: Programmers often use the same identifier to denote several
temporary entities.
 Each variable should be given a descriptive name indicating its purpose. This is not possible if an identifier
is used for multiple purposes. Use of a variable for multiple purposes can lead to confusion and make it
difficult for somebody trying to read and understand the code.
 Use of variables for multiple purposes usually makes future enhancements more difficult.
 The code should be well-documented: As a rule of thumb, there must be at least one comment line on the
average for every three-source line.
 The length of any function should not exceed 10 source lines: A function that is very lengthy is usually very
difficult to understand as it probably carries out many different functions. For the same reason, lengthy
functions are likely to have disproportionately larger number of bugs.
 Do not use goto statements: Use of goto statements makes a program unstructured and very difficult to
understand.
Testing
 Testing is an important phase in software development that involves evaluating a system or application to identify any
defects or errors.
 The primary goal of testing is to ensure that the software meets the specified requirements and functions as expected.
 It encompasses various activities aimed at detecting and fixing bugs, ensuring reliability, and verifying that the
software meets quality standards.
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.
Con’d
 Testing is Verification and Validation
“Are we building the right system?”
 Focuses on the system's purpose and alignment with the overall goals and
requirements.
 It's about validating the project's direction and ensuring that the chosen
solution is the right one.
“Are we building the system right ?”
 It involves considerations of the chosen technologies, coding standards,
design principles, and overall development practices.
 It's about ensuring that the development team is following best practices
and building the system in a way that is efficient, maintainable, and reliable.
Con’d
Testing is a continuous activity during software development. In object-oriented systems, testing
encompasses three levels, namely, unit testing, subsystem testing, and system testing.
1) Unit Testing
In unit testing, the individual classes are tested. It is seen whether the class attributes are
implemented as per design and whether the methods and the interfaces are error-free. Unit testing
is the responsibility of the application engineer who implements the structure.
2) Subsystem Testing
This involves testing a particular module or a subsystem and is the responsibility of the subsystem
lead. It involves testing the associations within the subsystem as well as the interaction of the
subsystem with the outside. Subsystem tests can be used as regression tests for each newly
released version of the subsystem.
3) System Testing
System testing involves testing the system as a whole and is the responsibility of the quality-
assurance team. The team often uses system tests as regression tests when assembling new
releases.
Object-Oriented Testing Techniques
Grey Box Testing
The different types of test cases that can be designed for testing object-oriented
programs are called grey box test cases. Some of the important types of grey box testing
are:
 State model based testing: This encompasses state coverage, state transition
coverage, and state transition path coverage.
 Use case based testing: Each scenario in each use case is tested.
 Class diagram based testing: Each class, derived class, associations, and
aggregations are tested.
 Sequence diagram based testing: The methods in the messages in the sequence
diagrams are tested.
Techniques for Subsystem Testing
The two main approaches of subsystem testing are:
 Thread based testing: All classes that are needed to realize a single use case in a
subsystem are integrated and tested.
 Use based testing: The interfaces and services of the modules at each level of hierarchy
are tested. Testing starts from the individual classes to the small modules comprising of
classes, gradually to larger modules, and finally all the major subsystems.
Categories of System Testing
 Alpha testing: This is carried out by the testing team within the organization that develops
software.
 Beta testing: This is carried out by select group of co-operating customers.
 Acceptance testing: This is carried out by the customer before accepting the deliverables.
What Testing Shows
Who Tests the Software?

Independent tester
Developer Must learn about the system, and, will attempt
to break it and, is driven by quality Eg.
Perform unit testing, which involves testing
 Quality Assurance (QA) Engineers
individual modules.
 Users or Beta Testers
They are responsible for testing their code
 Security professionals
and fixing any bugs or issues that arise
during this phase.
Test Planning
 Testing starts with the development of a test plan that defines a series of
tests that will be conducted.
 Since testing takes place through the development of an object-oriented
system, a test plan should be developed at the very beginning of the
SDLC and continuously updated as the system evolves.
 The test plan should address all products that are created during the
development of the system.
Principles of Testing

 All the tests should meet the customer requirements.


 To make our software testing should be performed by a third party.
 Exhaustive testing is not possible. As we need the optimal amount of testing based
on the risk assessment of the application.
 All the tests to be conducted should be planned before implementing it
 It follows the Pareto rule(80/20 rule) which states that 80% of errors come from 20%
of program components.
 Start testing with small parts and extend it to large parts.
Inspection
Software inspection is a control technique for ensuring that the documentation produced
during a given phase remains consistent with the documentation of the previous phases and
respects pre-established rules and standards.
A core technique in software quality assurance where a group of reviewers
independently and systematically examine software artifacts to find defects.
The point of inspection is to verify that the installed equipment:
Complies with relevant standards – this is normally a mark of certification by the
installer or manufacturer
Is the correct type and installed in accordance to the Regulations.
Not damaged or defective which would cause a safety issue.
Installation

 Installation is the process of making hardware and/or software ready for use.
Obviously, different systems require different types of installations.
 While certain installations are simple and straightforward and can be performed by
non-professionals, others are more complex and time-consuming and may require the
involvement of specialists.
 You can install software on individual machines or on network servers - this is
common in situations where several employees and applications share the software.
Documentation
 When a software is developed, in addition to the executable files and the source code,
several kinds of documents such as users’ manual, software requirements specification (SRS)
document, design document, test document, installation manual, etc., are developed as part
of the software engineering process. All these documents are considered a vital part of any
good software development practice.
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.
Con’d

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.
Training

 Enabling end users and technical personals to work and mange the
system/software
Software Maintenance

 Software maintenance is the process of changing, modifying, and updating


software to keep up with customer needs.
 Software maintenance is the process of modifying and updating software
after its initial release to correct defects, improve performance, adapt to
changes in the environment, and meet new user requirements.
 It encompasses a set of activities that aim to keep software in a functional
state throughout its lifecycle.
 Software maintenance is done after the product has launched for several
reasons including improving the software overall, correcting issues or bugs,
to boost performance, and more.
Con’d

Software maintenance is typically classified into 4 different types:


1) Corrective Maintenance: Focuses on fixing errors, bugs, or defects discovered
in the software during its operational use.
2) Adaptive Maintenance: Involves making changes to the software to adapt it to
changes in the external environment, such as operating system upgrades,
hardware changes, or changes in regulations.
3) Perfective Maintenance: Aims to improve the software's performance, enhance
its functionality, and add new features.
4) Preventive Maintenance: Focuses on proactively making modifications to the
software to reduce the likelihood of future issues or to improve its maintainability.
Con’d

Key aspects of software maintenance include:


 Bug Fixes: Identifying and addressing software defects to ensure correct and reliable operation.
 Enhancements: Adding new features or improving existing functionalities based on user feedback
or changing business requirements.
 Upgrades: Adapting the software to work with new hardware or software environments, including
updates to operating systems, libraries, or third-party components.
 Optimizations: Improving the software's performance, efficiency, and resource utilization.
 Documentation Updates: Keeping documentation up-to-date to reflect changes in the software.
 User Support: Providing ongoing support to users, addressing their queries, and helping them
navigate the software.
 Security Updates: Identifying and patching security vulnerabilities to protect the software from
potential threats.
 Regulatory Compliance: Ensuring that the software complies with changing regulations and
standards.
Thank You!!!

You might also like