I came back from the background of writing test cases which were categorized in either Positive or Negative test cases. Positive test cases were business flows which may or may not give any result but they will certainly not give any exception or error. Negative test cases are those test cases which were bound to result into some exception or better expressed as error causing scenarios. Then those positive test cases were prioritized as High/Medium/Low. Finally it used to result in quite a comprehensive test case document. Then it will go through the process of review and few more updates or change of priority etc. Certainly it is a tedious process.
Here in ThoughtWorks I got introduced to different way of categorizing test cases called “Happy/Sad/Bad”. A test case which results you in a positive result is a Happy path, for e.g. entering proper username and password on login page. A test case which yields no result like entering invalid username and invalid password on a login screen is Sad path. These test cases will actually will be scenarios which will not take you further. And finally the last one “Bad path” which is like entering junk characters in username field or some 70 characters in username field and will expect system to handle it and show some messages to the user.
So if you carefully see the 3 paths, they can actually help you filter out the test cases which you would want to deliver to client for UAT testing or will help you prioritize the bugs. Ideally in agile methodology where you have an iteration typically of 2 weeks, you don’t have much time to explore everything or beautify your test cases or have long discussions on whether that bug needs to be fixed or not. The turn around time should not be high and in such scenario the happy, sad and bad path would actually help you decide things in a much faster way.