Written Report on Model (Testing)

Model Analysis and Testing

Model Analysis

Ubiquitousness of Split

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the Report for View (Testing) section.

Testing

Testing Strategy

• Conformance — Does the value conform to an expected format?
• Ordering — Is the set of values ordered or unordered as appropriate?
• Range — Is the value within reasonable minimum and maximum values?
• Reference — Does the code reference anything external that isn't under direct control of the code itself?
• Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
• Cardinality — Are there exactly enough values?
• Time (absolute and relative) — Is everything happening in order? At the right time? In time?