whitebox vs. blackbox testing
rsspruell
both wbox and blbox testing. What exactly is the difference between the
two? Should one method be tested before the other?
curious
WD
box is testing from a user's standpoint, someone who knows nothing about how
the product was made, its architecture, etc....and only wants to use it.
Both forms of testing will reveal bugs that the other might not, so both
must be implemented.
rsspruell wrote in message <92472715...@news.remarQ.com>...
Zhenya Rozinskiy
have to know is who system works and what to expect from it. Depending on
tester's level you are going to get differen level of bugs reports and
problem found.
White box testing is done on programming level. For example API testing.
Writing tools to do performance testing. You need someone who will use
your system and work with a code produced by developers directly. Also a
lot of times white box tester will modify a code to use Code coverage
tools or to insert some hooks to be able to test some specific function
Zhenya Rozinskiy
Manager, Quality Assurance
Moai Technologies, Inc.
dz...@my-dejanews.com
"rsspruell" <removethist...@ftbms.com> wrote:
> I have heard many different things about the advantages and disadvantages of
> both wbox and blbox testing. What exactly is the difference between the
> two? Should one method be tested before the other?
>
> curious
>
>
of the code.
blbox is user testing. You don't know the code, you become the user
who uses the product.
Both tests need to be performed. I tend to emphasize on blbox testing
first. My argument is that the customers (users) are the most important
to please. The customers don't care what your code looks like or
whatever bug you have in your code, they only care if the product work
as it's supposed to do.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Janusz Szpilewski
>
> Should one method be tested before the other?
>
As it concerns the most recommended testing order, white box tests
should be performed first to test code quality. Their role is to pass
all paths in the code and execute all loops with 0,1,more iterations to
check if the code really works as it is supposed to and will not cause
an unexpected crash. It would be advantageous if those tests were
performed by the developers themselves as their know best the code they
wrote and can quickly introduce corrections if such are needed.
If the code is proven to work well, then it can be tested if it does
what is expected to. It is done with black box tests basing on analysis
of module/program input and output and checking if it conforms to a
given product specification.
If any anomalies are detected at this stage they must be analyzed to
decide if they come from coding or design level and passed to be
corrected. That usually requires another iteration of
design/coding/wbt/bbt.
Greetings,
Janusz Szpilewski
ATM Software Tester
Alcatel CIT
Annemarie Martin
first, based on your definitions, you are able to better isolate and trace problems
found at the bl box level.
Janusz Szpilewski
>
> I tend to emphasize on blbox testing
> first. My argument is that the customers (users) are the most important
> to please. The customers don't care what your code looks like or
> whatever bug you have in your code, they only care if the product work
> as it's supposed to do.
It may be solution if time constraint is a really important factor i.e.
in prototyping phase when it is important to demonstrate product
functionality to the customer as soon as possible.
However if we consider the final product, making white box tests at the
beginning allows fast locating and fixing some bugs coming from simple
programming mistakes. For instance incorrect value of loop iterations
will be easily seen in the code but from black box point of view it may
be detected as an invalid calculation result what requires a longer path
(communication between different persons/departments) in locating and
fixing the bug.
The main argument for white box tests first is that they allow quick fix
of obvious bugs. Black box testers may be really upset having to deal
with a heavily crashing program. Also in this case their test reports
cannot be very accurate what brings another delay in product delivery.
Anyway the test strategy should be suited to the kind of product being
tested. One is suitable for a great enterprise delivering long live
commercial products and a different one for a single contractor writing
small programs on demand.
tester...@my-dejanews.com
"rsspruell" <removethist...@ftbms.com> wrote:
> I have heard many different things about the advantages and disadvantages of
> both wbox and blbox testing. What exactly is the difference between the
> two? Should one method be tested before the other?
>
> curious
>
>
Read the FAQ for this newsgroup. It was posted on April 20 by Danny Faught.
--
Guy Jackson
Design Validation Testing Engineer
MTI Technology Corporation
Kristian Damm Jensen
dz...@my-dejanews.com wrote:
> In article <92472715...@news.remarQ.com>,
> "rsspruell" <removethist...@ftbms.com> wrote:
> > I have heard many different things about the advantages and disadvantages of
> > both wbox and blbox testing. What exactly is the difference between the
> > two? Should one method be tested before the other?
> >
> > curious
> >
> >
> wbox is functional test, unit test. You test it based on your knowledge
> of the code.
> blbox is user testing. You don't know the code, you become the user
> who uses the product.
> Both tests need to be performed. I tend to emphasize on blbox testing
> first. My argument is that the customers (users) are the most important
> to please. The customers don't care what your code looks like or
> whatever bug you have in your code, they only care if the product work
> as it's supposed to do.
I agree, that if you can't do both, emphasize the black box test. But beware: it is
very hard to design a black box test, that covers each and every statement of the
code. A good black box test will take you to a coverage of about 80%.
You use a white box test to froce the program into all corners of the code, to make
sure that no errors lurk in the background. Black box checks - as said - that the
program performs the job the user wants.
But there really is not reason to make one before the other, iff both are to be
performed.
Regards,
Kristian
Xie Min
: I have heard many different things about the advantages and disadvantages of
: both wbox and blbox testing. What exactly is the difference between the
: two? Should one method be tested before the other?
I think people normally use "grey-box" testing...
Bill
of
>both wbox and blbox testing. What exactly is the difference between the
>two? Should one method be tested before the other?
>
Having read all posts to this subject to date, I'll wade in.
White (Glass?) box testing, IMHO, involves intimate knowledge of THE CODE.
Someone who knows the code well tests it to see if there iare any logic or
other flaws in it. They should also(?) perform a thorough functional test -
just to make sure it really does what it is supposed to do. The
qualifications for a white box tester sound to me like a good fit for the
programmer themself. Unfortunately, the programmer knows too much about the
code and isn't likely to follow all paths - especially when they have a "get
it out the door on time or else!" manager breathing down their neck. This
means much testing will not be done.
Black box testing, IMHO, is where someone first tries to determine if the
thing realy does everything it is supposed to do without knowing the guts of
the program. Then the tester attempts to make the software do things it
SHOULDN'T. This takes a talented tester who thoroughly understands what the
product is supposed to do and has a clear picture of what they wold't accept
if the thing were foisted off on them.
It would appear to resolve to a process of answering a few basic questions.
BBT answers whether the thing works.
WBT attempts to answer:
1) does it do everything (and I do mean EVERYTHING) it is supposed to do?
and
2) Does it do anything it should NOT do?
If time is at a premium, the second question may be simplified using a
severity/likelyhood grid and concentrating on the most likely and most
costly failure modes.
The company I work for produces multiple indemendant modules which run in
Win NT. If I have my way we will certify every module in a simplified test
system and then certify various configurations. We're not there yet. I'm
testing a configuration with four major/critical modules not previously
individually certified. Can you spell nightmare, boys and girls? But we've
gotten the system to a state where it is mostly stable. And I did it all
via black box testing. I just had to get REALLY far into the proper
operation of the box.
Bill Mullins
Bil...@txconnect.com
Bill_M...@autogas.com