In last week’s post, we started looking at CRUD testing. As you recall, CRUD stands for Create, Read, Update, and Delete. Last week we discussed testing Create and Update operations, and now we will continue by looking at Update and Delete.
In our discussion of the Read operation last week, I mentioned how important it is to test scenarios where the data in the database is invalid. This is also true for Update operations. Just because a text field is supposed to be required and have a certain number of characters doesn’t mean that’s how it is in the database!
Below is a matrix of testing scenarios for editing a text field. Remember from last week that our hypothetical text field has the following validation rules: it is a required field, it must have at least two characters, it must have 40 or fewer characters, and it should only have alphanumeric characters or hyphens and apostrophes; no other symbols are allowed. As with the Create operation, be sure to test that the newly edited field is correct in the UI and in the database after the update.
For the bad values that you are testing with, be sure to vary them so you are covering a number of different validation scenarios. For the good values that you are testing with, make sure to test hyphens and apostrophes, numbers and letters, and the upper and lower limits of the character count.
Finally, let’s discuss Delete. The main thing to test with Delete is that the value has been deleted from both the UI and the database. But just as with Read and Update, you’ll want to make sure that you can delete bad values. For example, if your First Name field has forty-one characters in it (violating the rule that only 40 characters or less should be added), you’ll want to make sure that you can delete it in the UI.
You may be wondering how to find all these invalid values for testing. While it is possible to find them by searching through the existing records, the easiest way to test them is to put them in yourself! This is why it’s important to know the appropriate query language, such as SQL, for your database.
For those who are wondering why testing with bad values is important, I once had a scenario where I was testing contact information for a person. There were a number of incorrectly formatted phone numbers in the database. When I tried to update any of the contact information for the person, I got the message that the record couldn’t be updated, because there was invalid data present. This was true even if I was trying to update the invalid phone number in question! Please be sure to check for scenarios like these; your end-user will thank you!
