Versions Compared

Old Version 137

changes.mady.by.user Scott Amerson

Saved on

compared with

New Version Current

changes.mady.by.user Anonymous

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

TEST PLAN OVERVIEW

Scope of testing

This document is designed to guide Quality Assurance in the functionality testing of the provider mechanisms within SmartSite. The functionality of the provider mechanisms, as detailed by the given test cases in this plan, are driven by the functional requirements at :http://confluence.ucdavis.edu:8080/confluence/display/UCDSAKAI/Sakai+Providers.

...

  • Known (not fixed) issue #1 for Resources tool (e.g. using WebDav), is that when a file is uploaded to the system, metadata is written to the database before the file is stored on the file system. This is a feature of Sakai, which was detected during some resource discussion re:AFS file storage. For this reason, a resource may "seem" to be updated correctly, and listed in the resouce tool however the content cannot be seen. An http 404 error is thrown (No page can be found). This error is NOT fixed for this testing, just a known issue for Case 1a.
  • Known (not fixed) issue #2 is that whatever user that creates the sites when logged in is placed as a member in the site. Therefore, if ssbatchadmin created sites then the roster for such sites may appear off by 1.
  • Known (not fixed) issue #3 is that the instructor presented in the member list is not presented first. This is a default sorting behavior within SmartSite and will not be fixed.
  • Known (not fixed) *issue #4 PREVIOUS TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-202 * is that the instructor presented in the member list may be still listed even if they have been "replaced"
Info
titleJIRAs that explain features and past bugs fixed, to be tested in this plan

Summary of the Jiras related to this test plan, which have been fixed:
BATCH TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-184 (1000 row limit on associations (realms) for sakai internal query)
BATCH TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-185 (term abbreviation and term description do not match in site information tool)
PREVIOUS PROVIDER TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-197 Support and Training web link should be present, going to gateway site on sakai2
PREVIOUS PROVIDER TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-201 authz group refresh interfering with batching of courses, noticed in provider integration testing
PREVIOUS PROVIDER TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-124 (Banner rosters not in sync with SmartSite UI)
PREVIOUS PROVIDER TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-125 (drop student from Banner and not reflected in SmartSite UI)
PREVIOUS PROVIDER TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-132 (realms not refreshing fast enough in the providers)

Note
titleJIRAs that reference test scenarios, "QA Tests" described in this test plan

http://jira.ucdavis.edu:8080/jira/browse/SAK-155 When users log into Sakai, their user information is looked up externally in Mothra, LDAP, or some other central datasource for campus
http://jira.ucdavis.edu:8080/jira/browse/SAK-156 User logs into Sakai, and sees the tabs associated with their enrollment (roles) in courses from Banner, as well as sites internally defined in Sakai (e.g. projects)
http://jira.ucdavis.edu:8080/jira/browse/SAK-157 Course information must be pulled dynamically from Banner, within Sakai
http://jira.ucdavis.edu:8080/jira/browse/SAK-154 User is able to used WebDav in Sakai, with their Kerberos username and password

...

DEPENDENCIES

  • All UCDavis Providers (UserDirectoryProvider, GroupProvider, and CourseManagementProvider) will be enabled to allow user accounts to be looked up automatically via kerberos name
  • Distributed authentication using AFS should be enabled (SAK-143)
  • Sakai-test (Sakai-dev for integration testing) database will be a either a clean copy or a copy of existing production data, so sakai-test will have to be backed up prior to testing,
    Pradhu or Geeta will be contacted to schedule this. Sakai-dev has been scheduled to be a blank db as of 9/14/06, 2pm.
  • We will be referencing sakai-test (banner test external, mViews..) for populating course data

...

Info

*NOTE: The order of the test cases will be as follows.

Setup Preliminary Case (0a): Accessing server
Setup Preliminary Case (0b): Login access via DistAuth
Setup Preliminary Case (0c): Login outside of DistAuth (e.g. internal account)
Setup Preliminary Case (0d): Accessing admin functionality

Case 1: User Directory Provider
1a) Web Dav authentication
1b) User directory lookup functionality

