LifeCycle Components

1
CHAPTER 4

• Life-Cycle Components

2
Learning Objectives

• To discuss
• Integrating quality activities in the project
  life cycle
• Reviews
• Software testing
• Integrating quality in software maintenance

2
BCS3263 Software Quality Assurance
SemII0809 BARIAH YUSOB
3
Software testing - strategies

• Definitions and objectives
• Software testing strategies
• Software test classifications
• White box testing
• Data processing and calculation correctness
  tests
• Correctness tests and path coverage
• Correctness tests and line coverage
• McCabes cyclomatic complexity metrics
• Software qualification and reusability testing
• Advantages and disadvantages of white box
  testing
• Black box testing
• Equivalence classes for output correctness tests
• Other operation factor testing classes
• Revision factor testing classes
• Transition factor testing classes
• Advantages and disadvantages of black box testing

4
Software tests - definition
Software testing is a formal process carried out
by a specialized testing team in which a software
unit, several integrated software units or an
entire software package are examined by running
the programs on a computer. All the associated
tests are performed according to approved test
procedures on approved test cases.
5
Software testing objectives

• Direct objectives
• To identify and reveal as many errors as possible
  in the tested software
• To bring the tested software, after correction of
  the identified errors and retesting, to an
  acceptable level of quality.
• To perform the required tests efficiently and
  effectively, within the limits budgetary and
  scheduling limitation.
• Indirect objectives
• a. To compile a record of software errors
  for use in error prevention (by corrective and
  preventive actions)  

6
Software testing strategies

• Incremental testing strategies
• Bottom-up testing
• Top-down testing
• Big bang testing

7
Bottom-up testing
M11
Stage 4
Integration B
Integration c
M9
Stage 3
M10
Integration A
M8
Stage 2
M1
M2
M3
M4
M5
M6
M7
Stage 1
8
Top-down testing
Integration D
Integration C
Integration B
Integration A
M11
Stage 1
M9
M10
Stage 2
M8
Stage 3
M6
M7
Stage 4
M1
M2
Stage 5
M3
M4
M5
Stage 6
9
Use of stubs and drivers for incremental testing
Top-down testing of module M8
Bottom-up testing of module M8
Module tested in an earlier stage
M9
Drive of M9
M8
M8
Module on test
Module on test
Modules tested in an earlier stage
Stub of M2
Stub of M1
M2
M1
10
Black box and white box - IEEE definitions

• Black box testing
• Testing that ignores the internal mechanism of
  the system or component and focuses solely on
  the outputs in response to selected inputs and
  execution conditions
• Testing conducted to evaluate the compliance of a
  system or component with specified functional
  requirements
• White box testing
• Testing that takes into account the
  internal mechanism of a system or component

11
White box testing "Path" vs "line" coverage

• Path coverage
• Path coverage of a test is measured by the
  percentage of all possible program paths included
  in planned testing.
• Line coverage
• Line coverage of a test is measured by the
  percentage of program code lines included in
  planned testing.

12
The Imperial Taxi Services (ITS) taximeter
EExample ITS taxi fares for one-time passengers
are calculated as follows 1. Minimal fare 2.
This fare covers the distance traveled up to
1000 yards and waiting time (stopping for
traffic lights or traffic jams, etc.) of up to 3
minutes.  2. For every additional 250 yards or
part of it 25 cents.  3. For every additional 2
minutes of stopping or waiting or part thereof
20 cents.  4. One suitcase 0 change each
additional suitcase 1.  5. Night supplement
25, effective for journeys between 21.00 and
06.00. Regular clients are entitled to a 10
discount and are not charged the night
supplement.
13
ITS - Flow chart
1 Charge the minimal fare
D gt 1000
D 1000
2 Distance
3
4
WT gt 3
5 Waiting time
WT 3
6
7
8 No.of suitcases
S 1
S gt1
9
10
11 Regular client?
No
Yes
12
13
14 Night journey?
No
Yes
15
16
17 Print receipt.
14
ITS - Program flow graph
1
2
4
R1
3
5
7
R2
6
8
R6
9
10
R3
11
13
12
14
R4
15
16
R5
17
15
ITS - The minimum number of paths
for full line coverage
1
2
4
R1
3
5
7
R2
6
8
R6
9
10
R3
11
13
12
14
R4
15
16
R5
17
16
ITS - The maximum set of independent paths
V(G)R6 V(G)E-N221-1726 V(G)P1516
RRegions NNodes EEdges PDecisions
McCabes cyclomatic complexity metrics
17
Advantages and disadvantages of white box testing

