[techtalk] Testing (Was: Re: Technical issues)

[Beverly Guillermo]

On Tue, 21 Nov 2000, Laurel Fan wrote:

> So, how do you test well?  What testing procedures and methodolgies
> should be used?  And how can adequate coverage be ensured?
> 

It's different from company to company.  It's also different depending on
what your program is expected to do.  It's also different depending on
what type of infrastructure you're going to use.  What do you want your
program to do?   The process should begin with an initial
feasibility proposal and that will eventually develop into a design
document which will contain requirements that will help create your test
cases.  In other words, it should contain all the answers to what is
needed for the program to work.  It also helps give a "projection" of the
release of the final project.

In my experience a well-written and thought out design document is
invaluable to the programmers and to the quality management teams.  Not
only does it provide what the program will do but what cases should be
thoroughly inspected to work out any bugs.  Testing is an extension of the
design process, at least my opinion. 

Once the design document is finalized, we try not to add anymore
requirements during the implementation phase.  Those extra additions that
are developed will be placed on the back burner, unless it's a must need,
just gotta have, feature.  Or if you're really talented and can work
it into the design without totally changing what the component is
meant to do.  Then, we think about how it will affect the entire project
as a whole.

The design document will help test whether a component works
well by developing cases on what it was expected to do.  Then, we
put the sub-components together and determined whether that entire
procedure works well overall.  This was our alpha testing, when we've
finally gotten all the requirements into a working program.  Here's where
most of the difficulty lies because some components just don't want to
work together.  It's the most stressing part, IMO.

The next step is to determine what is overlooked.  This phase is the beta
test of the software.  Usually, giving it to Quality Assurance.  They are
given a summary of what the user expects, from the design document, and
they develop their own test cases trying to break the software.  On rare
occassions, they find a really tricky one and it sometimes leads to
rewrites of certain components.

If the design document changes, it will help the others know
about the changes.  Of course, each component should be individualized
with no dependencies on other components.  This basically is a bad design
but that's a whole different question.  I've only developed two projects
but the hardest task was being in the design process on one
project.

> Scenario: 
> All of your fellow developers recognize the wisdom
> of testing, but some have no experience in more formal (meaning
> 'organized', not necessarily proofs of correctness) testing.  The
> project is written in C++, and makes extensive use of external
> libraries (in C and C++).  The application has a gui, and has a
> network component talking a well documented, standard protocol.  You
> are roughly in the beta stage, and your project is used by a few
> hundred people.
> 
> What factors would you take into consideration, and what
> would your plan look like?

I can't really answer this question without knowing the
requirements of the program. You've probably have done research on the
external libraries for them to actually do what you require.  But how will
it work within your program?  And what will your gui and the built-in
network component access and perform?  Of course I might be too
picky and not giving general answers to your question on testing. =)

Beverly


----------------------------------------------------------------------
mezanin at chno2.com                                 http://www.chno2.com