I am a tester in a development team, we are working on a project designed with Delphi(the main part) and part in c and c++ (with MFC), that uses MSSQL (SQL 2000 or MSDE).
I was instructed to search for testing automation options, packages, tools, applications, etc. Our most critical, critical issue is regression testing.
What do you recommend?
kfaday wrote: what do you mean with: What are your requirements ?
Well, do you need complete, automatic testing with no human intervention? This requires that the testing tool capture screen shots, output file/database interactions, etc., and compare them to a known "good" run.
OTOH, if you just want something that will generate some mouse movements, clicks, and keyboard input, then you will have to manually inspect each screen and each db write, to make sure they are correct.
Most test environments use some kind of "scripted" technique to run thru regression tests for previous bug fixes, etc. However, sometimes human interaction is required. For example, suppose that a bug was fixed related to excessive flickering when a dialog was resized. It would be difficult to check the fix in a completely automatic way. Even describing it takes longer than just grabbing the dialog and resizing it!
Finally, you have to look at how many screens there are - are they dense, packed with controls? Is another application invoked? Are there external dependencies, such as waiting for a file to arrive on a server before some action is performed? Is it client/server, so that both the client and the server must be set up to reproduce the bug?
I would also suggest looking thru your bug log and asking, If I had a test tool, what would it have to do to recreate this bug? The types of bugs encountered is heavily dependent on the type of application, whether it has a GUI, client/server, etc.
Whatever you do, don't just buy something. Insist on a 30 or even better 60 day evaluation. Take your bug log and try some of the nasty ones. You might find that an inexpensive tool is better for your environment than an expensive one.
If you do go with something like WinRunner, you need to get some training. Don't let anybody talk you out of this.
I'm new to unit testing and I need some clarification. I want to test a class. When I create an instance of this class with the default constructor, I need to check 3 values and make sure they are initialised to the correct default values (for instance : a name property).
Do I have to code three tests (one for each value to test) or can I create one test for the default construction of the instance and check, in the same test, the 3 values ?
There is no good reason to test each value separately. Your "unit" consists of the class itself, I assume, and your unit test should verify the class as a whole. If there is something unique about the way values are accessed, then the test should take that into account. But if they're accessible as a group, go ahead. Your test also should include verification of the methods within the class, and should be structured so that all private methods are utilized during the test. If the class has any dependencies on other classes, make sure that you exercise them thoroughly. Ideally, you should also try testing error conditions; try things you never intended the class to do and check how gracefully it fails. Use out of range values, incorrect variable types, and edge-of-limit values if there are any limit tests required. As a general guide, try to imagine what the dumbest consumer of your class might attempt to do to it, then duplicate that in your test. We used to call that "dummy-proofing" before there was such a thing as formal unit testing, and it worked remarkably well.
"...putting all your eggs in one basket along with your bowling ball and gym clothes only gets you scrambled eggs and an extra laundry day... " - Jeffry J. Brickley