If your AUT has logic that checks for null values, make sure removed values get set back to null. If they get set to blank, you may have a nice crunchy bug.
Here are the pseudo steps for the test case using a generic order form example. But you can use anything in your AUT that programmatically makes a decision based on whether or not some value exists.
Feature: Orders with missing line item quantities can no longer be submitted.
- Create a new line item on an order. Do not specify a quantity. Crack open the DB and find the record with the unpopulated quantity. Let’s assume the quantity has a null value.
- Populate the quantity via the AUT .
- Clear the quantity via the AUT. Look at the DB again. Does the quantity have a blank or null value?
Expected Results: Quantity has a null value.
If your dev only validates against null quantity values, your user just ordered nothing...yikes!
4 comments:
Subscribe to:
Post Comments (Atom)
RSS
Also try \t \n and other fun variants that look blank to the user but are not null in the db.
There's a nice handy built in function in C#'s string class called IsNullOrEmpty which checks for either null or empty string and returns true if either case exists.
One thing I wish C# would add builtin which would also take care of spaces, tabs, carriage returns is if did a Trim() if the string wasn't null before checking to see if it's empty. Although it would be easy enough to write an extension method to do so.
in Rails (Ruby On Rails), the blank? method does this job, also if you have spaces, tabs etc.
For example
"".blank? => true
" ".blank? => true
" \t ".blank? => true
nil.blank? => true
"whatever".blank? => false
I got burned by this defect once and once was enough. The developers did not realize that the null value in Cobol represents nothing, it is not the same as blank.
Finding this defect at a system level was difficult, as was finding the root cause of the defect.
A data flow test at the unit test level would have been more efficient, i.e. follow your data through the define-use-kill cycle (duk).
Or better yet perform a code inspection with a other developers who would find this for you before testing.
jmm
softwaretesting.net