Beruflich Dokumente
Kultur Dokumente
SOFTWARE ENGINEERING
MODULE C7
SOFTWARE ENGINEERING
CONTENTS
S.No.
Chapter
Page
1.
2.
15
3.
Software Testing
28
4.
36
No. of Pages : 40
No. of Sheets : 21
April - 2002
CHAPTER 1
C7
---
---
Business Software
---
Engineering and
Scientific Software
---
Embedded Software
---
PC Software
---
Web based
Software
---
Artificial Intelligence
---
to
Multimedia
based
Software
Problems.
When a Software is developed, the Quality of the end Product is always important. The
Software Project Manager must continuously evaluate the Quality throughout the
Development Process. The Quality can be divided in two categories Quality of Design,
which refers to the Characteristics that the Designers specify and Quality of
Conformance, which defines the degree to which the Design Specifications are followed
during the Development.
There are many Quality Criteria to be taken into account. They are:
Usability
Integrity
Efficiency
Correctness
Reliability
Maintainability ----- The efforts needed to locate and rectify a Fault. It is often
measured by the Mean Time To Change a Failure.
Flexibility
Testability
Portability
----environment.
Reusability
Interoperability ----- The effort needed to couple the System to another one.
The
effort
needed
to
transfer
Program
to
new
CORRECTNESS
INVERSE
RELIABILITY
= Inv
EFFICIENCY
E
= DirectINTEGRITY
-_
--
---
MAINTAINABILITY
--
TESTABILITY
--
FLEXIBILITY
--
PORTABILITY
--
--
--
--
P --
REUSABILITY
--
--
INTEROPERABILITY
--
--
--
--
--
--
USABILITY
R
E
--
= DIRECT
= NIL
Size of the Software. If the size is too big, the probability of Errors also increases.
Percentage of new design and / or Code. If the new Design is proportionately more,
then much Effort would be needed to develop the Software.
Complexity of the Software system. More Complexity would need more Effort, Time and
Cost.
Security Classification Level of the Software. More Safety Critical Software needs
tougher Verification and Validation. This obviously needs more Time, Effort and Cost.
Volatility of the Requirement. If the Requirement changes very often, the Development
Process gets affected.
Personnel associated with the Software development. The Personnel must have
Knowledge, Enthusiasm and Involvement. They should also be properly Trained.
There are total 65 Processes in the whole Software Life-Cycle. The Processes are spread
over Pre-Development, Development and Post-Development phases. These phases
cover 33 Processes. There are, in addition, 19 Integral Processes, which are spread over
the whole Development Life-Cycle.
PROJECT INITIATION ( 4 )
PROJECT MONITORING & CONTROL ( 5 )
CONCEPT
EXPLORATION
(5)
DEVELOPMENT
PROCESSES
( 14 )
POSTDEVELOPMENT
PROCESSES
( 11 )
REQUIREMENTS
(3)
DESIGN
(5)
SYSTEM
ALLOCATION
(3)
IMPLEMEN
TATION
(6)
INSTALLATION
(4)
OPERATION &
SUPPORT
(3)
MAINTENANCE
(1)
RETIREMENT
(3)
INTEGRAL PROCESSES ( 17 )
VERIFICATION AND VALIDATION ( 6 )
SELECT
PROJECT
MODEL
CONFIGURATION
MANAGEMENT ( 4 )
7
DOCUMENTATION DEVELPOMENT ( 3 )
TRAINING ( 4 )
Effective Project Management needs that the Software Development be done in three
Stages.
A)
Some of the Processes are to be followed during the Initiation of the Project Development.
They are to be properly Planned and performed before the actual Development starts.
Map activities To Software Life-cycle Model.
Allocate Project Resources.
Establish Project Environment.
Plan Project Management.
B)
The Quality Management must be done throughout the Development Life-Cycle for
producing a good Software. The Processes are:
Plan Software Quality Management.
Define Software Metrics.
Manage Software Quality.
Identify Quality Improvement needs.
PRE-DEVELOPMENT PROCESSES
B)
DEVELOPMENT PROCESSES
Actual Development of the Software can be divided into several Phases --- Requirement,
Design and Implementation.
A)
Requirement Processes
Design Processes
This Phase defines the Design Flow and Interfaces. It also describes the Algorithm in detail.
Perform Architectural Design.
Design the Database, if applicable.
Design Interfaces.
Select or Develop Algorithms.
Perform detailed Design.
C)
Implementation Processes
This Phase defines the Coding Processes and how the Integration between various Modules
as well as Hardware and Software will be done.
Create Test Data.
Create Source Code.
Create Object Code.
Create Operating Documents.
Plan Integration.
Perform Integration
POST-DEVELOPMENT PROCESSES
After the Development of the Software, come the Installation, Maintenance and Retirement
Processes. Software, though does not have any aging as such, needs Update from time to
time. In the case of any Alterations done after Installation, the Software may have to go
through the whole Development Processes again.
A)
Installation Processes
Plan Installation.
Distribute Software.
Install Software.
Maintenance Processes
Reapply Software Life-cycle.
D)
Retirement Processes
Notify the Users.
Conduct Parallel Operations, if applicable.
Retire the System.
INTEGRAL PROCESSES
There are some Processes that need to be pursued throughout the Software Development
Life-Cycle. The Integrity of the Software and the proper output depends on these Phases.
10
A)
This Phase is very important to be assured that the Software has been developed in a
Proper Way and will perform Proper Jobs. This also covers Testing of the Software. The
Processes are:
Plan Verification and Validation.
Execute V & V Tasks.
Collect and analyze Metric Data.
Plan Software Testing.
Develop Software Testing Requirements.
Execute the Software Testing.
B)
C)
Training Processes
Plan the Training Program.
Develop Training Materials.
Validate the Training Program.
Implement the Training Program.
Design process should not suffer from Tunnel Vision. A good designer should consider
alternate approaches.
Design should not reinvent the wheel. Reusable design components should always be
chosen as an alternative to reinvention.
11
Design should minimize the Intellectual Distance between the Software and the
problem, as it exists in the real world.
Design should be Assessed for Quality during the formation and not after a fact.
SYSTEM
ENGINEERING
ANALYSIS
DESIGN
CODING
TESTING
MAINTENANCE
12
Requirement Analysis
Any Software is built to process Data and Events, which continue Information
Domain of the System. Software Engineer must understand the Information Domain and
the Required Function, Behaviour, Performance and Interfacing. Documentation and
Review of Requirements are to be done in this stage.
Design
Code Generation
Testing
Maintenance
It comprises Regular check for Errors and change in Software to
accommodate change in Environment.
The Spiral Model is an evolutionary Software Process Model that couples the
Iterative Nature of the Prototype Model with the Controlled and Systematic approach of
the Waterfall Model to provide the potential for Rapid Development. In this case, the
Software is developed in a Series of Incremental Releases.
This Model is divided into a number of specified Activities called Task Regions:
13
Planning
Risk Analysis
Engineering
---
Construction and
Release
---
PLANNING
RISK ANALYSIS
( Finding Objective )
(Analyzing Alternatives)
Initial Requirements
Gathering and Project
Planning
Risk Analysis
based on
initial needs
Planning
Based on
Customer
Comments
Risk
Analysis
based
on
Customer
Reaction
Customer
Evaluation
After Release
Towards a
Completed
System
14
RELEASE
ENGINEERING
SOFTWARE SPECIFICATION
Principles
Context on which the system operates is to be defined. This covers Interaction with
other system components.
Diagrams and other notational forms should be restricted in number and consistent in
use.
Do the stated Goals and Objectives for the Software remain consistent with the
System Goals and Objectives?
Have the important Interfaces for all the System Elements been described?
Is the behaviour of the Software consistent with the Inputs & Outputs?
15
A set of Operational Principles must be followed :-Information Domain of the problem must be represented and understood.
Analysis process should move from Vital Information to the Implementation detail.
16
CHAPTER 2
C7
Reference Documents
17
Documents used to develop the SQAP should be referred in its Text. By definition,
these Documents originate outside the Project. Some may have confidentiality restrictions,
so that only Part of the Document is available to the Project. Some may have different
Update and Version Release Procedures. Some may be on Paper and some Electronic.
Some may be located with the project and some may be located elsewhere. Any special
arrangement to obtain the document is to be Identified and the Project must use the most
Current Official Version.
Organization
The Organizational Element(s) responsible for the Software Quality Assurance
Functions covered by the SQAP, should be Developers having Knowledge in Quality
Assurance Tools, Techniques, and Methodologies. The SQAP should state the
organizational and functional boundaries of the SQA organizational element.
The relationship between the Primary SQA Organizational Member and the Software
Development Member should be defined and explained. The most effective organization will
have a separate Quality Assurance (QA) Team, responsible to an SQA Organization, rather
than to the manager of the Software Development organization. SQA independence is
necessary because the QA manager must not have Development responsibilities, which can
otherwise tend to override the Quality concerns. SQA Organizational Elements should
share Quality Evaluation Records and related Information with Customer
Organizations to promote resolution of Quality Issues.
A pictorial Organizational Structure should be included with an Explanation
describing the Nature and Degree of Relationships with all Organizational Elements
responsible for Software Quality and Development. The explanation should include the
following:
The Reporting Chain for reducing Conflicts and the Method by which Conflicts are
to be Resolved among the elements.
The Size of the SQAP Element and the Amount of Effort dedicated to the Project,
where the amount is less than 100%
The description of the Organizational Structure should be complete so that all the
Tasks addressed in the SQAP can be directly related to a responsible Organization.
Tasks
18
This describe (a) the Portion of the Software Life-cycle covered by the SQAP,
(b) the Tasks to be performed with special emphasis on Software Quality Assurance
Activities, and (c) the relationships between these Tasks and the planned Major
Check-points. The sequence of the tasks shall be indicated.
Some of these tasks consist of Planning Activities, while others, such as reviews and
tests, are directed towards the Software Product. All the Tasks may not be applicable to a
Specific Project, in which event, they may be omitted from the Project SQAP. Any omissions
or deviations should be explained in the appropriate section of the project SQAP. Any
additional tasks, should be included in the appropriate SQAP sections.
This section of the SQAP also should identify the Tasks associated with the
Publication, Distribution, Maintenance, and Implementation of the SQAP.
Some of these Tasks have a profound Influence on the Development Element, and
such Tasks should be performed by, or in close Association with, the Software Development
Element. Each identified Task, should be defined together with Entrance and Exit Criteria
required to Initiate and Terminate the Task. The output of each task should be defined in
such a way that its achievement or termination car be Objectively Determined in a
Prescribed Manner.
It is strongly recommended that a Software Development Plan (SDP) or a Software
Project Management Plan (SPMP) be prepared. If either Document is not available, schedule
Information outlining the Development Cycle should be provided to include the Software
Quality Assurance Activities.
Responsibilities
If two or more organizational elements share Responsibility for a Task, their
Respective Responsibilities should be Identified. Describe the procedure for resolving
issues between Organizational Elements sharing Responsibilities. The Management
position accountable for overall Software Quality should be identified. SQAP should also
indicate the Review and Approval Cycle, indicating Signature Authority, as required. It
should show the number of Controlled Copies and describe the Method of Control. It should
designate the personnel and organizational element responsible for distributing the SQAP
and describe the Methods and Responsibilities for the Approval, Distribution, and
Incorporation of Changes. The SQAP should identify the Organizational Elements
responsible for the Origination, Review, Verification, Approval, Maintenance, and Control of
the required Task Documentation.
Documentation
The SQAP shall identify Documentation, whether Hardcopy or softcopy, that will be
prepared during the Development, Verification and Validation, Use, and Maintenance of the
Software. If there is no Independent Verification and Validation, then the Quality Assurance
Procedures that are to be used on the Project should be Identified. Also, all required Test
Documentation should be noted. The SQAP also shall identify the Specific Reviews,
Audits, and Associated Criteria required for each Document.
To ensure that the implementation of the software satisfies requirements, the
following documentation is required as a minimum.
19
This minimum set of documents has been found to be a solid foundation to assure the
Quality of a Software Development. These documents are equally usable in In-house
Developments with or without an Informal Contract. Other Documentation, such as Test
Plans and Database Design Information, should be provided, as applicable. The QA activities
associated with each Document Review must be scheduled in consonance with the
Development Life-cycle Phases of the project. Where the development project changes
Existing Software, the required Set of Documents may be a Subset of the Documents used
for the Original Development.
A brief description of each document follows.
Software Requirements Specification (SRS).
The SRS shall clearly and precisely describe each of the essential Requirements of the
Software and the External Interfaces. Each Requirement shall be defined such that its
Achievement is capable of being Objectively Verified and Validated by a prescribed
method.
The SRS is usually developed from One or More Documents, e.g., a User
Requirements Statement, Operational Requirements, Preliminary Hazard Analysis, Software
Product Definition, SRS Reverse Engineering Documentation, System-level Requirements
and Design Documentation. It specifies in detail the Requirements as agreed upon by the
Developer and the Requester or User. Where the Developer produces the SRS, the SQAP
should identify the Standards or Guides followed. The SQAP should clearly define the
methods to be used by the SQA Organizational Element to Verify and Validate the Data in
the SRS.
Software Design Description (SDD).
The SDD is a Technical description of how the Software will meet the Requirements
defined in the SRS. It shall also describe the Components and Sub components of the
Software Design, including Databases and Internal Interfaces. The SDD shall be prepared
first as the Preliminary SDD and subsequently expanded to the Detailed SDD. It involves
Descriptions of the Operating Environment, Timing, System Throughput, Tables, Sizing,
Centralised or Distributed Processing, Extent of Parallelism, Client/Server, Reusable Objects
Library, Program Design Language (PDL), Prototypes, Modelling, Simulation, etc. The SQAP
should identify the Standards and Conventions that apply to the Content and Format of the
SDD.
The SDD may be an evolving Document or a Document that is updated after each
significant Review. A new Version containing a more Detailed Design Description is
developed for each subsequent review. The SQAP should identify the Number and Purpose
of the SDD Documents.
The SDD is subject to the Preliminary Design Review (PDR) and the Critical Design
Review (CDR). The SDD should consist of following items:
20
The SQAP should clearly define the methods to be used by the SQA Organizational
Element to Verify and Validate the Data in the SDD.
Software verification and validation plan (SVVP)
The SVVP shall identify and describe the methods to be used:
To verify that the Requirements in the SRS have been approved by an appropriate
authority, are implemented in the Design expressed in the SDD, which is further
implemented in the Code.
To Validate that the Code, when executed, Complies with the Requirements expressed in
the SRS.
The SVVP describes the overall Plan for the Verification and Validation of the
Software and could be produced and Reviewed incrementally. The Tasks, Methods, and
Criteria for V & V are described. SVVP might be used to Document the Procedures to be
followed for some of the Reviews. This section should explain the scope of Validation Testing
to ensure the Reviewed Requirements and explain the stages of Development that require
Customer Review and the extent of the Verification that will precede such a Review. The
contents of the SVVP will be Evaluated at the Software Verification and Validation Plan
Review(SVVPR).
Software Verification and Validation Report (SVVR)
The SVVR shall describe the Results of the execution of the SVVP and summarises
the observed Status of the Software as a result of the Execution of the SVVP. The SVVR
should include the following information:
This section should explain why the style of report was chosen and in what way it
satisfies the Criticality of the Product and gives Assurances to the Customer. The SVVPR
should clearly define the Methods to be used by the SQA Organizational Element to assure
the Correctness and Completeness of the Data in the SQAP.
User Documentation
User Documentation shall Specify and Describe the Required Data and Control Inputs
and Input Sequences as well as Options, Program Limitations, and other activities or items
21
necessary for successful Execution of the Software. All Error Messages shall be
Identified and Corrective Actions are to be elaborately described. The User
Documentation section of the SQAP should describe the Software's Operational Use and
comprise the following items:
User Instructions that contain an Introduction and a Description of the User's Interaction
with the System
Procedures for Reporting and Handling problems encountered during the use of a
Software Item.
22
Identifying the Personnel responsible for maintaining the Guidelines and distributing the
SCMP.
The SQAP should define the procedures for creating the data in the SDP and criteria
for updating and assuring its Quality. Any deviations from the Plan should be reconciled
between the SQA staff and the Software Development Manager. The Plan should be
updated and the latest version clearly identified.
Software Project Management Plan (SPMP)
The SPMP can be used in place of an SDP, or as a Plan that governs a larger project
having Sub-projects, each covered by SDPs. The SPMP should identify all Technical and
Managerial Activities associated with an instance of Software Development. The SPMP
should specify the following items:
23
The SQAP should define the procedures for creating the data in the SPMP and
criteria for updating and assuring its quality. Any deviations from the plan should be
reconciled between the SQA staff and the Software Project Manager.
Software Maintenance Manual (SMM)
A Maintenance Manual should contain Instructions for Software Product Support and
Maintenance, e.g., Procedures for Correcting Defects, Installation of Enhancements,
and Testing of all Changes. All Hardware and Software Configuration Specifications,
required to maintain the Software, should be described in Detail. Any Unusual Settings or
known Anomalies should be identified in order to aid in Efficient Maintenance. New Versions
of Software should be thoroughly tested prior to incorporation into Operational Systems.
Version control procedures should be reviewed and approved by SQA and SCM
Organizational Elements. The SQA Organizational Element should periodically Audit and
Validate the use of the Version Control Procedures as well as the Software Maintenance
Process and Procedures.
Additional suggested documentation
The Attributes, Context, and Environment of the Product could dictate Inclusion of
Additional Documents, such as, but not limited to, the following:
A User Requirements Statement can be used as a high-level document preceding
the approved SRS for a large development, in place of an SRS in cases where minor
changes are made to an operational system that has no SRS, or as a means of passing
requirements on to a supplier.
An Introduction
24
Run Schedules
Error Procedures
Security Procedures
Distribution Procedures
Restart procedures
Termination Procedures
25
Procedures for evaluating the effectiveness of the training and for making modifications
to the training.
The Software Metrics Plan should address the way Product and Process Metrics will
be used to Manage the Development, Delivery, and Maintenance Processes. The Software
Metrics Plan should contain information on the following:
a)
b)
The Quantitative Measures of the Quality of the Software Products and Processes.
c)
How the Product or Process Metrics will be used to Identify and Measure
Performance.
d)
How Remedial Action will be taken if Product or Process Metric Levels grow Worse or
exceed established Target Levels.
e)
f)
How the Metrics will be used to determine how well the Development Process is
being carried out in
terms of Milestones and In-process Quality Objectives being
met on schedule.
g)
How the Metrics will be used to determine how Effective the Development Process
Improvement is at
reducing the Probability that Faults are introduced or that any
Faults Introduced go Undetected.
h)
i)
j)
The Software Security Plan should address the way in which the Software and the
Data will be protected from unauthorised Access or Damage. The Software Security Plan
should contain Information on the following:
a. How the Data should be Classified and how this will be Communicated
b. How the Users of the Software Access the Application and how that Access is to be
controlled.
c. Network Design.
d. User Identifications, Passwords, Security Logging, and Auditing.
26
Physical Security.
g. Virus Protection.
h. How Employees will be trained on Security Procedures and Practices.
i. The Method by which this Security Plan will be Audited for Compliance.
j.
Disaster plan.
Documentation Standards
(2)
(3)
Coding Standards
(4)
Commentary Standards
(5)
(6)
Selected Software Quality Assurance Product and Process Metrics such as:
(a)
Branch Metric
(b)
(c)
Domain Metric
(d)
(e)
The SQAP should identify or reference the Standards, Practices, Conventions and
Metrics to be used on the Project. As a minimum, the Information required should be
addressed in the following life-cycle phases:
Software Requirements,
Design,
Implementation,
Testing, and
Maintenance.
27
b)
c)
d)
e)
Functional audit
f)
Physical audit
g)
In-Process audits
h)
Managerial reviews
i)
j)
Test
This section shall identify all the tests not included in the SVVP for the software
covered by the SQAP and shall state the methods to be used. The SQAP shall include the
Specific Software Tests and Testing not addressed in the SVVP (or other test
documentation). The SQAP should identify and describe the Methods, Approaches, and
Techniques to be used. Test methods and techniques can be divided into two
classifications: Static Tests and Dynamic Tests. Static Testing Evaluates or Analyses the
Software without executing the Code.
Dynamic testing, encompasses such Methods and Techniques as
Unit Level Testing,
White-box Testing,
Black-box Testing,
Integration Testing,
System Level Testing,
Stress Testing,
28
Test Plans
Test Design and Test Case Specifications
Test Procedures and Test Instructions
Test Schedule
Test Reports and
Test Incidents and their Resolution.
Records maintenance
The SQAP should specify the manner in which Records will be kept Also, it should state
how Records will be stored to protect them from Fire, Theft, or Environmental Deterioration.
Training
The need for Training of Personnel designated to perform the Activities defined in the
SQAP should be assessed. It is suggested that a Document is created to define the Task,
Skill Requirement(s) of the Task and the Skills of the Personnel designated to perform the
Task. This will allow the Rapid Identification of Training Needs for each Task and each
Individual. Considerations for Training should include Special Tools, Techniques,
Methodologies and Computer Resources.
Once the Training Need is established, a Training Plan should be developed that
identifies the Training Activities Required to successfully implement the SQAP. Existing
Training Programs should be adapted or New Training Programs developed to meet these
Training Needs. Training Sessions should be scheduled for Personnel who will be assigned
to carry out the Tasks.
If Training for Non-SQAP related Software Activities is not covered in other Project
Documentation, the SQA Organizational Element, upon Completion of the other Project
Documentation Review, should recommend the Development and Inclusion of a Training
Programme into their Documentation.
Resources for SQAP
The four types of resources required to implement a SQAP are Personnel,
Equipment, Facilities and Tools. The Quantity and Quality of these Resources should be
made known to the Appropriate Level of Management. The responsible element should
identify the Job Classifications and Skill Levels of the Personnel required to implement and
maintain the SQAP, throughout the Life of the Project. It should identify the Hardware
needed to implement the SQAP and to support it throughout the Project, as well as
Estimates of Computer Time and Support required. Also, it should identify the Facilities
needed for Storage of Media and Records. When Resources are identified by an Element
29
other than the SQA element, the SQA Element should verify compliance with this Task. The
Tools required for Implementation should have been already identified in the SQAP itself.
CHAPTER 3
C7
SOFTWARE TESTING
Testing of any Software is an integral part of the Software Development Life cycle
and is a Critical part of Software Quality Assurance. Nowadays, roughly about 30 to 40 %
of the total Software Development Cost are catered for Software Testing. In fact, for Safetycritical Software, e.g. those used in Railway Interlocking, the cost may be even three to five
times of all other costs taken together.
The main Objectives of Testing a Software, are
Softwares are to be built keeping Testability in mind, which would allow the Testers to
generate Test Cases more efficiently. Care is to be taken to have minimum Bugs, and even
if there is any, the Test Execution should not be affected by this. The Software should have
Controllability, Simplicity, Stability and Understandability to have a good Testing Process.
The capabilities of a Software Test Plan is dependent on --
User satisfaction
Planning
Training
Use of processes
30
Tools
Efficiency
Quality control
Correctness
are
File Integrity
Authorization
the
Audit Trail
Service Levels
Access Control
Compliance
Reliability
31
32
ASSESS
DEVELOPMENT
DEVELOP THE
TEST PLAN
TEST SOFTWARE
REQUIREMENTS
TEST SOFTWARE
DESIGN
DEFINE SOFTWARE
REQUIREMENTS
EXECUTE AND
RECORD RESULTS
ACCEPTANCE
TEST
REPORT TEST
RESULTS
TEST SOFTWARE
INSTALLATION
TEST SOFTWARE
CHANGES
EVALUATE TEST
EFFECTIVENESS
REQUIREMENTS
33
The following checklist is to be inducted by the Software Test Team for getting
efficient and fruitful test results:
Whether the Test Strategy is used as a Guide for developing the Test Tactics?
Whether the Individuals associated with testing were properly identified and a
Strategy was maintained for their recruitment?
Did the Management assign any Documented Responsibility to the Test Team
Members?
Had a Testing Plan been established, covering Objectives, Strategy, Tactic and
Resource Identification?
Whether any provision for modifying Test Plan and Evaluation was kept to tackle any
unforeseen changes?
Does the Test Team adequately represent User, Data Administrator, Internal Auditor,
Quality Assurance Staff, Management, Security Administrator and Professionally trained
Tester?
Whether the idea of Removing Faults at an Early Stage is appreciated by the Test
Team?
Will the Test Team do the Verification and Validation tasks as well?
Has the Test Team identified a Source for Generic Test Tool?
SOFTWARE TESTING
.Softwares are tested both for their Functions as well as their Structures.
Software Functional Testing
These tests are designed to ensure that the System Requirements and
Specifications are achieved. The process normally involves creating Test Conditions for
use in evaluating the correctness of the application. The various types of Software Functional
Tests are:
Requirements Test
Regression Test
Error-handling Test
34
Manual-Support Test
Control Test
Parallel Test
Stress Test
Execution Test
Recovery Test
Operations Test
Security Test
35
Error oriented Testing and Analysis ensures that the range of Typical Errors is
covered.
ensure that
the
major
In Function-driven Testing, the Test case Generator must create at least one Normal
Test Case for every specified Function. The Generator must also create one or more
abnormal Test Cases for every Function. The later finds out any missing Error-handling
Functions. The Functional Testing requires the Test of not only the Functions implemented
by the whole Programme but also partial Programmes. Some Faults can remain undetected
when the Programme is tested as a whole and can only be detected by testing of Partial
Programmes.
Functional Testing and Analysis can be both Independent of and Dependent on
Specification. For Tests independent of Specifications, we have two types:
i) Testing based on the Interface:
Input Domain Testing, where Input Data is chosen to cover the entire domain including
Upper and Lower extremes as well as many mid range values. The Tester applies a Data
Input at its Highest and Lowest valid values. This Boundary Analysis should be
complemented with feeding Data having values just adjacent and beyond the Boundary
Values, for effectiveness.
Equivalence Partitioning, where the full set of Input Data is divided in to many Classes,
needing equivalent treatments. Here, the Tester chooses Partitions such that the every
Data value in a Partition Class has the Equivalent effect on Test Result.
Syntax Checking, where the Programme must parse its Input and handle wrongly
formatted Data.
ii)
Special Value testing, where Test Data is chosen on the basis of functional features to
be computed.
Output Domain Coverage, where Data is chosen such that extremes of each Output
Domain will be achieved.
36
Complexity Measures -- It defines the small Percentage of Codes which contain the
largest number of Errors.
Symbolic Execution
Text Execution means Running or Executing Software Test Cases to find Software
Faults and showing that the Software works as Specified. It is largely Procedural and
depends only slightly on Theoretical or Mathematical foundations. The Software Test
Execution is done according to one of the five different Maturity Levels described by the
Software Engineering Institute (SEI).
Level 1 Organizations do not provide any Automatic Tool for Software Testing and
the Test Documentation is also of a Poor Quality. The Professional Level of Testers is not
good.
In Level 2, the Documentation is better, but still there is no Automated Tool for
Testing the Software. Some Capture Tools like VCR or Tape Recorder is used to capture
the Strokes from the Key Board or Clicks from the Mouse. Thus, this Level also cannot
produce a good quality Testing.
37
CHAPTER 4
38
C7
Each project needs its own effective Software Verification & Validation Plan
tailored for the project. The Plan may be modified at times in response to major changes. V
& V Planning, which can be thought of an integrated part of overall Project Planning, may be
broken down in to the following steps :
REQUIREMENT PHASE
V&V
The Requirement Phase is the period during which, the Functional and Nonfunctional capabilities of a Software product are defined and documented. This phase
describes and specifies :
System Boundary
Software Environment
Software Functions
Software Constraints
Software Interfaces
Software Data
Software Algorithm
Software States
Software Error Conditions
Software Standards
Hardware Interfaces
Requirements Phase V & V
For Critical Softwares, this includes :
39
40
Using Criticality Analysis of the Code components to determine which Code to Evaluate
Ensuring that the Coding Standard is understood
Ensuring that the Coding Standards are available to the Staff before coding starts
Defining how to evaluate Code Quality Attributes
Identifying Code Analysis Tools that may be used
41
Besides the above phases, V & V Tasks are also spread over the Test, Installation as
well as Operation and Maintenance Phases.
ACKNOWLEDGEMENT
42
The notes on Software Engineering are prepared taking reference from following books:
1.
2.
3.
Software Engineering IEEE Standards 1059 (V&V), 1074 (Life Cycle Process), 730
(SQAP)
Most of the typing are done by my wife Gouri Pal and Daughters Kasturi & Poushali
43