Equivalence partitioning for complex input data - Software-Testing

Hi!

> The question arised if there is a kind of 'systematics' to identify
> equivalence classes when one has a more complex input space (e.g.
> functions which have a complex interface or even a complex GUI).

Is there really nobody who has/had this problem before? Or do I just
miss something obvious here?

--
chris

chris wrote:

>> The question arised if there is a kind of 'systematics' to identify
>> equivalence classes when one has a more complex input space (e.g.
>> functions which have a complex interface or even a complex GUI).

> Is there really nobody who has/had this problem before? Or do I just
> miss something obvious here?

1. Divide and conquer (obviously) .

For example, you might be able to divide the UI into regions
(X,Y,Z etc) . Each region may have equivalence classes of their
own.

Then there may be dependency between regions :

(X equivalence class 1) implies
(Y equivalence class 2) or (Z equivalence class 3) .


Whatever you discover, document it as domain information.


2. Have a sophisticated specification-driven test tool that derives
the equivalence classes for you (if you have such a tool - give it
to me now !!! :-) ) .


Regards,
Steven Perryman

> A couple of days ago a few collegues and I discussed about equivalence
> partitioning.
>
> The question arised if there is a kind of 'systematics' to identify
> equivalence classes when one has a more complex input space (e.g.
> functions which have a complex interface or even a complex GUI).
>
> One solution could be to design the interfaces more testable in
> advance, but this might not always be possible (e.g. if you have some
> legacy code).
>
> Any hints?

Yes: see the lecture on Domain Testing in Cem Kaner and James Bach's
Black Box Software Testing course at
http://www.testingeducation.org/BBST/index.html.

It's important to note that equivalence partitioning is based on some
mental model of commonalitites and differences. Not all equivalance
classes can be represented on number lines; not all equivalance classes
have clear boundaries. Instead, equivalence classes are based on our
expectations--why do we believe that one piece of input will cause
different behaviour from another piece of input? How might two
devices--say, two network cards--behave similarly and differently? How
might two outcomes be considered similar enough--or different
enough--for the purposes of exercising various pathways through the
code?

Improving testability is usually a highly desirable approach.

---Michael B.

Can you explain what do you mean by "complex input space"? In my
opinion -
by complex interface or GUI - input space will not become complex.
I think equivalence classes can not defined for multiple input entities
(simply input data points). Equivalence classes are defined per each
Input entry - like

1. Name field - Free format string [100]
2. Date Field - in mm/dd/yyyy format

So we will have two sets of EQ. classes for each of above in put data
fields.

My fav example of demonstrating EQ classes is on "Search field" of
Google.
Here are few that I can come with

1. Search with + operator involving 2 words
2. Search with - operator with 3 words.
3. Search with one quoted string and non quoted string
4. Search with only quoted string

This is example represents a complex Input domain simply because of
it's size - 256 char long with no restriction on what user can enter.
How do I simplify what do I test? How many test cases do I have....?