The CRUD Approach

With the knowledge of "what" and "how" to test, let us go one more step forward in testing. Majority of the tests fall under the category of functionality. Functionality is nothing but the way the software responds to its inputs based on the programmed logic. The functionality itself can be broken to smaller pieces to make it simple. Here is a CRUDe way to do it.


Let us take a simple social networking application. You can create a new account, edit your profile, add a friend, delete a friend, add comments, delete comments, reload your photograph, view the comments by others etc. Take an instant messenger like Skype. You can add a contact, rename the contact, edit your text, delete a contact etc. Look at a documenting tool like MS Word. You can create a document, modify its contents, rename it, delete some portions of it etc.


So, what do you see as a common set of activities in all the above? Add something, edit or modify it, read or view it, delete it. In other words, Create Read Update Delete and that is CRUD. There is no exception to this in software. Every software will have to necessarily support these features; so if we chase these, we can test a software in a structural manner. Once you read the specifications of the software, see whether that requirement falls under create or read or update or delete. Once you identify that, you can blindly apply the following test conditions to that particular requirement.


If the requirement falls under Create (also termed as New, Add, Insert) category, you need to define test conditions for:

1. Creating a brand new item one at a time
2. Creating a duplicate item
3. Creating more than one items in a single shot (if applicable)

If the requirement falls under Read (also termed as View, Select, Open) category, you need to define test conditions for:

1. Reading an existing item one at a time
2. Reading more than one existing items at a time
3. Reading a non-existing item
4. Reading in a sorted order (such as sort a grid in ascending or descending order)
5. Read an item based on wild cards (such as search or filter items)

If the requirement falls under Update (also termed as Edit, Modify, Change) category, you need to define test conditions for:

1. Update an existing item one at a time
2. Update more than one existing items 
3. Update a non-existing item 

If the requirement falls under Delete (also termed as Remove, Trash, Erase) category, you need to define test conditions for:

1. Delete an existing item one at a time
2. Delete more than one existing items 
3. Delete a non-existing item 

So, if we apply this CRUD method to every single requirement, we start getting more and more branches for every such operation. 

What is the guarantee that most of the software operations are restricted to only this CRUD concept? If you look at any database, you can see just four important operations - SELECT, INSERT, UPDATE and DELETE. Whether it is Oracle or MySQL or MS SQL or DB2, all use these 4 operations day in and day out. And ultimately every software must deal with a database  to finally store the data. Hope this is quite a convincing argument.

For more in testing, please visit http://www.openmentor.net.