Often the first request I make when starting work on a new application, is to request the database schema. I thought (somehow) that this was a fairly typical tester’s first step but recently working with other testers I came to realize this might not be the case.
I thought I would quickly outline some of the things I learn from reading a database schema from a tester’s perspective.
Spread
I can gain a quick sense of how complex an application is just by seeing the model. In turn, knowing an app’s complexity helps me realize how intense SQL queries might become behind the scenes when I conduct searching testing from the front of the application.
Audit trails
I look around for tables with columns like created by, updated by, etc. Multiple timestamp entries on a table help me to watch for what (if any) objects have an audit trail. In turn, I view the objects as more sensitive for some reason and I look at those objects more closely.
Sensitive data
I look for encrypted fields. Will I be working with SSL pages? And if the password field isn’t encrypted, I’ve probably already found a bug.
Data types
I’ve written about data types before but in general, I like to know the types of data I’m working with. I especially look for large data types like blobs and texts. There’s opportunity (bug finds) in filling large objects and then running searches that tax the database.
Fat tables
I look around for tables that I think will grow in volume as the application ages. And I wonder what will happen to performance if when there’s more volume in those tables. I make arrangements for fattening up tables especially if I’m working in a pristine test environment where the data load is small and life for the application is too easy.
I could keep going, there is so much more to be said in being able to read schemas. In my view, database schemas are roadmaps and plenty can be picked up by reviewing one. In all reality what I’d like to do is build a class and offer teaching in this specific area. Maybe I will…