• Advantages
•       Direct determination of software
  correctness as expressed in the processing paths,
  including algorithms.
• Allows performance of line coverage follow
  up.
•   Ascertains quality of coding work and its
  adherence to coding standards.
• Disadvantages
•   The vast resources utilized, much above
  those required for black box testing of the same
  software package.
• The inability to test software performance
  in terms of availability (response time),
  reliability, load durability, etc.

18
Equivalence class partitioning (EC)

• A black box method aimed at increasing the
  efficiency of testing and, at the same time,
  improving coverage of potential error conditions.

19
Equivalence class partitioning (EC)

• An equivalence class (EC) is a set of input
  variable values that produce the same output
  results or that are processed identically.
• EC boundaries are defined by a single numeric or
  alphabetic value, a group of numeric or
  alphabetic values, a range of values, and so on.
• An EC that contains only valid states is defined
  as a "valid EC," whereas an EC that contains only
  invalid states is defined as the "invalid EC."
• In cases where a program's input is provided by
  several variables, valid and invalid ECs should
  be defined for each variable.

20
Equivalence class partitioning (EC)

• According to the equivalence class partitioning
  method
• Each valid EC and each invalid EC are included in
  at least one test case.
• Definition of test cases is done separately for
  the valid and invalid ECs.
• In defining a test case for the valid ECs, we try
  to cover as many as possible new ECs in that
  same test case.
• In defining invalid ECs, we must assign one test
  case to each new invalid EC, as a test case
  that includes more than one invalid EC may not
  allow the tester to distinguish between the
  programs separate reactions to each of the
  invalid ECs.
• Test cases are added as long as there are
  uncovered ECs.

21
Entrance ticket price table - The Pool
22
Test cases - The ticket price module
23
Advantages and disadvantages of black box testing
Advantages     Allows us to carry out the
majority of testing classes, most of which can be
implemented solely by black box tests, i.e. load
tests and availability tests.     For testing
classes that can be carried out by both white and
black box tests, black box testing requires fewer
resources. Disadvantages     Possibility that
coincidental aggregation of several errors will
produce the correct response for a test case, and
prevent error detection.     Absence of
control of line coverage. There is no easy way
to specify the parameters of the test cases
required to improve coverage.
Impossibility of testing the quality of coding
and its strict adherence to the coding standards.
24
Integrating the quality in software maintenance
25
Software maintenance components
26
Software maintenance QA activities - objectives

• Assure, with an acceptable level of confidence,
  that the software maintenance activities conform
  to the functional technical requirements.
• Assure, with an accepted level of confidence,
  that the software maintenance activities conform
  to managerial scheduling and budgetary
  requirements.
• Initiate and manage activities to improve and
  increase the efficiency of software maintenance
  and SQA activities. This involves improving the
  prospects of achieving functional and managerial
  requirements while reducing costs.

27
The foundation of high quality

• Foundation 1 Software package quality
• Foundation 2 Maintenance policy

28
Foundation 1 Software package quality

• From McCall quality factor, factors that have
  direct impact on software maintenance
• Two product operation factors?
• Three product revision factors?
• Two product transition factors?

29
Product operation factors

• Correctness
• Output correctness
• No pre-specified output is missing
• All systems output are processed correctly
• Process information is up-to-date as specified
• Reaction times do not exceed the specified
  maximum values, especially in online and
  real-time applications.

30
Product operation factors

• Documentation correctness
• The quality of documentation completeness,
  accuracy, documentation style and structure.
• Coding qualification
• Compliance with coding instructions, especially
  those that limit and reduce code complexity and
  define standard coding style.

31
Product operation factors

• Reliability
• The frequency of system failures as well as
  recovery times.

32
Product revision factors

• Maintainability
• By following the software structure and style
  requirements
• By implementing programmer documentation
  requirement.
• Flexibility
• Theres more space for future functional
  improvement.

33
Product revision factors

• Testability
• Includes the availability of system diagnostics
  to be applied by the user as well as failure
  diagnostics to be applied by the support center
  or the maintenance staff at the users site.

34
Product transition factors

• Portability
• The softwares potential application in different
  hardware and operating system environments,
  including the activities that enable those
  applications.
• Interoperability
• Capacity to operate with other packages and
  computerized equipment.

35
Foundation 2 Maintenance policy

