During the last years we used extreme programming as a technique in most projects.
Extreme programming makes testing an integral part of development and at the
same time reduces test time and improves stability a lot. A great part of testing
for extreme programming is done with automated test programs, validating every
part of the program separately. This helps to detect Problems at a Level, long
before they cause any trouble. A small glitch in a Library routine might easy
slip traditional QA methods, just because the circumstances are so limited for
the glitch to appear, that one could think it will nearly never ever do, but
believe me it will show up, 5 days after the program was installed on hundreds
of maschines. Then the first trouble reports come in, and there seems to be
no preceivable pattern in them, the application just crashs, perhaps even distroys
valuable data. There might be no way to debug while the live program is running
on a customer machine, but the Bug has to be fixed. With a lot of luck the Error
can be reproduced on a development machine, what still does not mean anyone
finds the cause, just because the problem is so far away from the symptom that
it would be complete luck to find it this way. Believe me, I have been there.
There are Companies out there that will sell you pricy compilers with faulty
libraries and charge you up front for reporting Errors.
Never take anything for granted. When you buy a piece of land you should check
for sinkholes before you build the house, because the best foundation will not
be strong enough to hold your house when you built it on a sinkhole. Extreme
Programming is a bit like the building inspector that comes out after every
step of the construction and checks the work that was done, that way you detect
that your pipes might not be strong enough before you painted the wall and put
the furniture in. Because debugging is just like taking the whole house appart,
it will take at least twice as long as expected and still when you are finnished
you might have new pipes but still a big sinkhole under the floor.
We have a lot of experience in this EP and in code auditing. Testing the complete system is still important to rule out conceptual combination or program flow failures, but to really create a robust, secure application, code auditing and repetitive modular testing is a necessity.
Black box tests try to test the system without knowing what the system does or is supposed to do.In an ideal world a blackbox Test would cover every possible Input that can be made resulting in every possible output that then has to be verified. What in Theory sounds to be a good idea because it make software testing scientifically verifyable is in the real world not always possible or a good idea! Testing a blackbox without any knowledge of expected behavior does not make sure we realy know how to work the box. If the box processes a sequenze of data on one input while only single data on other inputs it will be hard to test that behavior without knowing about it.
So in the real world most tests are grey box test, tests where the expected function is known and some effort is made to supply data that makes sense for the box... Oops bubytrap: the tester knowing the expected performance of the box might easily be misslead to test exactly how the box is expected to react, but maybe he overlooks what the box is not to do because he did not test for the right out of bounds exceptions. So while on the one hand knowledge about the expected behavior make testing for this box possible in the first place, that same knowledge might render the test useless.
Now lets talk about what some schoolars still see as a risk in development. The tester know exactly not only how the box is supposed to behave but he can look inside and see what the box does to do so. Used the right way, this is actually the best test one can perform but you have to be very cautious not to drop in the same pitfall as the greybox tester, you have to do better. The important thing about a white box test is to choose the right data to test.
The last point is exactly where the white box has the advantage over the grey box. When you did into the code you can check for every branch, every exception and make sure to provide a testcase for every of them, how unlikely ever they are to happen.
So, good luck testing!
[Philosophy] [Products] [Services] [Company] [Support] [KnowHow] [Contact] [Specials] [Links]
(c) 2001-2004 Explido Software USA Inc.
NEW Phone number 1 (863) 248 1195
or 1 (800) 348 5129
Explido Software USA Inc. is a small private owned IT Service
company in central Florida. From our location in Lakeland, Polk County we service
the whole Tampa and Orlando area. Our main areas of business are
IT Counseling, Software Development,
Linux Server
Systems and Web Marketing.
This Web Site is brought to you by Explido Software USA
Inc. We hope the Information on our Site is helpful for you however we give
no guarantees for the Information on our Web Site If you want to process, store
or republish the Information on this Web Site in any way not associated with
the normal use of the Internet, as in search-engines, browser caches, proxy
servers, etc., you need our written consent.