Case 2: Group Provider
2a) Roles in courses verified by tabs
(1) Roles in courses verified by system log output (system admins)
2b) Realm refresh via browser refresh button (1) Realm refresh seen in system log output (system admins)

Case 3: Course Management Provider
3a) Rosters from Banner viewed by instructor and administrator role in site
3b) Adds/drops of students from Banner seen in SmartSite UI
3c) Roster details accurate (e.g. kname, role, etc)
3d) Instructor changes for a course seen in participants list for a site

...

results: Recorded in Jira http://jira.ucdavis.edu:8080/jira/browse/SAK-154

Note
titleWebDav User Lookup Testing, Case 1b

Description = Test the capability of the UserDirectoryProvider to provide information about an externally provided user via the SU Tool

Category of Testing = functionality,regression

Prerequisite Steps

  1. SU tool available to tester

Test Scenario 1b, User lookup functionality

  1. Log in as any user having administrative access (access to admin realm)
  2. Use a given kerberos name available via test data (e.g. instructor)
  3. Enter kerberos name, and click "View User Info"
  4. Verify user information from whois.ucdavis.edu and/or email.ucdavis.edu
  • Data to Be Used:
    QA determines

Test Cleanup
None

...

Note
titleCase 2a, Group Provider Tabs test

Description = Test the capability of the GroupProvider to provide tabs for a user based on their enrollment/membership in sites

Category of Testing = functionality,regression

Prerequisite Steps

  1. Site user is a member of must be already created prior to test (via Batch? via manually?)
  2. User must be a member of the sites in order to see the tab
  3. If user is an externally provided one, then they must be in either the external database (Banner) or already in the internal SmartSite database

Test Scenario 2a, Tabs

  1. Log in as in Case 0d, but become the user and don't log out
  2. Log in instructor for a given site site (see test data attachmentin CourseManagementProvider test section)
  3. View tabs presented for sites available, and only those that you are a member of and have been created will appear
  4. Stay logged in for case 2b

-Additional step for programmers (Case 2ai), verify that data presented in tabs matches server log data-

  • Data to Be Used:
    QA determines

Test Cleanup
None

...

Note
titleCase 2b, Realms refresh test

Description = Test the capability of the AuthxGroups to be updated more frequently than default OOTB

Category of Testing = functionality,regression

Prerequisite Steps

  1. Site user is a member of must be already created prior to test (via Batch? via manually?)
  2. User must be a member of the sites in order to see the tab
  3. If user is an externally provided one, then they must be in either the external database (Banner) or already in the internal SmartSite database

