Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
41Activity
0 of .
Results for:
No results containing your search query
P. 1
Testing

Testing

Ratings: (0)|Views: 798|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

Testing is a process used to help identify the correctness, completeness and quality of developed
computer software. With that in mind, testing can never completely establish the correctness of
computer software.

There are many approaches to software testing, but effective testing of complex products is essentially a process of investigation, not merely a matter of creating and following rote procedure. One definition of testing is "the process of questioning a product in order to evaluate it", where the "questions" are things the tester tries to do with the product, and the product answers with its behavior in reaction to the probing of the tester. Although most of the intellectual processes of testing are nearly identical to that of review or inspection, the word testing is connoted to mean the dynamic analysis of the product\u2014putting the product through its paces.

The quality of the application can and normally does vary widely from system to system but some of the common quality attributes include reliability, stability, portability, maintainability and usability. Refer to the ISO standard ISO 9126 for a more complete list of attributes and criteria.

Testing helps is Verifying and Validating if the Software is working as it is intended to be working.
Thins involves using Static and Dynamic methodologies to Test the application.
Because of the fallibility of its human designers and its own abstract, complex nature,software
development must be accompanied by quality assurance activities. It is not unusual for developersto

spend 40% of the total project time on testing. For life-critical software (e.g. flight control, reactor monitoring), testing can cost 3 to 5 times as much as all other activities combined. The destructive nature of testing requires that the developer discard preconceived notions of the correctness of his/her developed software.

Software
Testing
Fundamentals
Testing
objectives
include

1. Testing is a process of executing a program with the intent of finding an error. 2. A good test case is one that has a high probability of finding an as yet undiscovered error. 3.

A
successful
test
is
one
that
uncovers
an
as
yet
undiscovered
error.

Testing should systematically uncover different classes of errors in a minimum amount of time and with a minimum amount of effort. A secondary benefit of testing is that it demonstrates that the software appears to be working as stated in the specifications. The data collected through testing can also provide an indication of the software's reliability and quality. But, testing cannot show the absence of defect -- it can only show thatsoftware defects are present.

One Stop Testing has been developed to give all the information on Software Testing in one place. This
site contains the information on the following:
When Testing should start:

Testing early in the life cycle reduces the errors. Test deliverables are associated with every phase of development. The goal of Software Tester is to find bugs, find them as early as possible, and make them sure they are fixed.

The number one cause of Software bugs is theSpecification. There are several reasons specifications
are the largest bug producer.

In many instances a Spec simply isn\u2019t written. Other reasons may be that the spec isn\u2019t thorough enough, its constantly changing, or it\u2019s not communicated well to the entire team. Planning software is vitally important. If it\u2019s not done correctly bugs will be created.

The next largest source of bugs is theDesign, That\u2019s where theprogrammers lay the plan for their Software. Compare it to an architect creating the blue print for the building, Bugs occur here for the same reason they occur in the specification. It\u2019s rushed, changed, or not well communicated.

Coding errors may be more familiar to you if you are a programmer. Typically these can be traced to

theSoftware complexity, poor documentation, schedule pressure or just plain dump mistakes. It\u2019s important to note that many bugs that appear on the surface to be programming errors can really be traced to specification. It\u2019s quite common to hear a programmer say, \u201c oh, so that\u2019s what its supposed to do. If someone had told me that I wouldn\u2019t have written the code that way.\u201d

The other category is the catch-all for what is left. Some bugs can blamed for false positives, conditions that were thought to be bugs but really weren\u2019t. There may be duplicate bugs, multiple ones that resulted from the square root cause. Some bugs can be traced to Testing errors.

Costs: The costs re logarithmic- that is, they increase tenfold as time increases. A bug found and

fixed during the early stages when the specification is being written might cost next to nothing, or 10 cents in our example. The same bug, if not found until the software is coded and tested, might cost $1 to $10. If a customer finds it, the cost would easily top $100.

When to Stop Testing

This can be difficult to determine. Many modern software applications are so complex, and run in such as interdependent environment, that complete testing can never be done. "When to stop testing" is one of the most difficult questions to a test engineer. Common factors in deciding when to stop are:

\u2022
Deadlines ( release deadlines,testing deadlines.)
\u2022
Test cases completed with certain percentages passed
\u2022
Test budget depleted
\u2022
Coverage of code/functionality/requirements reaches a specified point
\u2022
The rate at which Bugs can be found is too small
\u2022
Beta or Alpha Testing period ends
\u2022
The risk in the project is under acceptable limit.

Practically, we feel that the decision of stopping testing is based on the level of the risk acceptable to the management. As testing is a never ending process we can never assume that 100 % testing has been done, we can only minimize the risk of shipping the product to client with X testing done. The risk can be measured by Risk analysis but for small duration / low budget / low resources project, risk can be deduced by simply: -

\u2022
Measuring Test Coverage.
\u2022
Number of test cycles.
\u2022
Number of high priority bugs.
Test Strategy:

How we plan to cover the product so as to develop an adequate assessment of quality.
A good test strategy is:
Specific

Practical

Justified
The purpose of a test strategy is to clarify the major tasks and challenges of the test project.
Test Approach and Test Architecture are other terms commonly used to describe what I\u2019m calling test

strategy.
Example of a poorly stated (and probably poorly conceived) test strategy:
"We will use black box testing, cause-effect graphing, boundary testing, and white box testing to test
this product against its specification."
Test Strategy: Type of Project, Type ofSoft ware, when Testing will occur, Critical Success factors,
Tradeoffs
Test Plan - Why
\u2022
Identify Risks and Assumptions up front to reduce surprises later.
\u2022
Communicate objectives to all team members.
\u2022
Foundation for Test Spec, Test Cases, and ultimately the Bugs we find.
Failing to plan = planning to fail.
Test Plan - What
\u2022
Derived from Test Approach, Requirements, Project Plan, Functional Spec., and Design Spec.
\u2022
Details out project-specific Test Approach.
\u2022
Lists general (high level) Test Case areas.
\u2022
Include testing Risk Assessment.
\u2022
Include preliminary Test Schedule
\u2022
Lists Resource requirements.
Test Plan

The test strategy identifies multiple test levels, which are going to be performed for the project. Activities at each level must be planned well in advance and it has to be formally documented. Based on the individual plans only, the individual test levels are carried out.

Entry means the entry point to that phase. For example, for unit testing, the coding must be complete and then only one can start unit testing. Task is the activity that is performed. Validation is the way in which the progress and correctness and compliance are verified for that phase. Exit tells the completion criteria of that phase, after the validation is done. For example, the exit criterion for unit testing is all unit test cases must pass.

Unit Test Plan {UTP}
The unit test plan is the overall plan to carry out the unit test activities. The lead tester prepares it
and it will be distributed to the individual testers, which contains the following sections.
What is to be tested?

The unit test plan must clearly specify the scope of unit testing. In this, normally the basic input/output of the units along with their basic functionality will be tested. In this case mostly the input units will be tested for the format, alignment, accuracy and the totals. The UTP will clearly give the rules of what data types are present in the system, their format and their boundary conditions. This list may not be exhaustive; but it is better to have a complete list of these details.

Activity (41)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Quang DO liked this
Abhimanyu Thakur liked this
kamakshyi liked this
nemuritorul liked this
kitty_bst liked this
shiva liked this
chandu6567 liked this
abhijeetk3 liked this

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)//-->