views:

69

answers:

3

I just finished (mostly) a major application that I've been working on for a little over a year (off and on). It is around 86k lines of code, 50k of those is from Visual Studio's auto-generated dataset. It's largely a GUI to interacting with the database, generating reports, etc. It deals with money and manages contracts so it is important for it to be as bug free as possible.

I've walked through the code, and ran the program myself. I, for the most part, cannot find more bugs. I am however, sure there are, I've just been working on the system so long I can't see them anymore. I know there are some, because of some intermittent issues I run across, but can never pinpoint.

How should I go about software testing in order to discover the remaining bugs?

+4  A: 

I know this is a little late, but have you heard of Test-Driven Development?

There are lots of tests you could build to discover the "remaining" bugs:

1) Unit tests

2) Integration tests

3) Behavior/Business/Acceptance tests

You could always attend a Developer Testing Bootcamp to get more ideas.

Lucas B
"A little late" is an understatement.
Johann Strydom
How would I integrate TDD on a largely Databound, GUI driven application?
Malfist
jdot
It might be too late for that. Almost all database interaction is handled by .NET's databinding.
Malfist
@Malfist You could still implement type 2 and 3 tests.
Lucas B
+2  A: 

You can involve some of your end users and do a beta test that way. The less experience they have with the application until now, the more likely they are to try things you didn't think of.

Johann Strydom
+2  A: 

Since you didn't use TDD to write it. Your best bet now is to add as many automated tests as possible to cover common scenarios. That way, when you do find bugs, and there are ALWAYS bugs in programs, you can hopefully minimize the risk to the rest of the system when you fix them.

Chad
+1: "add as many automated tests as possible". Start with the stuff that's easiest to specify and write tests for. Move on to the hard stuff once you have a base of tests running.
S.Lott