Reasonable approach to testing complex software when there's a minor change
I'm involved in a software testing group, it's the basic testing of an existing enterprise system. My question is about testing a fairly complex piece of software, that does this and that, and then inserts data into an Oracle table.
How do you test something like this "to the penny"? In order to have an independent test, you'd kind of have to build the same logic separately. Then if the program changes, you'd have to update your testing module.
Nevertheless, this is a system test and not a unit test. But still, to balance "to the penny", this is more than a causal glance at the numbers, "Hey, looks good!"
In my example, the logic retrieves data from Oracle where [such and such] = A, B, or C, and we changed the logic to add D, E, F. I'm inclined to inspect the code as our verification method. But to write a query to test this, I'm thinking I have to build the actual logic from the program.
Just looking for a reasonable approach to this.
How do you test something like this "to the penny"? In order to have an independent test, you'd kind of have to build the same logic separately. Then if the program changes, you'd have to update your testing module.
Nevertheless, this is a system test and not a unit test. But still, to balance "to the penny", this is more than a causal glance at the numbers, "Hey, looks good!"
In my example, the logic retrieves data from Oracle where [such and such] = A, B, or C, and we changed the logic to add D, E, F. I'm inclined to inspect the code as our verification method. But to write a query to test this, I'm thinking I have to build the actual logic from the program.
Just looking for a reasonable approach to this.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Kyle, those are great links, thank you!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Kathy,
excellent, thank you.
>>That way, you don't have to reimplement the code. Instead, you reimplement the desired result.
- great perspective
>>the best tests are the ones that don't look at what the change does, but rather look at the results of the change
- great point
>>I'm as big of a believer in good inspections as in testing. :)
- totally agree!
excellent, thank you.
>>That way, you don't have to reimplement the code. Instead, you reimplement the desired result.
- great perspective
>>the best tests are the ones that don't look at what the change does, but rather look at the results of the change
- great point
>>I'm as big of a believer in good inspections as in testing. :)
- totally agree!
ASKER
thanks for the discussion!
ASKER
thanks, just looking for a reasonable approach. One takeaway of your comment is that there needs to be a toolkit of testing components.
Your suggestion is more of an integrated test as I understand. A full system test is still another approach.