What test scenarios are necessary and sufficient to exhaustively black box test a recurring appointment model?

Question

I have a django model for an appointment in a calendar that I am attempting to write a very comprehensive test driver for. The recurring appointment occurs at some point in time and can either run on infinitely or recur for a fixed number of times. The appointment mirrors the functionality available for a Google Calendar appointment (can recur monthly/annually/weekly, every two weeks, every 3 years.)

I'm trying to come up with a unit test that will exhaustively test the basics of this implementation. I am looking for the edge cases that will define the most basic tests.

I have a lot of basic ones, but am looking for suggestions to help identify the most important cases: 1) Create a single appointment 2) Create an appointment that recurs weekly 3) ... recurs monthly 4) recurs every 2 weeks 5) recurs every 2 months 6) recurs annually

Answer 1

Don't forget to test annual recurrence for Feb 29 on a leap year ;)

Answer 2

Test with final days of months, leap years, and whether it will go crazy when the year has an extra second (this one hit a driver in the zune player).

Test it behaves well when crossing years.

That said, consider whether you are re-testing something that is part of the framework. Testing date logic can get ugly real fast, so you want to draw a line on what is part of your application and what is part of the framework.

Answer 3

Before you start rattling off scenarios, you really need to come up with a test plan based on your understanding of the Requirements.

Consider your user base and any other possible/future user bases (as a lower priority). What will they mostly be using it for and how much are those use cases worth to them in their business?

Ideally, create a model of the app and start from there.

Come up with a Risk Analysis of what you plan on doing. Then plan to do functional, security, localization testing, etc.

Then you can start thinking about scenarios based on how "risky" they are (from the Risk Analysis). Focus on writing and executing the "riskier" ones first.

Get Business input (signoff if possible) on your analysis of risk and how the intend to use it.

Just throwing random scenarios out there is not a good test practice and deserves all the ridicule you can get from developers. Testing should be a more engineered, planned exercise. They can hire anyone off the street to run scenarios that come to the top of their head.

That being said, I agree that the previously mentioned scenarios are tried and true. Good ideas. Also throw in Daylight Savings testing. Use different Email clients. Try publishing free/busy date. Get the developers to explain how they are publishing this information. Is it through a web service? Do they expect only Exchange users to use this? Anyone in different countries where dates are formatted differently? You can then find weaknesses and find more bugs.

Happy Testing.