Test Scenario 2b, Realms refreshing

  1. Staying as user from Case 2a, record the site tab that is highlighted
  2. Brian Donnelly or Scott Amerson will add a user to this given site, through the external db (by adding a user this way, the 15 minute refresh doesn't have to occur to see the end results)
  3. Scott will notify Pat Kava of what user has been added to the course externally
  4. Pat will verify that by hitting the browser refresh after 5 minutes elapsed since update, that the user added appears as a member in the site

-Additional step for programmers (Case 2bi), verify that authz refresh is happening via the log output, and at what intervals-

  • Data to Be Used:
    QA determines

Test Cleanup
None

...

Note
titleCase 3b, Roster Update Tests (student add(1), student drop(2))

Description = Test the capability of the CourseMangementProvider to accurately reflect within the SmartSite UI, students added to a Banner roster within an alotted time period

Category of Testing = functionality,regression

Prerequisite Steps
*Current roster given or available to QA for respective courses to be tested
*Courses with test CRN's are created either by batch list or full batch mode

Info
titleCase 3b(1), Roster add

Test Scenario 3b(1), Roster Add

  1. Coordinator will talk to Libby about adding:
    student pidm (2204701), kerberos name kdas to CRN (2006-10-)28142
    student pidm (163004),kerberos name larivers to CRN (2006-10-)28142
    student pidm (163004),kerberos name larivers to CRN (2006-10-)26423
  2. Record times when updates start, and when they are finished
  3. Wait until external db refresh happens, based on recorded time(s)
  4. Coordinator will advise testers when update has occured
  5. Log in as instructor for one of these courses, and click Site Info to view updated roster adds above

Description = Test the capability of the CourseMangementProvider to accurately reflect within the SmartSite UI, students dropped from a Banner roster within an alotted time period

Category of Testing = functionality,regression

Prerequisite Steps
Current roster given to QA for respective courses to be tested

Info
titleCase 3b(2), Roster removedrop

Test Scenario 3b(2), Roster Delete

  1. Coordinator will talk to Libby about adding:
    student pidm (1107630), kerberos name dclu dropped from CRN (2006-10-)13185
    student pidm (2218507), kerberos name djf27 dropped from CRN (2006-10-)32457
  2. Record times when updates start, and when they are finished
  3. Wait until external db refresh happens, based on recorded time(s)
  4. Coordinator will advise testers when update has occured
  5. Log in as instructor for one of these courses, and click Site Info to view updated roster deletes above
  6. Log in as kerberos names above, see if any 2006 Fall tabs show up
  • Data to Be Used:
    QA determines if there are additional updates from list of available sites above.

Test Cleanup
None

...

Note
titleCase 3d, Instructor Change Tests (instructor add(1), instructor remove(2), instructor change from staff(3))

Description = Test the capability of the CourseMangementProvider to accurately reflect within the SmartSite UI, instructors added to a Banner course within an alotted time period

Category of Testing = functionality,regression

Prerequisite Steps
*Current roster given or available to QA for respective courses to be tested
*Courses with test CRN's are created either by batch list or full batch mode

Info
titleCase 3d(1), Instructor add

Test Scenario 3d(1), Instructor Add

  1. Coordinator will talk to Libby about adding:
    instructor uid (612026), kerberos name jordi to CRN (2006-10-)10013 mfharris prev inst(mfharris is previous instructor)
    instructor uid (610902),kerberos name palmer to CRN (2006-10-)10033 oluwa prev inst(oluwa is previous instructor)
  2. Record times when updates start, and when they are finished
  3. Wait until external db refresh happens, based on recorded time(s)
  4. Coordinator will advise testers when update has occured
  5. Log in as the respective instructor for one of these courses, and click Site Info to view updated member list (instructor) above
  6. Record other instructor represented in course, given by [] above

Description = Test the capability of the CourseMangementProvider to accurately reflect within the SmartSite UI, instructors removed from a Banner course within an alotted time period

Category of Testing = functionality,regression

Prerequisite Steps
Current roster given to QA for respective courses to be tested

Info
titleCase 3d(2), Instructor remove

Test Scenario 3d(2), Instructor Delete

  1. Coordinator will talk to Libby about removing:
    kerberos name mfharris (148041) from CRN 10025 (mfharris was only instructor, now should be Staff)
    kerberos name fzturner (610916) from CRN 10024 (fzturner was only instructor, now should be Staff)
  1. Record times when updates start, and when they are finished
  2. Wait until external db refresh happens, based on recorded time(s)
  3. Coordinator will advise testers when update has occured
  4. Log in as instructor for one of these courses, see if site tabs for CRNs appear
  5. Log in as admin, see if instructors appear for courses

Description = Test the capability of the CourseMangementProvider to accurately reflect within the SmartSite UI, staff removed from a Banner course, and replaced with another instructor within an alotted time period

Category of Testing = functionality,regression

Prerequisite Steps
Current instructors given to QA for respective courses to be tested

Info
titleCase 3d(3), Instructor added in place of staff

Test Scenario 3d(3), Instructor added, Staff Removed

  1. Coordinator will talk to Libby about adding:
    kerberos name mfharris (148041) to CRN 10037 (mfharris should be only instructor, replacing Staff)
  1. Record times when updates start, and when they are finished
  2. Wait until external db refresh happens, based on recorded time(s)
  3. Coordinator will advise testers when update has occured
  4. Log in as instructor mfharris for one of these courses, see if site tabs for CRNs appear
  5. Log in as admin, see if instructor appears for course
  • Data to Be Used:
    QA determines if there are additional updates from list of available sites above.

Test Cleanup
None

...

results: Recorded in Jira http://jira.ucdavis.edu:8080/jira/browse/SAK-124202

Recording Results

The test results will be recorded in Jira by QA testers. They can be of table form or text form.

...