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


Ratings: (0)|Views: 52|Likes:
Published by api-3738458

More info:

Published by: api-3738458 on Oct 16, 2008
Copyright:Attribution Non-commercial


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





What's the difference between load and stress testing ?

One of the most common, but unfortunate misuse of terminology
is treating "load testing" and "stress testing" as synonymous. The
consequence of this ignorant semantic abuse is usually that the system
is neither properly "load tested" nor subjected to a meaningful stress

1.Stress testing is subjecting a system to an unreasonable load
while denying it the resources (e.g., RAM, disc, mips, interrupts,
etc.) needed to process that load. The idea is to stress a system to
the breaking point in order to find bugs that will make that break
potentially harmful. The system is not expected to process the
overload without adequate resources, but to behave (e.g., fail) in a
decent manner (e.g., not corrupting or losing data). Bugs and failure
modes discovered under stress testing may or may not be repaired
depending on the application, the failure mode, consequences, etc.
The load (incoming transaction stream) in stress testing is often
deliberately distorted so as to force the system into resource

2.Load testing is subjecting a system to a statistically
representative (usually) load. The two main reasons for using such
loads is in support of software reliability testing and in
performance testing. The term "load testing" by itself is too vague
and imprecise to warrant use. For example, do you mean representative
load," "overload," "high load," etc. In performance testing, load is
varied from a minimum (zero) to the maximum level the system can
sustain without running out of resources or having, transactions
suffer (application-specific) excessive delay.

3. A third use of the term is as a test whose objective is to
determine the maximum sustainable load the system can handle.
In this usage, "load testing" is merely testing at the highest
transaction arrival rate in performance testing.

What's the difference between QA and testing?
Most testing jobs I see are nevertheless advertised as "QA". Some people
suggest that QC is a better set of initials to describe testing.
In my courses and my practice, I stick to the ANSI/IEEE
definitions, which agree with what is generally held *outside* the

software arena. The definitions boil down to:
* TESTING means "quality control"
* QUALITY CONTROL measures the quality of a product
* QUALITY ASSURANCE measures the quality of processes used

to create a quality product.
What is black box/white box testing?

Black-box and white-box are test design methods. Black-box test design
treats the system as a "black-box", so it doesn't explicitly use
knowledge of the internal structure. Black-box test design is usually
described as focusing on testing functional requirements. Synonyms for

black-box include: behavioral, functional, opaque-box, and
closed-box. White-box test design allows one to peek inside the "box",
and it focuses specifically on using internal knowledge of the software
to guide the selection of test data. Synonyms for white-box include:
structural, glass-box and clear-box.

While black-box and white-box are terms that are still in popular use,
many people prefer the terms "behavioral" and "structural". Behavioral
test design is slightly different from black-box test design because
the use of internal knowledge isn't strictly forbidden, but it's still
discouraged. In practice, it hasn't proven useful to use a single test
design method. One has to use a mixture of different methods so that
they aren't hindered by the limitations of a particular one. Some call
this "gray-box" or "translucent-box" test design, but others wish we'd
stop talking about boxes altogether.

It is important to understand that these methods are used during the
test design phase, and their influence is hard to see in the tests once
they're implemented. Note that any level of testing (unit testing,
system testing, etc.) can use any test design methods. Unit testing is
usually associated with structural test design, but this is because
testers usually don't have well-defined requirements at the unit level
to validate.

What do you like and dislike in this job?
Like: Finding faults with the code and driving an application to perfection. carrying out testing with

limited resources,limited time and limited effort and uncovering bugs is a very challenging &
creative task. it's very interesting,challenging by thinking about the application in the end user's
perception. it is interesting that we are doing destructive work but in the long term it is a
consructive work.

Dislikes: There is nothing that I can state as my dislike for my role as a tester.
Define quality for me as you understand it
It is a software that is reasonably bug-free and delivered on time and within the budget, meets the
requirements and expectations and is maintainable.
Describe the difference between validation and verification

Verification takes place before validation, and not vice versa. Verification evaluates documents,
plans, code, requirements and specifications. Validation evaluates the product itself. The input of
verification are checklists, issue lists, walkthroughs and inspection meetings, reviews and
meetings. The input of validation is the actual testing of an actual product. The output of
verification is a nearly perfect set of documents, plans, specifications and requirements.

Have you ever created a test plan?
I have never created any test plan. I developed and executed testcases. But I was
involved/participated actively with my Team Leader while creatiing Test Plans.
How do you determine what to test?
The duties of the software Tester is to go through the requirements documents and functional
specification and based on those documents one should focus on writing test cases, which

covers all the functionality to be tested. The tester should carry out all these procedures at the time of application under development. Once the build is ready for testing, we know what to test and how to proceed for the testing. Make sure, main functionality is tested first, so that all other testers can be ready for testing their modules/functionality.

How do you test if you have minimal or no documentation about the product?

based on previous experiance on that particular product we start testing .this is mainly called ad-
hoc testing. this type of testing conducting who knows the domain knowledge,frame work,use
cases, this type of testing conduting ad-hoc testing,sanity testing
in this situation i will try to test the application with the perception of end user.
i use my(or someones) previous experiences.
here we are not prepare any formal test plans and testcase documents.
most of the time we perform ad-hoc on this type of applications.

What is the purpose of the testing?

The purpose of testing can be quality assurance, verification and validation, or reliability
estimation. Testing can be used as a generic metric as well. Correctness testing and reliability
testing are two major areas of testing. Software testing is a trade-off between budget, time and
quality. the main course of testing is to check for the existance of defects or errors in a program or
project or product, based up on some predefined instructions or conditions.Also we can say that
the Purpose of Testing is to Analyse that the Product or project is according to Requirnments.

What are unit, component and integration testing?

Unit. The smallest compilable component. A unit typically is the
work of one programmer (At least in principle). As defined, it does
not include any called sub-components (for procedural languages) or
communicating components in general.

Unit Testing: in unit testing called components (or communicating
components) are replaced with stubs, simulators, or trusted
components. Calling components are replaced with drivers or trusted
super-components. The unit is tested in isolation.

component: a unit is a component. The integration of one or more
components is a component.

Note: The reason for "one or more" as contrasted to "Two or
more" is to allow for components that call themselves

component testing: the same as unit testing except that all stubs
and simulators are replaced with the real thing.

Two components (actually one or more) are said to be integrated when:
a. They have been compiled, linked, and loaded together.
b. They have successfully passed the integration tests at the

interface between them.

Thus, components A and B are integrated to create a new, larger, component (A,B). Note that this does not conflict with the idea of incremental integration -- it just means that A is a big component

You're Reading a Free Preview

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