Fog Creek Software
Discussion Board




Table changes without code changes

I'm looking for arguements on whether or not testing should be required on a table only change (a table entry is added/changed/deleted from a table used by a program, but no actual source code in the program is changed).  If a developer makes a change to a table and not code, should this be reviewed  by QA?  My thought is yes.  An incorrect table change can cause a production problem just as an incorrect coding change can.  Input is appreciated. Thanks!

Jen
Thursday, April 24, 2003

CREATE PROC ListPeople
    @Criteria int
AS
    SELECT Name, Address, City, State
    FROM People
    WHERE FK=@Criteria


Now, if the "table only" change involves dropping the State field, what's the result? [grin]

Philo

Philo
Thursday, April 24, 2003

I think Jen meant adding or changing data, without changing the structure.

To which I say... heck yeah! I have introduced bugs and fixed bugs by changing data in tables.

As a rule of thumb, anytime you have to change data in a table by hand, it's cause for retesting. If the data changes as a part of some automated process that has already been tested (e.g. normal operation of the software) it's not.

Joel Spolsky
Thursday, April 24, 2003

I think changes to static data should always be tested.  Then again I tend to test too much.  If you have a database table of states and the next thing you know we add another state to the union, should you test that?  Probably.  Simply because the chances are that someone has a loop running with a hardcoded 50 somewhere in the 100,000 LOC.

Just my $0.02 among the $100.

Dave B.
Thursday, April 24, 2003

My theory has always been that if you have to ask whether or not you need to test, you do.

Over the years I learned that it's not the major data model changes or huge chunks of code changes that kill you, it's the "we'll just do this real quick" type of changes that go untested, break Production, and leave you sitting all alone in the office on Sunday evening hacking away on the code while everyone else in your department in calling you for status every 10 minutes.

Sometimes a simple string search through the code will remind you of something dumb you forgot to finish a few months ago, swearing at the time that "if we ever change X, I'll be sure to come back here and fix this".

Jeff MacDonald
Friday, April 25, 2003

As an example sometimes adding a NULL in a row (NULLs allowed) can get some queries to return "unexpected" results. Yes, the code should have anticipated the possibility of NULL's, but it might not have.

It also depends on the semantics. Sometimes data is realy meta-data (as in certain O-R mappings), which means a simple change in a row can have a huge impact.

Just me (Sir to you)
Friday, April 25, 2003

*  Recent Topics

*  Fog Creek Home