How best to model CRUD functionality?

  • 2
  • Question
  • Updated 6 years ago
  • Answered
Hi, I'm working on a model to add a user. The parameters and values are pretty simple - name, address, etc. I can add a user, edit an existing user or delete a user. I'm trying to decide if I should create a model for each action (add, edit, delete) or if there's a better way to do it and combine it all into one model (adding action as a parameter perhaps?). Thoughts or opinions?
Photo of Jan

Jan

  • 9 Posts
  • 0 Reply Likes

Posted 6 years ago

  • 2
Photo of Justin Hunter, Hexawise Founder

Justin Hunter, Hexawise Founder, Founder and CEO

  • 246 Posts
  • 15 Reply Likes
Jan,

Good question. Thanks for asking it.

I could think of a few different ways to model it. Let's review the simplest solution first then move to a few optional extra ideas that you could use in addition.

Option 1: Only one C, R, U, D action tested in each of your tests

Have one Parameter called "CRUD ACTION" - have 4 different values: Create, Read, Update, Delete

Option 2: Include two CRUD actions in (most of) your tests

Create 2 Parameters, each with the following 4 and 3 Values:

FIRST CRUD ACTION: Create, Read, Update, Delete
SECOND CRUD ACTION: Read, Update, Delete

You may want to add an Invalid Pair with the FIRST CRUD ACTION = Delete and each of the three Values in the SECOND CRUD ACTION (in which case you'd need to add a 4th Value called N/A and leave it as the only available option for scenarios that deleted a record in the first test.

Option 3: Up to 4 CRUD actions in each of your tests

Create a new record: create, don't create
Read a record: read, don't read
Update a record: update, don't update
Delete a record: delete, don't delete

That's the most basic modeling decision. (e.g., one CRUD action / test, two CRUD actions / test, or potentially 4 CRUD actions / test).

What other things might be interesting to vary?

You might want to think about "newspaper reporter questions" - e.g., (who, what, when, where, why? how? how much?)

Who?

Which user type (or which system) is performing the CRUD ACTION? - Are certain types of users or systems not allowed to perform certain actions? Include test inputs to make sure they can't. Are others allowed to? Include test inputs in your model to make sure they can.

What?

What kind of CRUD actions are being made? Valid ones? Invalid ones? How many invalid types of actions can you think of? What is supposed to happen when special characters are entered? What is supposed to happen when blanks are entered? What is supposed to happen when extremely long names are entered (e.g., are there concatenation rules?)

When?

When are the updates being made? Are there any system downtimes? What happens to CRUD actions that are attempted then? What happens if the time stamp on a CRUD action is from the future? From the past? Originates in a different time zone?

When? ("version 2")
When are the CRUD actions tested in relation to one another? e.g., Update a record and then try to read it or read it and then try to update it? If you wanted to "mix up the order" of the Option 3 actions, for example, you could add a Parameter called PERFORM CRUD ACTIONS IN WHAT ORDER? with Values such as normal C then R then U then D order, the reverse of the normal order as much as possible, start with R or O. This would not give you a "perfect solution" to cover every timing combination but it would lead to additional variability within your tests if you wanted them.

Why?

Why is an CRUD action being conducted? Do any interesting testing ideas come to mind when you think about this angle? How about bad or malicious motivations?

How?

How are the actions being undertaken? By a keyboard? By a mouse? By a batch processing system?

Lastly, if you have an account you created on Hexawise.com, check out "08. Modifications to a Database" for some additional ideas.

Bottom line: when test designers create tests (whether they use Hexawise to generate their tests or whether they select and document their tests by hand), they will have a lot of discretion over what kinds ideas to include / exclude from their tests. Using Hexawise offers these advantages over selecting tests by hand: (i) you will maximize variation in your tests, (ii) you will minimize wasteful repetition in your tests, (iii) you will achieve 100% coverage of the combinations you tell the tool to include in your solution (e.g., pairwise testing coverage, three-way coverage, risk based testing coverage, etc.), (iv) you will be able to select those combinations and documented tester instructions faster and with fewer errors in the documented tests.

I hope these ideas help! Please keep the good questions coming.
Photo of Jan

Jan

  • 9 Posts
  • 0 Reply Likes
Thanks Justin! This is exactly what I was looking for.

My initial thought after reading your response was "What about coverage?" - how did choosing options 1,2, or 3 impact my coverage and how did that trade off effect my decision.

I decided to try all three options in my model and compare the number of test cases to see if test effort was impacted as well. It wasn't! All three options resulted in the same number of tests. The total number of permutations varies but what needs to be tested doesn't. (This was all 2-way, didn't check 3-way).

So is it fair to assume then that my coverage all 3 ways is equal? I don't want to jump to any incorrect conclusions.

Thanks,
Jan
Photo of Justin Hunter, Hexawise Founder

Justin Hunter, Hexawise Founder, Founder and CEO

  • 246 Posts
  • 15 Reply Likes
Jan,

I wouldn't put it quite that way. The tests from "Scenario 1" that have just one CRUD action in each test will test each of those in combination with every other test input in your plan.

In contrast, the "Senario 3 tests" that have multiple CRUD actions in each test will have more thorough testing coverage because they will ALSO cover whether e.g., trying to Create a record and then Delete that same record shortly afterward would work properly.
Photo of Jan

Jan

  • 9 Posts
  • 0 Reply Likes
Another question...

I'm leaning towards option 3 right now. I have all of my original parameters and values in my model as well as:

Update: Update, Don't Update
Delete: Delete, Don't Delete

I have to add regardless and read doesn't really apply.

A lot of my "add" permutations are error cases. For example, I have a parameter called userid with a value of blank. This will cause an error and the add will not be successful. Thus whatever the tool selects for Update and Delete will never be executed.

I'm wondering if I'm better off making a second model of just my "good" add tests and then using the permutations of Update and Delete on those.

If I keep it the way it is then is my update and delete coverage actually less than it should be because I can't get that far with those tests and those those combinations are never tested?

Did that make sense?
Photo of Justin Hunter, Hexawise Founder

Justin Hunter, Hexawise Founder, Founder and CEO

  • 246 Posts
  • 15 Reply Likes
Jan,

More good questions. Thank you.

There are a few common strategies to handle negative test cases when you're doing pairwise testing or OA testing or OATS...

First Strategy:

First, you could simply modify the test inputs from "Add a record with a blank name" to read something like - "Add a record with a blank name AND THEN FIX IT BY ENTERING A VALID NAME ONCE YOU RECEIVE AN ERROR MESSAGE SO THAT YOU CAN PROCEED TO THE LAST STEP AT THE END OF THE TEST CASE."

Second Strategy:

Generate one set of "positive" test cases using Hexawise.

Document additional negative test cases (not covered in your Hexawise-generated tests) outside of Hexawise.