Software Testing - Software Testing Large Project

Author

Software Testing Large Project

dotnetdesigner

2005-12-09, 7:27 pm

Hi,

Could someone please discuss with me what elements (including staff,
other resources, access to various parts of the test system and data,
etc.) that it would take for a test manager to succeed on our web
application project? It is a large online case entry/management type
system. It has 70 plus total web pages; some are reporting but many are
data entry pages. There are typically two developers working full time
on the system and the code that they are producing seems to be low
quality based on the number of errors that we are finding. The
underlying code itself is very complex with integration with more than
nine other systems, one that includes an AI engine that manages the
business rules. The system also has a separate application piece that
runs on a Tablet PC, accepts data entry, and then syncs up at a later
time with the main database.

Many times when we have tried to make manual test cases we have found
that there is no way to discern the correct behavior of the system
without asking someone (dirty system?).

I am a software architect by profession and realize how important
testing is to our long-term success. I would like to draw upon the
practical experience of professional software testers. Any help would
be appreciated.

Thanks,
Shawn

2005-12-09, 7:27 pm

On Fri, 9 Dec 2005, dotnetdesigner wrote:

> Hi,

Hello.

> Could someone please discuss with me what elements (including staff,
> other resources, access to various parts of the test system and data,
> etc.) that it would take for a test manager to succeed on our web
> application project? It is a large online case entry/management type
> system. It has 70 plus total web pages; some are reporting but many are
> data entry pages. There are typically two developers working full time
> on the system and the code that they are producing seems to be low
> quality based on the number of errors that we are finding. The
> underlying code itself is very complex with integration with more than
> nine other systems, one that includes an AI engine that manages the
> business rules. The system also has a separate application piece that
> runs on a Tablet PC, accepts data entry, and then syncs up at a later
> time with the main database.

I have to say the first thing that popped to mind reading this is, "Don't
use a screwdriver to hammer nails."

If the two developers are producing low quality code there is no point in
testing the system. You need to get unit testing in place. There is a
general rule of thumb that things become exponentially more costly the
further it is caught in the software development life cycle. If it costs
$1 to catch it at requirements it will cost $4 to catch it at design, $16
to catch it at unit testing, $256 to catch it at system testing, etc.

Without automated unit testing how are you going to know that something
they fixed today doesn't break something that was working yesterday? In
other words, if you cannot rely on the developers then you will have to
retest everything each time the developers fix anything.

> Many times when we have tried to make manual test cases we have found
> that there is no way to discern the correct behavior of the system
> without asking someone (dirty system?).

I believe this is the definition of insanity for testers. How do you test
something does the right thing if you don't know what the right thing is?

> I am a software architect by profession and realize how important
> testing is to our long-term success. I would like to draw upon the
> practical experience of professional software testers. Any help would
> be appreciated.

I'm guessing they don't have any requirements or design documentation.
First thing I would do is start reverse engineering these. I find Use
Cases helpful. I start creating Use Cases, what would an Actor do with the
system. I would then get agreement from the developers what the system
will do. If possible, get a unit test case in place that will validate the
requirements for the Use Case to succeed.

If you can get the different parts of the system defined then maybe you
can seperate the testing into parts. Help the developers create unit
testing. Until you do this it doesn't make sense to spend time system
testing.

Once the system has been broken apart into modules and unit tests created,
you can start working on integration and system testing. Then if you find
problems it should be easier for the developers to find and fix them. Plus
with unit testing in place you can feel assured that one fix isn't going
to create new problems.

--
Send e-mail to: darrell dot grainger at utoronto dot ca

Phlip

2005-12-10, 4:19 am

dotnetdesigner wrote:

> There are typically two developers working full time
> on the system and the code that they are producing seems to be low
> quality based on the number of errors that we are finding.

Then their velocity (say, 5 pages a w

, or the equivalent) is a lie, and
they are probably spending lots of their time debugging.

If they wrote the first level of unit tests, then the project would be more
likely to stay in control.

Any other formula would throw good money after bad.

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

Sponsored Links