Re: How do I test a database?

John Jensen wrote: > Hey Guys. > I am trying to develop a test plan for and informix data > base. I am not > trying to test informix itself but I need to see if our developers > have set > it up correctly. Does any body have any ideas on what I need to > look at? 1. Do your constraints make sense and are they working like you want them to? 2. Check the definition of and data type of each column in each table after installation? 3. Is this a custom, one time installation or something that is going to be duplicated elsewhere? If it's to be duplicated, test the install. 4. What is the purpose of the database? What's it to be used for? Does it have a lot of custom user interface? Each user interface has to be tested and the interaction of different interfaces tested against each other? Do they put the data in correctly? Is it retrieved and displayed correctly? 5. If this system has a specific purpose, for instance accounting, you have to run the various accounting modules and verify that the output matches expectations. 6. Check the purpose and use of each stored procedure. 7. Are the key fields defined in indexes correctly? 8. Are there batch level transactions being fed into the database? Does the program to do this work? 9. Is the data being exported to anyone? Is it correct? 10. Can users access their data? Is critical data protected? 11. Can critical data be modified by incorrect users? 12. Does the archive and retrieval work correctly? 13. Can the system recover from a crash or a lockup? 14. Do you have the administration tools working? Frankly, this is such an open ended question I hardly know what to say. I see testing as an integral part of requirement gathering and system design. I like testers to be involved in each phase and I want them to be enough of a developer to be able to envision those parts of a system that will need particular attention. Interfaces of all kinds seem to be particular bugaboos. With the testers involved in the design "bull sessions" they see and hear first hand how things are going together and can design tests to fit those situations. In this way the tests are in place before the system is built since the test plan develops along with the system design. All documents are living to me, so things can change. Now if you are at the other end of the spectrum and have to test after the fact. I don't happen to think anything is going to replace fairly long hours of studying the schema and the applications for what it is and what they do. Then you design tests to see if they do that. I have taken some fine courses on software testing design and implementation. I like Boris Beizers' book on Software Testing Techniques and a course by the Software Practices Research Center called STEP. The center is in Jacksonville. While these courses don't address databases only they provide a foundation for building a methodology. Good Luck. :)