• The main maintenance policy components that
  affect the success of software maintenance are
• Version development
• Change policies to be applied during the
  softwares life cycle.

36
Version development policy

• A strictly one active version policy is quite
  preferable to a multi-version policy.
• Two form of version
• Sequential only 1 version to the entire
  customer population. Can be revised, but once a
  new version is completed, it will replace the
  current policy.
• Tree develop a specialized, targeted version
  for groups of customers.

37
Change policy

• Refers to the method of examining each change
  request and the criteria used for its approval.
• Balanced policy that approves only a small
  proportion of worthwhile changes as a result of
  its focus on the most important.
• Beneficial changes is preferable to a
  permissive policy that approves every change
  requested.

38
Pre-maintenance software quality components

• Maintenance contract view
• Maintenance plan construction

39
Maintenance contract view

• Objectives
• Customer requirement clarification
• Review of alternative approaches to maintenance
  provision
• Review of estimates of required maintenance
  resources
• Review of maintenance services to be provided by
  subcontractors and/or the customer
• Review of maintenance costs estimates

40
Maintenance contract view

• Activities
• Proposal draft reviews
• Contract draft reviews.

41
Maintenance plan

• Should be prepared for all customers, external
  and internal.
• Provide framework within which maintenance
  provision is organized.

42
Maintenance plan

• The plan includes the following
• A list of the contracted maintenance services
• A description of the maintenance teams
  organization
• A list of maintenance facilities
• A list of identified maintenance service risks
• A list of required software maintenance
  procedures and controls
• The software maintenance budget.

43
Maintenance software quality assurance tools

• SQA tools for corrective maintenance
• SQA tools for functionality improvement
  maintenance
• SQA infrastructure tools for software maintenance
• SQA tools for managerial control of software
  maintenance.

44
SQA tools for corrective maintenance

• Activities
• User support services
• Code and documentation failures, incomplete
  documentation.
• Software corrections (bug repairs)
• Bug repairs and documentation corrections
• Mini testing handle repair patch
  (small-scale) tasks, caused by a small number of
  coding line changes together with intense
  pressure to complete the corrections rapidly.

45
Guidelines for assuring the mini testing quality

• Testing is to be performed by a qualified tester,
  not by the programmer who carried out the repair.
• A testing procedure document should be prepared.
• A test report fully documenting the errors in
  each stage and re-testing should be completed.
• The leader of the testing team should review the
  testing document for the scope of corrections,
  test cases and results ? approve the repaired
  software.

46
The tools for user support services

• Commonly, use subcontractors maintenance
  services.
• The SQA tools integrated into the contract focus
  on
• Procedures for handling a specified range of
  maintenance calls.
• Full documentation of the service procedures.
• Availability of records documenting professional
  certification of the subcontractors maintenance
  team members, for contractor review.
• Authorization for the contractor to carry out
  periodic review of the maintenance services as
  well as customer satisfaction surveys.
• Quality-related conditions requiring imposition
  of penalties and termination of the
  subcontracting contract in extreme cases.

47
SQA tools for functionality improvement
maintenance

• Due similarity of functionality improvement
  maintenance tasks to software development project
  tasks, project life cycle tools (review and
  testing) are regularly applied for functionality
  improvement maintenance.

48
SQA infrastructure components for software
maintenance

• SQA infrastructure tools
• Maintenance procedures and work instructions
• Supporting quality devices
• Training and certification of maintenance teams
• Preventive and correction actions
• Configuration management
• Documentation and quality record control.

49
Maintenance procedures and work instructions

• Mostly applied for corrective maintenance and
  user support activities
• Remote handling of requests for services in cases
  of software failure
• On-site handling of customer requests for service
  in cases of software failure
• User support service
• Quality assurance control of software correction
  and user support activities
• Customer satisfaction surveys
• Certification of corrective maintenance and user
  support team members.

50
Supporting quality devices

• Checklists for location of caused for a failure
  to be applied by the maintenance technician.
• Templates for reporting how software failure were
  solved, including findings of the correction
  process.
• Checklists for preparing a mini testing procedure
  document.

51
Training and certification of maintenance teams

• Not differ from the other development team.
• However, special training and certification are
  crucial for corrective maintenance teams, because
  of the need to supply the services specified in
  maintenance contracts on a continuous basis.

52
Preventive and corrective actions

• Records of software failures and their repair as
  well as records of user support requests can lead
  to preventive and corrective actions ? improve
  the existing and new software systems.
