Page Comparison

The purpose of this test plan is to regression test the provider functionality, which in SmartSite includes:

UserDirectoryProvider

1. Support for WebDav authentication (via Kerberos)
2. Provide user account information (e.g. first,last,email,type) from outside data source (e.g. feed from Mothra)

GroupProvider

1. Assign roles to users who log in to SmartSite that correspond to Sakai internal roles (e.g. Student, Instructor) when applicable. These roles need to be queried from an external data source (e.g. Banner mViews), so that authorization can be determined in real-time.
2. Define the sites a user belongs to when they log into SmartSite.

CourseManagementProvider

1. Retrieve dynamic rosters for courses, including updates within specific time interval. Roster updates from Banner need to be displayed in the SmartSite application within a pre-determined acceptable time period as defined by the user acceptance testing group.
2. Display current instructor(s) course sites and display them as members in the course with appropriate role
3. Display Banner course details in the SmartSite UIDisplay site membership changes in a course site, including instructor adds/removals/updates

*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
3b) Rosters from Banner viewed by instructor and administrator role in site
3c) 3c) Roster details accurate (e.g. kname, role, etc)
3d) Instructor changes for a course seen in participants list for a site 3e) Course Site information viewed by instructor seen in site summary details

Description = Test the capability of the user to log into the test server using a valid SmartSite admin account and see SU Tool, and other admin functionality

Category of Testing = functionality,regression

Prerequisite Steps
User has valid admin account name, password known

Test Scenario 0d

1. go to http://sakai-test.ucdavis.edu/portal/xlogin in your browser
2. user will enter username and password given
3. User will use admin account name
4. View site information for a given site (e.g. see Sites link in Admin workspace)
5. User will logout of admin account
6. User will use QAAdmin QAadmin account name
7. Become a user using SU Tool
8. Logout of using SU Tool

Test Cleanup
None

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

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

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