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!
CREATE PROC ListPeople
I think Jen meant adding or changing data, without changing the structure.
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.
My theory has always been that if you have to ask whether or not you need to test, you do.
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.
Just me (Sir to you)
Fog Creek Home