Translate

Monday, September 26, 2016

Genealogy

So this is another black box testing exercise. It has to do with a search on a Genealogical (family history) site. Since last time, it was recommended to use Boundary and Equivalence classes, I thought this example could be using nothing but boundary and Equivalence classes. Here is the prompt:
You are designing the tests for a genealogy search program. Design equivalence class tests and boundary tests to cover all aspects of this program. List the boundaries you are testing, as well as the equivalence classes you are testing, and list the test cases for each. Do not forget to list the expected results.
The user can input the following information, and then do a query. The program will either return the results of the query, or will return a message saying “invalid query.” A valid query can return either a set of names (don’t worry how many), or a message saying “no persons found matching your query.”
  1. Surname, up to 20 characters. Longer names are truncated.
  2. Given name, up to 20 characters. Longer names are truncated.
  3. At least one date. Each date consists of a day (2-digit numeric), a month (numeric), and a year (4-digit numeric):
    1. Birth date
    2. Death date
    3. Marriage date. Note that if a person is younger than 12 or older than 60 when he or she is married, the program prints a warning, but allows the query to go through.
  4. Place: Each of the dates (birth, death, marriage) has an associated place, consisting of two fields, City and Country. Each field is optional (if no place is present, then it matches that event anywhere in the world. A city may be specified without a country; for example, you know someone was born in London, but you aren’t sure whether it refers to London, England, or London, Canada.)
What I did is do all the equivalence classes and then the boundaries.
Equivalence Classes tests
Surname:
            Class 1 Valid Surname (1 < 20): williams
            Class 2 too many characters ( >= 20): hhhhhhhhhhhhhhhhhhhhhh
            Class 3 to few characters (< 1): (blank)
Given Name:
            Class 1 Valid Surname (1 < 20): williams
            Class 2 too many characters ( >= 20): hhhhhhhhhhhhhhhhhhhhhh
            Class 3 to few characters (< 1): (blank)
Birth Date:
            Class 1 valid date:  12-11-1999
            Class 2 wrong number in days:  35-12-1999
            Class 3 wrong number in months: 15-15-1999
            Class 4 wrong number in years: 15-12-2050
Death Date:
            Class 1 valid date:  12-11-1999
            Class 2 wrong number in days:  35-12-1999
            Class 3 wrong number in months: 15-15-1999
            Class 4 wrong number in years: 15-12-2050
Marriage Date:
            Class 1 valid date:  12-11-1999
            Class 2 wrong number in days:  35-12-1999
            Class 3 wrong number in months: 15-15-1999
            Class 4 wrong number in years: 15-12-2050
            Class 5 younger than 12 years:   21-9-2004
            Class 6 older than 60: 21-9-1955
Place:
            Class 1 valid city and country: London, England
            Class 2 just a valid city: San Diego
            Class 3 just country: USA
            Class 4 just an invalid city: hjkhjh
Boundary test
Surname boundary is  >0 and <=20
            Test: 0,1 and 20,21 letters long for the surname
Given name boundary is  >0 and <=20
Test: 0,1 and 19,20,21 letters long for the given name
Birthdate boundary for day is 1-31
            Test: 0,1 and 31,32
Birthdate boundary for month is 1-12
            Test: 0,1 and 12,13
Birthdate boundary for year is 1900> and <2017
            Test: 1900, 1901 and 2016, 2017
Death date boundary for day is 1-31
            Test: 0, 1 and 31, 32
Death date boundary for month is 1-12
            Test: 0, 1 and 12, 13
Death date boundary for year is 1900> and <2017
            Test: 1900, 1901 and 2016, 2017
Marriage date boundary for day is 1-31
            Test: 0, 1 and 31, 32
Marriage date boundary for month is 1-12
            Test: 0, 1 and 12, 13
Marriage date boundary for year is 1956> and <2004
            Test: 1900, 1901 and 2016, 2017
Marriage date lower age boundary  for message <1956 and >1900
            Test: 1955, 1956 and 1900, 1901
Marriage date lower age boundary  for message >2004 and <2016
            Test: 2004, 2005 and 2015, 2016
Place city boundary only equals valid city
            Test:  London and hhhhhh
Place country boundary only equals valid country
            Test: Spain and hhhh      


When you have both of these you can remove duplicates, which comes out to be basically only the boundary test cases. This is because the boundaries cover all the equivalence classes as well as their own. Just to put it out there I probably missed some, I am not perfect in any way. By the way there are about 90 test cases before you remove the redundancies. And about 50 test cases after removing redundancies.

Do people like testing examples?

1 comment :

  1. Testing this feature by *only* BV and EC will fall flat and leave much to be tested.
    Let me explain:

    1. Anywhere where a text input is expected you should also include tests for input containing *non* alphanumerical chars (e.g. $,^,&). Bonus point goes for using chars from UTF-8 (like Chinese or German letters with umlauts above them).

    2. It is not specified in the spec what format the date is to take: whether it is dd/mm/yyyy or mm/dd/yyyy. From the example BV we understand its the European style, but that should be specced-out.

    3. Having said that, you should test all numerical input fields for *non* numerical inputs, easiest of which is negative floats, e.g. -8.6 or, better yet, (-4.3).
    3.1. That is, of course, unless the date is picked by a calendar widget. It's not out job to QA the widget's library.
    3.2. Since the spec *DOES* specify the number of digits each field of the date should have, an easy test is trying entering *non* valid number of chars per field.
    You ***CAN'T*** try something like d/mmm/yy since if it fails you can't be sure which of the three different section failed. This one you have to try the hard way: d/mm/yyyy; dd/m/yyyy; dd/mm/yy.

    4. If you have any two or more of the three dates described you should validate death date is the most recent and wedding date come after birth date.
    4.1. To present a warning about marrying too young or too old you **MUST** have the birth date as well as wedding date. Currently you're calculating age with respect to year 2016. My grandfather wed when he was 24, way back at 1938... that kind of data should not trigger a warning according to the spec, but with the posted BV and EC it will.

    5. Also, it is not in the spec that the minimal year is 1900. It's OK to make assumption when you're writing an example. In real life you'd have to contact a stakeholder and find out.

    6. Lastly, nowhere in the spec does it say that the city/state combination, the first name stated is the state, as is inferred by you BV/EC.

    There are probably more, many more, cases.
    Genealogy apps are huge, logic-wise.
    You can, and should, use BV/EC to optimize the testing, but you can't rely only on these two tools alone or you'll miss out on a huge amount of logic (and tests, and bugs).

    ReplyDelete