Equivalent partitioning. Not always a simple concept

This is the second issue in series of mini-experiences – learning opportunities I’ve recently described .
Equivalent partitioning is a simple concept isn’t it? I’m going to show that even as simple example as search form with two fields could appear quite complex. A person without testing experience has a good chance to design excess tests still failing to design the test case to detect the defect I’m going to describe. The defect from a real life I've reported few weeks ago. Do you want to check yourself?

The Context: problem description
Suppose I’m testing defect tracking system search capabilities (I will call entries in it “tickets”). Design test case to test a form that search all tickets by their creation date (form have two fields: date_from and date_to). Given that I know that fields for data entry they use as standard ones (tested already for invalid data entry) and data is saved in Oracle DB and retrieved using SQL (where statement), so there are no sense to test the correct ordering of date, only the where statement generation. I want tests to be scripted exactly – it is easier to review them.
Ok, this test is a classic text-book equivalence partitioning task. Of course, if you take the context into account and drop all incorrect data entered tests with the only exception (see below). It is does not matter what the dates we select 0 only their order matter. So
Data preparation only consist of 5 tickets reported on different days (note that creation date can’t be empty):
a) January 1st
b) January 3rd
c) January 5th
d) January 7th
e) January 9th
I do not create two tickets on the same date and don’t care for order in which they are saved in database, etc.
The test execution steps. Perform (try to) following search requests (date_from – date_to):
1) January 3rd and 7th [and see if only tickets b, c and d are returned]
2) January 11th - 15th [test empty result-set]
3) January 3rd – 3rd [see if only ticket b is returned that form accept from=to]
4) January 7th - 3rd [error handling – see if form does not accept from>to]

Now a little bit more complex task. There is one more search form. Suppose our system support status changes for tickets. The creation is supposed the first status change from status none to submitted. More changes are possible later on and system has to remember all of them. The new search form will allow us to find all tickets that have (ever) changed the status during certain period. It also has date_from and date_to fields in search form. Of course, I suggest you to completely reuse the first test case and only extend it a little bit (or a lot). For example add to test data ticket entered on January 5th but changed status on January 9th. I mean f) Januarry 5th->9th. It should be returned searching tickets that had any status change in interval 3rd - 7th. How much more are you going to suggest?

A comment
I’ve been writing this for days. Each day I discovered more and more about this seemingly simple case. So I was wrong with my answer myself on the first try. I know the idea of equivalence partitioning but I never formally apply it while doing testing. My final answer is that there is no one correct answer. There is some equivalence classes that should or should not be joined based on more context (for example risks/time prepare test data/time to execute and even time to design this test because it may be faster to excess few excess tests compared to analyze which one could be removed).

Formal answer
My answer is – I do not need to update test cases, except that the new form should be used. 4 searches 3rd - 7th ; 3rd - 3rd , 11th - 15th and 7th - 3rd. Also the same test data is reused, but the following cases added (read it as created->changed):
f) Januarry 5th->9th.
g) Januarry 1st ->5th.
h) Januarry 1st ->9th.
First of all – why I don’t need any more tests with boundary values, such as 3rd -> 7th? We have already tested boundary values using b and d tickets, I don’t really think it makes sense to test them for status multiple changes.
Now – I’m not sure if we really need even tickets h. The ticket h is only used to test that it does not appear in search 3rd - 7th. But isn’t it the same as ticket g not appearing in search 3rd – 3rd?
Tickets g and f are somehow the same, so we could remove f (g is used – see above). This is wrong! It may appear that a search only uses the first or only the last change from a history so we need both tickets to test both cases.

Let me now explain the defect I’ve found in the software. It was detected by ticket h and test 3rd - 7th which was almost the first test I did because felt like it has the highest risk to fail. And it did. The search returned me the ticked I call here h. The where statement was somehow (well if you know SQL you may simply imagine how that happened doing copy-paste logic from search by date_created) created in a way that this entry was found while searching using between January 3rd and January 5th.

The actual experience
When I was testing this all my test data from the first test was not reusable. More over the initial tests was performed before me. To be honest there was a generic search by any field and the feature added was enabling so called “multi-value fields” with search by them possible. So in order to test that I have to fill in a new field with multiple values. More over I know our developers does some unit tests themselves. So I was quite sure the feature will work for case like g or h.
As a result the ONLY test I ever did while testing the new feature – search by multi fields was: enter multi value January 3rd and January 7th and perform search between January 1st and January 9th. The only test I did found the defect. I don’t know if that was the only defect but I’m pretty sure about it. So in real life instead of creating 8 test data entries and performing 4 test, which may be counted as 8*4 tests performed I only did one. That’s real live context-driven equivalence class partitioning....