Information Technology Reference
In-Depth Information
set up, programmers can create new records, retrieve records, update records, and
delete records using the DBMS language totally independent of any application.
Back to the fi rst database testing, the tester needs to see if the data in the
databases can be managed per the application requirements. Using our previous
transaction fl ow example, the tester must be able to successfully add a new user
profi le, updating an existing user profi le, and deleting a user profi le just using
the DBMS commands. What this kind of testing validates is the viability of the
database design for the intended application. If the database design is not viable, then
the application can never maintain its data correctly regardless of the expertise of the
application programmers.
The second step is to test the application software's use of the validated database
design. This testing amounts to looking at the “back side” of the application
after successful fl ow testing has been completed. The test results may look good
on the screen; however, the testing question is “have those same results been
correctly managed in the database by the application?” This kind of testing is easiest
done by pairing up validated transaction fl ow screens with validated report fl ow
screens. If what is seen going into the transaction screens appears on the report
screens, chances are good (not 100%) that the underlying database structure that
supports these screens is being manipulated correctly.
Testing application databases requires cooperation and collaboration between
the tester and the database administrator due to the complexity of DBMS languages,
design, and operations.
7.4 AN APPROACH TO REGRESSION TESTING
The easiest way to describe regression testing is to quote the famous Humphrey
Bogart line in the movie Casablanca, “play it again, Sam.” The term itself means
to regress or go back to a less mature or less stable state. Applied to software,
regression testing means to search for software corrections that make the current
version less stable by unintentionally affecting code not directly related to the
corrections. If this topic sparks your interest, there are a number of good textbooks
that can give you more details and the results of current academic research.
[26-28]
Regression testing is normally started while new code is being written and
existing code is being corrected. The addition of new code or corrections to existing
code always raises the possibility that the new or changed code may accidentally
“break” the already tested code. The testing response to this possibility is to rerun all
successful test cases to date on a new build of the software. If the previously tested
code is not affected by the new or changed code, the previously tested code will
again pass all tests and the testing can go forward. If the regression testing discovers
defects, then the nature and location of the new or changed code is used to help di-
agnose the defect because the new or changed code is the number one suspect. Plan-
ning for regression testing includes standard approaches to writing test actions and
scripts so that they are rerunable and maintained in some kind of library to facilitate
Search WWH ::




Custom Search