• Activities/actions
• Screening the collected information
• Reviewing and analyzing findings
• Devising recommendations for improvements of
  relevant development and maintenance processes.

53
Configuration management

• Two common applications relying on configuration
  management
• Failure corrections
• Information regarding the version of the software
  installed at the customers site
• A copy of current code and its documentation.
• group replacement of currently used version of
  the software by a new version
• group? all customers having the same software
  version.
• Decision making based on the extent of
  replacement and the type of contracts signed with
  the customers.
• Planning the group replacement, allocating
  resources and determining the timetable.

54
Maintenance documentation and quality records

• Closely related to software correction and user
  support activities.
• Documentation and quality records are prepared in
  order to
• Supply vital data for preventive and corrective
  actions
• Support the handling of future customer failure
  reports and user support requests
• Provide evidence in response to future customer
  claims and/or complaints.

55
Managerial control SQA tools for software
maintenance

• Meant to improve control of maintenance by
  creating early alarms that signal reduced quality
  of service and increasing rates of service
  failures.
• Issues
• Performance controls for corrective maintenance
  services
• Quality metrics for corrective maintenance
• Costs of software maintenance quality.

56
Performance controls for software maintenance
services

• Software correction
• Increased resource utilization
• Decreased rate of remote failure repairs (low
  cost repairs) versus customers on-site repairs
• Increased rate of on-site repairs at
  long-distance locations and overseas services
• Increased percentage of failures to meet repair
  schedule requirements
• Increased rate of faulty repairs, and list of
  specific model cases of extreme failure
  situations
• Lower customer satisfaction based on customer
  satisfaction surveys.

57
Performance controls for software maintenance
services

• User support
• Increased rates of requests for service for a
  specific software system, for service type, etc.
• Increased resource utilization in user support
  services
• Increased rate of failures to provide requested
  consulting, and specific cases of outstanding
  failures
• Customer satisfaction information based on
  customer satisfaction surveys.

58
Quality metrics for software maintenance

• Used to identify trends in maintenance
  efficiency, effectiveness and customer
  satisfaction.
• Changes in trends, negative or positive, provide
  the quantitative basis for managerial decision
  making regarding
• Estimation of resource requirements when
  preparing maintenance plans for the next period
• Comparison of methods of operation
• Initiation of preventive and corrective actions
• Estimation of resource requirements as a basis
  for proposals for new or adjusted maintenance
  services.

59
Costs of software maintenance quality

• Prevention (error prevention)
• Maintenance team, preventive and corrective
  actions.
• Appraisal (error detection)
• Review of maintenance services and customer
  satisfaction surveys.
• Managerial preparation and control
• Preparation of maintenance plans, team
  recruitment and follow-up of maintenance
  performance.

60
Costs of software maintenance quality

• Internal failure
• Failure correction initiated by the maintenance
  team.
• External failure
• Failure correction initiated by customer
  complaints.
• Managerial failure
• Caused by managerial actions or inaction.
• Damages resulting from shortage of maintenance
  staff and/or inadequate maintenance task
  organization.

61
Costs of external failure of software corrective
maintenance activities

• Two maintenance periods
• The warranty period
• Usually 3-12 months after the software is
  installed.
• The contracted maintenance services period
• Begins at the end of the warranty period.
• Issues ? what situation should be considered as
  an external failure?

62
For software corrections

• All costs of software correction initiated by
  users during the warranty period are external
  quality costs because they are considered to
  result directly from software development
  failures? developers responsible.
• Software corrections performed during the
  contracted maintenance period are considered part
  of regular service ? regular service costs.
• During the contracted maintenance period, only
  costs of re-correction after failure of the
  initial correction efforts are considered
  external failure costs as the software technician
  failed in his regular maintenance service.

63
For user support services

• During warranty period, user support services are
  considered to be an inherent part of the
  instruction effort, and therefore should not be
  considered external failure costs.
• During the contracted maintenance period, all
  types of user support services ? are not external
  failure costs.
• During both maintenance period, an external
  failure ? when second consultation is required
  after the initial consultation proves to be
  inadequate.

64

• In general, maintenance quality cost information,
  together with other managerial control
  information, is expected to assist management in
  making decisions regarding
• Directions for investment in the improvement of
  maintenance services by indicating weak points of
  extremely high quality costs and strong points of
  extremely low quality costs.
• Development of an improved version of the
  software (in the case of custom-made software) or
  replacement of a purchased software package.