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.

Quality is Dead... Everywhere - The tale of the Christmas present being 1 month late

A few weeks ago James Bach wrote a post about quality being dead. His hypothesis was stated simply as, "a pleasing level of quality for end users has become too hard to achieve while demand for it has simultaneously evaporated and penalties for not achieving it are weak." James even threw out he proverbial "Microsoft releases buggy software" line. His points have merit and this post is not to discuss his points, as I agree with them; especially with respect to the weak penalties for releasing unsatisfactory software. This post is to point out that the phenomenon is not confined to desktop software where end user productivity is impacted, or confined to web based software where eCommerce may be affected. On to my experience...

First, I want to point out that my wife and I have 6 children ranging in age from 14 to 20. I do this because, as James' points out in his Rapid Software Testing approach, "Quality is value to some person (who matters)." In this story I think I should matter, but perhaps my ego is too big.

My wife went to a national clothing retail store, that caters to teens and young adults, located in our city to purchase a green stretchy sweater as Christmas gift for one of our nieces. This is not unlike many people who purchase clothing Christmas gifts for their family members. In any event, the purchase was made a few weeks before Christmas. At the time, nothing seemed unusual, except the register receipt paper color and texture. It was sort of craft-paperish like. We thought it was simply a branding thing, and pretty cool. We hosted Christmas at our house, exchange presents, and had a good time. A week later, we get a frantic phone call from my wife's sister. She is at their local store of this national change, trying to do what so many of us have to do, exchange the present for the correct size. If you think this is simply a story about exchanging presents, just wait to hear the rest. My sister-in-law had just been accused of stealing the sweater and trying to get a legitimate receipt under the ruse of exchanging the sweater with a fake receipt. Now, my wife's sister is angry and venting on my wife, both trying to figure out what the heck was going on. My wife called our local store to find out that this particular store was beta testing a new register system. How nice! Our local store was nice in trying to resolve our problem, but their initial solution was to have the sweater exchanged at their store only. After presssing on with the store manager, we were able to get a hold of a team member of the project team. The problem they told us, was that the old system could not understand where the transaction number was on the new receipt. They gave us instructions to give to the store in order to manually process the exchange. This is called a work around, but you do the work while going around and around. We called my sister-in-law back, and spoke with her and that store's manager. We followed the instructions as laid out as guess what, it did not work. We gave the store the name and number of the project team member that was helping us. However, when the store tried to call, no one answered. Given the busy exchange season, and the fact that the store still thinks someone is trying to scam them, they were not interested in pursuing the matter further. To wrap up the story, my sister-in-law had to ship the sweater back to us, so we could exchange it, and we had to ship the new sweater back to her. We spoke with our local store and the team member several times, and both refused to reimburse shipping expenses or offer any sort recompence (other than "we're sorry"). By the way, I agree, that chain is sorry.

This is where quality is dead comes in. Not only was the software not ready for beta testing, but it was dropped on unsuspecting consumers in a business that requires signficant consumer spending to stay afloat. There was no concern for any issues that consumers may run into, no method for resolving them, nor any true means to compensate consumers for being victimized for bad software and practices. Usually a beta community gets the opportunity to engage in the test or opt out. Not in this case. Which really makes this a public release and not a beta test. In this situation, I am imagining that only a handful of people were impacted, so maybe this is blown out of proportion. But, as a consumer with a large family in the demographic this store wants to target, I think I matter more than they realize. But this is where the weak penalties come into play. If my family doesn't shop at that store, which is our only recourse left as 2 stores, and a project team member fully know of our experience, their sales are not materially affected. (By the way, I am not calling for a boycott, let's not get crazy now) With such weak penalties it is a wonder that this hasn't happened faster and more frequently than it has.

My Comment Policy

Here is my policy for accepting comments that you make on this blog:

1. I moderate all comments. I accept comments for one or more of the following reasons:
• The poster offers an interesting point
• The poster engages in critical and thoughtful debate
• The poster either clarifies or offers an opportunity to clarify a point
2. It is okay to question my ethics or competence when proof is provided. Flame wars will not be posted or engaged. I will not approve a comment that insults me or dismisses my arguments without engaging the points directly. Respect between is paramount to ensure we can have thorough discussions.
   
3. If I don’t publish your comment, feel free to ask me why. I promise to explain.
4. I will not edit or redact a comment that you submit unless I have your permission, with the possible exception of fixing an obvious typo. I may interpolate my replies, however. If you don’t like that, you can email me privately to complain, or you can post your comments about my stuff on your own blog, and then you’ll have total control.\
5. If you want to comment on a reply I made to one of your comments, consider replying to me privately, so we can have the whole conversation. Then when you are ready to make your follow-up comment, I’m more likely to approve it.
6. By publishing your comment, I am implicitly endorsing it as potentially useful to the audience of this blog.
7. If you want me to remove or modify an earlier comment of yours, I will do so. Provided I can do so with Blogger's tools. (I have not yet checked this ability out)
8. You retain copyright over your comments.

Comment Policy borrowed from James Bach