Calendar:Test Case List: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
== Calendar Test Cases==
== Calendar Test Cases==
Since Litmus does not allow for an easy way to list test cases, this page will contain a listing of our test cases until {{bug|334871}} is fixed. Since submitting test cases to Litmus is a manual process at the moment, I will divide these test cases into two groups: those submitted to Litmus, and those not submitted to it. When adding new testcases, please add them to the "Not submitted to Litmus" list.
We will be using [[http://litmus.mozilla.org Litmus]] to track our testcases. If you have testcases that need to be added to Litmus, please add them to this page, and they will be moved into Litmus as soon as possible.
 
==Litmus Calendar Product Test Case Structure==
This is the proposed structure for the Calendar project testcases in Litmus. Litmus allows a high level "Product" (think of it as Project) grouping. Our Project is Calendar. Beneath our Product, we can have TestGroups, which are large generalized buckets of tests. Beneath TestGroups, there are SubGroups, which are more finely grained TestCase Buckets. And within the SubGroups there are TestCases.
 
I followed the models used by Firefox and Thunderbird to work out this type of structure for us.
 
*''Product: Calendar''
** ''TestGroup: Sunbird Basic Functional Tests''
***''SubGroup: Calendars''
****''Testcases: Create Local Calendar''
****''Testcases: Create Remote Calendar''
***''SubGroup: Events''
***''SubGroup: Tasks''
***''SubGroup: Installation''
***''SubGroup: Navigation''
***''SubGroup: Searching''
** TestGroup: Lightning Basic Functional Tests
** TestGroup: Sunbird 1.0 Full Functional Tests
** TestGroup: Lightning 1.0 Full Functional Tests
** TestGroup: Smoketests
***SubGroup: Sunbird
****TestCase: Sunbird Smoketest
***SubGroup: Lightning
****TestCase: Lightning Smoketest
** TestGroup: L10N
***SubGroup: Sunbird L10N
***SubGroup: Lightning L10N
 
'''Notes'''
* The items in italics are items that currently exist in Litmus (2006-07-20)
* Litmus has a Clone feature that makes it easy to clone the Sunbird structure for Lightning, then just remove the Sunbird specific parts.
* Do we want to track testcases separately for Lightning and Sunbird? I would think so, and that's why I created this structure.
* When performing calendar/event/task testing, I have broken testcases into "local" and "remote". In this description, "Remote" covers all possible providers, and I indicate to the person running the test to annotate the test with which provider they used for the remote test. Is that sufficient? My thinking was that there will be provider-specific testcases to focus on each provider, and therefore, it did not matter so much what provider basic tests were performed against. Thoughts?


==Testcases Not Submitted To Litmus==
==Testcases Not Submitted To Litmus==
===Unsubmitted Lightning Testcases===
===Unsubmitted Sunbird Testcases===
{| border="1" cellpadding="2"
{| border="1" cellpadding="2"
|+Basic usage
|+Basic usage
Line 128: Line 159:
| Backup files || Backup files should be made prior to every change to an ICS calendar, and 3 copies should always be kept. ||  
| Backup files || Backup files should be made prior to every change to an ICS calendar, and 3 copies should always be kept. ||  
|}
|}
===Unsubmitted Core Testcases===
===Unsubmitted Shared UI Testcases===
==Testcases Submitted To Litmus==
===Submitted Lightning Testcases===
===Submitted Sunbird Testcases===
===Submitted Core Testcases===
===Submitted Shared UI Testcases===

Revision as of 15:29, 20 July 2006

Calendar Test Cases

We will be using [Litmus] to track our testcases. If you have testcases that need to be added to Litmus, please add them to this page, and they will be moved into Litmus as soon as possible.

Litmus Calendar Product Test Case Structure

This is the proposed structure for the Calendar project testcases in Litmus. Litmus allows a high level "Product" (think of it as Project) grouping. Our Project is Calendar. Beneath our Product, we can have TestGroups, which are large generalized buckets of tests. Beneath TestGroups, there are SubGroups, which are more finely grained TestCase Buckets. And within the SubGroups there are TestCases.

I followed the models used by Firefox and Thunderbird to work out this type of structure for us.

  • Product: Calendar
    • TestGroup: Sunbird Basic Functional Tests
      • SubGroup: Calendars
        • Testcases: Create Local Calendar
        • Testcases: Create Remote Calendar
      • SubGroup: Events
      • SubGroup: Tasks
      • SubGroup: Installation
      • SubGroup: Navigation
      • SubGroup: Searching
    • TestGroup: Lightning Basic Functional Tests
    • TestGroup: Sunbird 1.0 Full Functional Tests
    • TestGroup: Lightning 1.0 Full Functional Tests
    • TestGroup: Smoketests
      • SubGroup: Sunbird
        • TestCase: Sunbird Smoketest
      • SubGroup: Lightning
        • TestCase: Lightning Smoketest
    • TestGroup: L10N
      • SubGroup: Sunbird L10N
      • SubGroup: Lightning L10N

Notes

  • The items in italics are items that currently exist in Litmus (2006-07-20)
  • Litmus has a Clone feature that makes it easy to clone the Sunbird structure for Lightning, then just remove the Sunbird specific parts.
  • Do we want to track testcases separately for Lightning and Sunbird? I would think so, and that's why I created this structure.
  • When performing calendar/event/task testing, I have broken testcases into "local" and "remote". In this description, "Remote" covers all possible providers, and I indicate to the person running the test to annotate the test with which provider they used for the remote test. Is that sufficient? My thinking was that there will be provider-specific testcases to focus on each provider, and therefore, it did not matter so much what provider basic tests were performed against. Thoughts?

Testcases Not Submitted To Litmus

Basic usage
Test Description Outcome
Event creation Sunbird should be able to create an event lasting any duration and at any date
Task creation Sunbird should be able to create an task lasting any duration and at any date, or without a start and/or due date
Event editing Events should be able to be edited. Changes made when editing an event should be saved.
Task editing Tasks should be able to be edited. Changes made when editing a tasks should be saved.
Deleting Tasks/Events should be able to be deleted.
Clipboard Tasks/Events should be able to be altered by using cut, copy and paste.
  • This isn't easy to do for tasks, because of bug 195580


Recurrence
Test Description Outcome
Daily Events/tasks should be able to recur every X days
Weekly Events/tasks should be able to recur every X weeks, including on multiple days of the week
Monthly Events/tasks should be able to recur every X months, on a specific day of the month
Monthly 2 Events/tasks should be able to recur every X months on the Nth (weekday) of a month
Yearly Events/tasks should be able to recur every X years
Exceptions An arbitrary number of exceptions should be able to be created and respected, for any recurring event


Calendars
Test Description Outcome
Local Calendar Creation Local Calendars should be able to be created, assigned a name, and assigned a color
Webdav Calendar Creation Webdav Calendars should be able to be created for any web address, assigned a name, and assigned a color
Caldav Calendar Creation Caldav Calendars should be able to be created for any web address, assigned a name, and assigned a color.
Calendar editing Any calendar should be able to be edited. Changes made in the Calendar Properties dialog should be properly saved.
Remote subscribing Sunbird should be able to subscribe to a remote calendar and properly display the events/tasks it contains.


Importing/Migration
Test Description Outcome
0.2 Migration You should be able to migrate data created in Sunbird 0.2 to 0.3PR. Choose 'File->Import' and import any calendars you may have created. Events should be successfully imported
Item data Check to make sure all aspects of an imported event were successfully imported. Check to make sure the event is displayed with the proper time
Outlook import Export data created in Outlook in .csv format and then import this data into Sunbird. Perform the previous checks.
  • Sunbird can currently only import from English or Dutch versions of Outlook (Bug 301750)


Export
Test Description Outcome
.ics export Sunbird should be able to export its data in a standards compliant .ics format. Export your data and attempt to import into another program
Item data Check to make sure all aspects of an exported event were successfully exported. Check to make sure the event is exported with the proper time
.html export Sunbird should be able to export data in a .html format. Export your data and try viewing the output in a web-browser
  • Only the title, location, and event-times are shown


Publishing
Test Description Outcome
http publishing Sunbird should be able to publish an entire calendar or a selected set of events to an http address
ftp publishing Sunbird should be able to publish an entire calendar or a selected set of events to an ftp address
password protection Sunbird should be able to publish an entire calendar or a selected set of events to a server that requires password authentication
subscribing Sunbird should be able to subscribe to a published calendar
Error reporting
Test Description Outcome
Invalid file Sunbird should report to the user when a file can't be parsed. The calendar should be placed in read-only mode
Offline failure Sunbird should report that a remote calendar cannot be read when internet access in not available. The calendar should be placed in read-only mode
Publish failure Sunbird should report when publishing a calendar fails, for any reason such as insufficient permissions. The calendar should be placed in read-only mode
Backup files Backup files should be made prior to every change to an ICS calendar, and 3 copies should always be kept.