Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
Chapter 4

Chapter 4

Ratings:
(0)
|Views: 48|Likes:
Published by api-3738664

More info:

Published by: api-3738664 on Oct 18, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

03/18/2014

pdf

text

original

Chapter 4- Static Testing
Chapter 4:
Static Testing

"On November 4th the system did fail. This was caused by a minor programming error that caused the system to "crash", the automatic change over to the back up system had not been adequately tested, and thus the whole system was brought down".

Extract from the main conclusions of the official report into the failure of the London
Ambulance Service\u2019s Computer Systems on October 26th and 27th and November 4th 1992.
4.0 STATIC TESTING
4.1 Overview

Static testing techniques is used to find errors before software is actually executed and contrasts therefore with dynamic testing techniques that are applied to a working system. The earlier we catch an error, the cheaper it is, usually, to correct. This module looks at a variety of different static testing techniques. Some are applied to documentation (e.g. walkthroughs, reviews and Inspections) and some are used to analyze the physical code (e.g. compilers, data flow analyzers). This is a huge subject and we can only hope to give an introduction in this module. You will be expected to appreciate the difference between the various review techniques and you will need to be aware of how and when static analysis tools are used.

4.2 Objectives
After completing this module you will:
\u2022
Understand the various review techniques that you can apply to documentation and
code.
\u2022
Appreciate the difference between walkthroughs, formal reviews and inspections.
\u2022
Understand how static analysis techniques can detect errors in code.
\u2022
Understand two complexity metrics (lines of code and McCabe's metric).
4.3 REVIEWS AND THE TEST PROCESS
4.3.1 What is a review?

A review is a fundamental technique that must be used throughout the development lifecycle. Basically a review is any of a variety of activities involving evaluation of technical matter by a group of people working together. The objective of any review is to obtain reliable information, usually as to status and/or work quality.

4.3.2 Some history of reviews
1
Chapter 4- Static Testing

During any project, management requires a means of assessing a measuring progress. The
so-called progress review evolved as means of achieving this. However, results of those
early reviews proved to be bitter experiences for many project managers. Just how long can
a project remain at 90% complete? They found that they could not measure 'true' progress
until they had a means of gauging the quality of the work performed. Thus the concept of
the technical review emerged to examine the quality of the work and provide input to the
progress reviews.

4.3.3 What can be reviewed?

There are many different types of reviews throughout the development life cycle. Virtually any work produced during development can be (and is) reviewed. This includes, requirements documents, designs, database specifications, designs, data models, code, test plans, test scripts, test documentation and so on.

4.3.4 What has this got to do with testing?

The old fashioned view that reviews and testing are totally different things stems from the
fact that testing used to be tacked onto the end of the development lifecycle. However as
we all now view testing as a continuous activity that must be started as early as possible
you can begin to appreciate the benefits of reviews. Reviews are the only testing technique
that is available to us in the early stages of testing. At early stages in the development
lifecycle we obviously cannot use dynamic testing techniques since the software is simply
not ready for testing.

Reviews share similarities to test activities in that they must be planned (what are we testing), what are the criteria for success (expected results) and who will do the work (responsibilities). The next section examines the different types of review techniques in more detail.

4.4 TYPES OF REVIEW

Walk-through, informal reviews, technical reviews and Inspections are fundamental
techniques that must be used throughout the development process. All have their strengths
and weaknesses and their place in the project development cycle. All four techniques have
some ground rules in common as follows:

A structured approach must be for the review process.
Be sure to know what is being reviewed - each component must have a unique identifier.
\u2022
Changes must be configuration controlled.
\u2022
Reviewers must prepare.
\u2022
Reviewers must concentrate on their own specialization.
\u2022
Be sure to review the product, not the person.
2
Chapter 4- Static Testing
There must be:

\ue000Total group responsibility.
\ue000Correct size of review group.
\ue000Correct allocation of time.
\ue000Correct application of standards.

Checklists must be used.
Reports must be produced.
Quality must be specified in terms of:

\ue000Adherence to standards.
\ue000Reliability required.
\ue000Robustness required.
\ue000Modularity.
\ue000Accuracy.
\ue000Ability to handle errors.

4.5 REVIEW TEAM SIZE AND COMPOSITION
Problems with small teams must be avoided; bring in extra people, (perhaps use the Testing
Team) to bring extra minds to bear on the issues.

Opinion is often divided as to whether or not the author should participate in a review. There are advantages to both scenarios. Since specifications and designs must be capable of being understood without the author present, an Inspection without them tests the document. Another reason for excluding the author from the review is that there should be team ownership of the product and team responsibility for the quality of all the deliverables, maintaining ownership via the author runs against this.

Alternatively, including the author can be a valuable aid to team building. Equally, an author may well be able to clear up misunderstandings in a document more quickly than another team member, thus saving the reviewer valuable time. From a practical perspective however, it is worth remembering that an author is the least likely person to identify faults in the document.

The one person who should not attend reviews is the manager. If, as in some cases, the manager is also a contributor to the deliverables, he should be included but treated the same as other group members. It is important that reviewers are a peer group process.

4.6 TYPE 1, 2 AND 3 REVIEW PROCESSES

Review process is both most effective and universal test method and management needs to
make sure that review process is working as effectively as possible. Useful model for
manager is 1,2,3 model.

1, 2, 3 model is derived from work of first working party of British Computer Society
3

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->