The Exception Proves the Rule

I often hear people speaking in idioms, such as “a blessing in disguise” or “it’s raining cats and dogs”, but one idiom that I find interesting is “the exception proves the rule.”

This particular idiom is actually useful in the field of software testing. To understand how it may be useful in our world, it is necessary to understand the epistemology of the phrase. [If you want to have a fun discussion with someone, ask them to explain what this idiom means!] The definition of the phrase does not mean an exception proves the validity of the rule/law or proves the need for the rule/law. If you have a rule that states “All cats are black, brown, or orange” then the existence and observation of a white cat cannot possibly prove that the rule is valid.

The phrase actually comes from 17th Century law where it is written in Latin as “Exceptio probat regulam in casibus non exceptis” which translates into English as Exception confirms the rule in the cases not excepted. More simply, 'The exception proves the rule exists' — the fact that certain exceptions are made in a legal document or announcement confirms the rule is in force at all other times. Think of it this way, if there is a sign announcing 'Free parking on Sunday' that leads everyone to understand that every other day of the week there will be a fee charged for leaving one's car in that spot. Thanks to Snopes.com for having done this research!

Now, in the world of testing this is an important statement. To rephrase for our world, in requirements, the fact that certain exceptions are iterated help to define the boundary of the requirement. Sometimes, requirements specify the rule and the exception and sometimes they only specify the exception leaving one to use implication to define the requirement. This is an actual requirements document I found online. It is laid out in a typical hierarchical outline fashion with requirements having sub-requirements. See here for the full document. In this document, which is a requirements document for a meeting scheduler for people and rooms, there is the following requirement branch (paraphrased for clarity - see below):

3.1 Scheduling a meeting
3.1.3 When the system chooses a time for a meeting, it shall send queries to the online calendars for all the rooms in which the meeting could be held to ascertain which rooms are vacant during the selected time.
3.1.3.1 If no rooms are vacant during the selected time, the system shall choose the next feasible time.
3.1.3.2 The system shall choose which room should be the venue for the meeting from the set of rooms free at the selected time by a room-choice algorithm that shall take account of the size of the room given the number of invitees to the meeting, and the convenience of the room for the invitees.

What is interesting about this requirement branch is that no where does it explicitly say the system will choose the user’s selected time for the meeting it that time is open for all resources and people. However, I implicitly see this requirement because 3.1.3.1 indicates that should the time not be available, an alternate time would be located and chosen. This implies that if the time selected is available it will be chosen.

There are more complicated examples in the following requirement branch:

3.1.6 If there is at least one feasible time and IMS chooses a time for the meeting, IMS shall display appropriate notification messages to the Initiator and all the invited attendees.
3.1.6.1The wording of the message shall depend on whether the recipient is

(a) the Initiator (who knows about the meeting and is being informed that it has been scheduled)
(b) an invited participant (who is learning about the meeting for the first time and who is being "strongly" invited to attend)
(c) an invited participant who was not in the subset of people whose schedules were checked when the Initiator chose option (a) above (such invitees being "weakly" invited, as they are known to be busy at the chosen time).

Here are some rules I see based on the exceptions identified:

• The messaging to strong and weak participants is different based on their categorization
• Participants are categorized as weak if they are not available or were not a part of the original invite
• Participants are categorized as strong based if they were a part of the original group and have availability at the selected time
• However, this leads to me to question (something to explore with Rapid Software Testing) whether the messaging does get crossed as the Initiator should also be a strong participant (as they should have availability) or not.

I could go on for a while about these requirements, but essentially, I want to convey that when requirements are not clear, sometimes the best way to clear them up is to question how the exception defines the underlying rule. It is an oracle that all thinking testers should have in their arsenal.