Solution: Establish a Big-Tent Culture of Quality

Quality simply comprises testing for most software developers. But that’s only quality control and it’s only part of the story. The entire life cycle of software engineering involves quality assurance, which includes three parts:

1. Specifying project requirements clearly and in writing.
2. Designing and developing a solution for our requirements.
3. Validating and testing that our solution matches the requirements.

We need to do all three of these to perform QA correctly, although, in some software methodologies, we don’t necessarily have to do them in this order.

We can achieve quality assurance in database development by following best practices in documentation, source code control, and testing.

Exhibit A: Documentation

There’s no such thing as self-documenting code. Although a skilled programmer can indeed decipher most code through a combination of careful analysis and experimentation, this is laborious. Also, code can’t tell us about missing features or unsolved problems.

We should document the requirements and implementation of a database just as we do with application code. Whether we’re the original designer of the database or we’re inheriting a database designed by someone else, we use the following checklist to document a database:

Entity-relationship diagram

The single most crucial piece of documentation for a database is an ER diagram showing the tables and their relationships.

Several chapters in this course use a simple form of ER diagrams. More complex ER diagrams have a notation for columns, keys, indexes, and other database objects.

Some diagramming software packages include elements for ER diagram notation. Some tools can even reverse-engineer an SQL script or a live database and produce an ER diagram.

One caveat is that databases can be ...