Page Comparison

...

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.

...

Tip

title	Purpose for this testing

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

UserDirectoryProvider

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

GroupProvider

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.
Define the sites a user belongs to when they log into SmartSite.

CourseManagementProvider

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.
Display current instructor(s) course sites and display them as members in the course with appropriate role
Display Banner course details in the SmartSite UIDisplay site membership changes in a course site, including instructor adds/removals/updates

...

Realms not refreshing frequent enough
Rosters not accurate with Banner
Drops not showing in SmartSite UI

...

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.

...

title	JIRAs that explain features and past bugs fixed, to be tested in this plan

...

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 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"

...

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-

155 When users log into Sakai, their user information is looked up externally in Mothra, LDAP, or some other central datasource for campus

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-

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:

124 (Banner rosters not in sync with SmartSite UI)
PREVIOUS PROVIDER TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-

157 Course information must be pulled dynamically from Banner, within Sakai

125 (drop student from Banner and not reflected in SmartSite UI)
PREVIOUS PROVIDER TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-

154 User is able to used WebDav in Sakai, with their Kerberos username and password

Info

title	JIRAs 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-124 (Banner rosters not in sync with SmartSite UI)
PREVIOUS PROVIDER 184 (1000 row limit on associations (realms) for sakai internal query)
BATCH TESTING BUGS FIXED:http://jira.ucdavis.edu:8080/jira/browse/SAK-125 (drop student from Banner and not reflected in SmartSite UI185 (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-132 (realms not refreshing fast enough in the providers)

Note

title	JIRAs that reference test scenarios, "QA Tests" described in this test plan

TEST ENVIRONMENT

Hardware Setup

Server Type	Location
database	bricker.ucdavis.edu with banner-test (external db), and sakai test (internal db)
application	isaac.ucdavis.edu, sakai-test
web server	url, http://sakai-test.ucdavis.edu
population of data referenced	2006 Banner Test data (external), and clean sakai internal database with exception of necessary login accounts and manual sites created)

Note: The application does not need to be stopped for these tests to occur

Software Setup
run test under https://mware.ucdavis.edu/svn/ucdsakai/branches/sakai-core-2.1.x branch, with mods from https://mware.ucdavis.edu/svn/ucdakai/sakai-core-2.1.x-scottsdev branch incorporated

Additional Setup Needed
**QA admin account (e.g. QAadmin)
**All login accounts that use kerberos names can be "provided" by the system (e.g. UserDirectoryProvider implemented).
**SU tool and Quartz tools are available in admin workspace/realm
**Testers have access to testable sites (via SU tool, admin workspace, as user QAAdmin, etc.)
**Run CourseManagement tests on existing batched sites perhaps

Additional External-Banner Test Data Used for Provider Testing
A copy of test data that may be used for these test cases is attached: http://confluence.ucdavis.edu:8080/confluence/download/attachments/17096/200603TestData.xls

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 database will be a copy of existing production data, so sakai-test will have to be backed up prior to testing
We will be referencing sakai-test external for populating course data

ROLES AND RESPONSIBILITIES

Testers (QA,students etc)*
Admins and SmartSite Programmers
- Any of the following persons that may be available:
  ***Application admins (Programmers available, including Thomas, Lisa W., James, Brian, Jon G., Scott)
  ***Database/system admins (Geeta Rayala, Chris Callahan)
  ***Banner admins (e.g. Libby Bullock)

*All of the above users will have access to the admin realm in Sakai, in addition to:
***QAadmin

PROVIDER DOCUMENTATION

132 (realms not refreshing fast enough in the providers)

Note

title	JIRAs 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

TEST ENVIRONMENT

Hardware Setup

Server Type	Location
INTEGRATION TESTING	SETUP
database	bricker.ucdavis.edu with banner-test (external db), and sakai dev (internal db)
application	hanley.ucdavis.edu, sakai-dev
web server	url, https://hanley.ucdavis.edu:8443/portal
population of data referenced	2006 Fall Quarter Banner Test data (external), and clean sakai internal database with exception of necessary login accounts and manual sites created)

Server Type	Location
QA TESTING	SETUP
database	bricker.ucdavis.edu with banner-test (external db), and sakai test (internal db)
application	isaac.ucdavis.edu, sakai-test
web server	url, http://sakai-test.ucdavis.edu
population of data referenced	2006 Fall Quarter Banner Test data (external), and clean sakai internal database with exception of necessary login accounts and manual sites created)

Note: The application does not need to be stopped for these tests to occur

Software Setup
run test under https://mware.ucdavis.edu/svn/ucdsakai/branches/sakai-core-2.1.x branch, with mods from https://mware.ucdavis.edu/svn/ucdakai/sakai-core-2.1.x-scottsdev branch incorporated

Additional Setup Needed
**QA admin account (e.g. QAadmin)
**All login accounts that use kerberos names can be "provided" by the system (e.g. UserDirectoryProvider implemented).
**SU tool and Quartz tools are available in admin workspace/realm
**Testers have access to testable sites (via SU tool, admin workspace, as user QAAdmin, etc.)
**Run CourseManagement tests on existing batched sites perhaps? or run CourseManagementTests on new Fall Quarter Courses batched?
mView refresh times must be recorded
Additional External-Banner Test Data Used for Provider Testing
A copy of test data that may be used for these test cases is attached: http://confluence.ucdavis.edu:8080/confluence/displaydownload/UCDSAKAI/UC+Davis+Data+Provisioning

General Provider and Batching interaction documented at https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/Requirements+for+Data+Provisioning+using+Providers+and+Batch+Processes

Functionality * attachments/17096/200603TestData.xls
An example of a white list file to be used for course creation is: http://confluence.ucdavis.edu:8080/confluence/download/displayattachments/UCDSAKAI/Sakai+Providers

UNIT AND INTEGRATION TEST RESULTS

Unit Test Results

The JUnit tests results that have been previously run on sakai-dev (isaac) are at:
http://confluence.ucdavis.edu:8080/confluence/display/UCDSAKAI/SmartSite+Provider+Unit+Test+Results%2C+run+Sep+11%2C+2006
In summary, all unit tests passed!!

Integration Test Results

TEST PLAN PROCESS

This SmartSite Provider QA Test Plan will be coordinated by Pat Kava, with assistance from the programming group (e.g. Scott Amerson), and will document the results of QA testing. It is assumed that all bugs have been documented by the programming group as issues before handing off to QA.

Steps involved in the test process will be varied depending on the given test performed (as described below in the Test Cases section).

Info

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

Setup Case (0a): Accessing server
Setup Case (0b): Login access via DistAuth
Setup Case (0c): Login outside of DistAuth (e.g. internal account)
Setup 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) Adds/drops of students from Banner seen in SmartSite UI
3b) Rosters from Banner viewed by instructor and administrator role in site
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

TEST CASES

Info

title	Key for Test Case Scenarios

Description = description of the test performed
Category of Testing = the described testing is at what level?
Prerequisite Steps = actions needed before performing any of the given tests

PRELIMINARY TESTS

Case 0 #Access,Login Test Cases

Case 0a

Note

title	Setup Test Case Scenario 0a, Accessing test server

Description = Test the capability of the user to access the test server

Category of Testing = functionality,regression

Prerequisite Steps
None

Test Scenario 0a

go to http://sakai-test.ucdavis.edu in your browser

Test Cleanup
None

Test Results 0a

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Access to SmartSite,	Pat Kava	mpkava	access	access	P

Case 0b

...

17226/white-list.txt

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.
We will be referencing sakai-test (banner test external, mViews..) for populating course data

ROLES AND RESPONSIBILITIES

Testers (QA,students etc)*
Admins and SmartSite Programmers
- Any of the following persons that may be available:
  ***Application admins (Programmers available, including Thomas, Lisa W., James, Brian, Jon G., Scott)
  ***Database/system admins (Geeta Rayala, Chris Callahan)
  ***Banner admins (e.g. Libby Bullock)

*All of the above users will have access to the admin realm in Sakai, in addition to:
***QAadmin

PROVIDER DOCUMENTATION

Requirements
Provider requirements at: http://confluence.ucdavis.edu:8080/confluence/display/UCDSAKAI/UC+Davis+Data+Provisioning

General Provider and Batching interaction documented at https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/Requirements+for+Data+Provisioning+using+Providers+and+Batch+Processes

Functionality * http://confluence.ucdavis.edu:8080/confluence/display/UCDSAKAI/Sakai+Providers

UNIT AND INTEGRATION TEST RESULTS

Unit Test Results

The JUnit tests results that have been previously run on sakai-dev (isaac) are at:
http://confluence.ucdavis.edu:8080/confluence/display/UCDSAKAI/SmartSite+Provider+Unit+Test+Results%2C+run+Sep+11%2C+2006
In summary, all unit tests passed!!

Integration Test Results

TEST PLAN PROCESS

This SmartSite Provider QA Test Plan will be coordinated by Pat Kava, with assistance from the programming group (e.g. Scott Amerson), and will document the results of QA testing. It is assumed that all bugs have been documented by the programming group as issues before handing off to QA.

Steps involved in the test process will be varied depending on the given test performed (as described below in the Test Cases section).

Info

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

Preliminary Case (0a): Accessing server
Preliminary Case (0b): Login access via DistAuth
Preliminary Case (0c): Login outside of DistAuth (e.g. internal account)
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
2b) Realm refresh via browser refresh button

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

TEST CASES

Info

title	Key for Test Case Scenarios

Description = description of the test performed
Category of Testing = the described testing is at what level?
Prerequisite Steps = actions needed before performing any of the given tests

PRELIMINARY TESTS

Case 0 #Access,Login Test Cases

Case 0a

Note

title	Setup Test Case Scenario 0a, Accessing test server

Description = Test the capability of the user to log into access the test server using their valid kerberos name

Category of Testing = functionality,regression

Prerequisite Steps
User has valid kerberos name
If not, go to http://computingaccounts.ucdavis.edu to set one upTest Scenario 0b None

Test Scenario 0a

go to http://sakai-test.ucdavis.edu in your browser
user will click on login link on rhs

Test Cleanup
None

Test Results 0b0a

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Login Access to SmartSite, (DistAuth)	Pat Kava	mpkava	logged in, user in "Users Present"	logged in, name in "Users Present"access	access	P

Case 0c0b

Note

title	Setup Test Case Scenario 0c0b, Logging into test server via SmartSite's internal accountsSecureWeb (DistAuth)

Description = Test the capability of the user to log into the test server using a their valid SmartSite accountkerberos name

Category of Testing = functionality,regression

Prerequisite Steps
User has valid account kerberos name, password known
If not, go to http://computingaccounts.ucdavis.edu to set one up

Test Scenario 0c0b

go to http://sakai-test.ucdavis.edu/portal/xlogin in your browser
user will enter username and password given
User will use admin account name
User will use QAAdmin account name
User will use sakaistudent1, etc.??click on login link on rhs

Test Cleanup
None

Test Results 0c0b

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Login to SmartSite, SmartSite account(DistAuth)	Pat Kava	QAAdminmpkava	logged in, user in "Users Present"	logged in, name in "Users Present"	P

Case 0d0c

Note

title	Setup Test Case Scenario 0d0c, Logging into test server via SmartSite's internal admin account, seeing necessary toolsaccounts

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 0d0c

go to http://sakai-test.ucdavis.edu/portal/xlogin in your browser
user will enter username and password given
User will use admin account nameView site information for a given site (e.g. see Sites link in Admin workspace)
User will logout of admin use QAAdmin account name
User will use QAAdmin account name
Become a user using SU Tool
Logout of using SU Tool
sakaistudent1, etc.??

Test Cleanup
None

Test Results 0d
For scenario 0d, the following actions0c

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Login to SmartSite, SmartSite admin account	Pat Kava	adminQAAdmin	logged in, user in "Users Present"	logged in, name in "Users Present"	P
Login to SmartSite, SmartSite admin account	Pat Kava	admin	see admin workspace	see admin workspace	P
Login to SmartSite, SmartSite admin account	Pat Kava	admin	see Sites link	Sites link accessable	P
Logout of SmartSite, using logout link	Pat Kava	admin	logout happens	logout happens	P
Login to SmartSite, using QAAdmin account	Pat Kava	QAAdmin

Case 0d

Note

title	Setup Test Case Scenario 0d, Logging into test server via SmartSite's internal admin account, seeing necessary tools

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

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

Test Cleanup
None

Test Results 0d
For scenario 0d, the following actions:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Login to SmartSite, SmartSite admin account	Pat Kava	admin	logged in, user in "Users Present"	logged in, name in "Users Present"	PSee SU page link
Login to SmartSite, SmartSite admin account	Pat Kava	QAAdmin	SU page/tool available	SU page/tool accessable	P	SU as some instructor using SU Tooladmin	see admin workspace	see admin workspace	P
Login to SmartSite, SmartSite admin account	Pat Kava	QAAdmin	SU by "View User Info" first, then "Become User"	SU happens correctly, become useradmin	see Sites link	Sites link accessable	P
Logout of SmartSite, using logout link	Pat Kava	SU'd person	admin	logout happens	logout happens	P

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
SmartSite admin account tools available	Pat Kava	admin,QAAdmin	administrative tools available	administrative tools work	P

All Results for Case 0

Tip

title	Results for Setup Provider Tests

results: Recorded in Jira https://jira.ucdavis.edu:8444/jira/browse/SAK-XXX

USERDIRECTORYPROVIDER TESTS

Case 1 #UserDirectorProvider Test Cases

Note

title	WebDav Testing, Case 1a

Description = Test the capability of the UserDirectoryProvider to provide Kerberos authentication for WebDav

Category of Testing = functionality,regression

Prerequisite Steps

One file must be uploaded via the Resources tool prior to using WebDav

Test Scenario 1a, WebDav

Log in as any user having access to any site
Follow WebDav instructions based on instructions in Resource area
* Use "Manage Multiple Resources" link in Resources tool to access WebDav

Data to Be Used:
QA determines

Test Cleanup
None

Results, Case 1a WebDav

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
WebDav authentication	Pat Kava	mpkava	authentication happens, file uploaded available for viewing, etc.	authentication occurs, file access available for upload/download	P

...

Login to SmartSite, using QAadmin account	Pat Kava	QAadmin	logged in, user in "Users Present"	logged in, name in "Users Present"	P
See SU page link	Pat Kava	QAadmin	SU page/tool available	SU page/tool accessable	P
SU as some instructor using SU Tool	Pat Kava	QAadmin	SU by "View User Info" first, then "Become User"	SU happens correctly, become user	P
Logout of SmartSite, using logout link	Pat Kava	SU'd person	logout happens	logout happens	P

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
SmartSite admin account tools available	Pat Kava	admin,QAAdmin	administrative tools available	administrative tools work	P

All Results for Case 0

Tip

title	Results for Setup Provider Tests

results: Recorded in Jira https://jira.ucdavis.edu:

...

8444/jira/browse/SAK-

...

Note
XXX
title

USERDIRECTORYPROVIDER TESTS

Case 1 #UserDirectorProvider Test Cases

Note

title	WebDav Testing, Case 1b1a

Description = Test the capability of the UserDirectoryProvider to provide information about an externally provided user via the SU ToolKerberos authentication for WebDav

Category of Testing = functionality,regression

Prerequisite Steps

SU tool available to testerOne file must be uploaded via the Resources tool prior to using WebDav

Test Scenario 1b1a, User lookup functionalityWebDav

Log in as any user having administrative access (access to admin realm)
Use a given kerberos name available via test data (e.g. instructor)
Enter kerberos name, and click "View User Info"
Verify user information from whois.ucdavis.edu and/or email.ucdavis.eduto any site
Follow WebDav instructions based on instructions in Resource area
* Use "Manage Multiple Resources" link in Resources tool to access WebDav

Data to Be Used:
QA determines

Test Cleanup
None

Test Results Case 1b, User Lookup functionality, Case 1a WebDav

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
User information verificationWebDav authentication	Pat Kava	QAAdmin	look up user with valid kerberos name	User's name, email address and "registered" type are validmpkava	authentication happens, file uploaded available for viewing, etc.	authentication occurs, file access available for upload/download	P

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

GROUPPROVIDER TESTS

Case 2 #GroupProvider Test Cases

154

Case 3a, Roster Update Tests (student add(1), student drop(2))

Note

title	Case 2a, Group Provider Tabs testUser Lookup Testing, Case 1b

Note

title

Description = Test the capability of the GroupProvider UserDirectoryProvider to provide tabs for a user based on their enrollment/membership in sites information about an externally provided user via the SU Tool

Category of Testing = functionality,regression

Prerequisite Steps

Site user is a member of must be already created prior to test (via Batch? via manually?)
User must be a member of the sites in order to see the tab
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

Log in as in Case 0d, but become the user and don't log out
Log in instructor for a given site site (see test data attachment)
View tabs presented for sites available, and only those that you are a member of and have been created will appear
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

Test Results Case 2a, Tab functionality

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Site tab check	Pat Kava	fzolupon?	site tabs xxxx,xxxxx,xxxxx seen	all sites seen that have been created prior to logging in	P

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

Note

title	Case 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

Site user is a member of must be already created prior to test (via Batch? via manually?)
User must be a member of the sites in order to see the tab
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

Staying as user from Case 2a, record the site tab that is highlighted
Brian Donnelly 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)
Scott will notify Pat Kava of what user has been added to the course externally
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

Test Results Case 2b, Realm refresh functionality

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Authz check	Pat Kava	fzolupon?	user xxxxx seen in roster?	user xxxx seen in SmartSite, site yyyyy roster after 5 minutes	P

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

COURSEMANAGEMENTPROVIDER TESTS

Case 3 #CourseManagementProvider Test Cases

Note

title	Possible data set to use for CourseManagementProvider Tests, carried over from Batch Testing

CRN with no enrollment	2006-06-60245	0	fzduts (Dennis Dutschke)	ITA 198 S01 Dir Group Study	Summer Special Session 2006	Black List	white-list.txt
CRN with large enrollment number	2006-01-60001	84 (all valid knames)	ewlarsen (Eric Larsen)	LDA, 190 , 001, ProSeminar	Winter Quarter 2006	Black List	white-list.txt,black-list.txt
CRN with enrollment	2006-01-40018	14 (all valid knames)	calymos (Calvin Lymos)	AAS, 154, 001, University Gospel Choir	Winter Quarter 2006	Black List	white-list.txt,black-list.txt
CRN with enrollment	2006-03-82882	10	ltcmwc (Mark Connelly)	MSC 141 002 Army Mngmt Systems	Spring Quarter 2006	Black List	black-list.txt
CRN with enrollment	2006-03-83634	10 (all valid knames)	eschang (Ernest Chang)	NPB 141P 001 Res In Physio Adapt	Spring Quarter 2006	Black List	black-list.txt

SU tool available to tester

Test Scenario 1b, User lookup functionality

Log in as any user having administrative access (access to admin realm)
Use a given kerberos name available via test data (e.g. instructor)
Enter kerberos name, and click "View User Info"
Verify user information from whois.ucdavis.edu and/or email.ucdavis.edu

Data to Be Used:
QA determines

Test Cleanup
None

Test Results Case 1b, User Lookup functionality

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
User information verification	Pat Kava	QAAdmin	look up user with valid kerberos name	User's name, email address and "registered" type are valid	P

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

GROUPPROVIDER TESTS

Case 2 #GroupProvider Test Cases

Note

title	Case 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

Site user is a member of must be already created prior to test (via Batch)
User must be a member of the sites in order to see the tab
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

Log in as in Case 0d, but become the user and don't log out
Log in instructor for a given site site (see test data in CourseManagementProvider test section)
View tabs presented for sites available, and only those that you are a member of and have been created will appear
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

Test Results Case 2a, Tab functionality

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Site tab check	Pat Kava	fzolupon?	site tabs xxxx,xxxxx,xxxxx seen	all sites seen that have been created prior to logging in	P

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

Note

title	Case 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

Site user is a member of must be already created prior to test (via Batch)
User must be a member of the sites in order to see the tab
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

Staying as user from Case 2a, record the site tab that is highlighted
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)
Scott will notify Pat Kava of what user has been added to the course externally
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

Test Results Case 2b, Realm refresh functionality

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Authz check	Pat Kava	fzolupon?	user xxxxx seen in roster?	user xxxx seen in SmartSite, site yyyyy roster after 5 minutes	P

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

COURSEMANAGEMENTPROVIDER TESTS

Case 3 #CourseManagementProvider Test Cases

Possible Test Data

Note

title	Possible data set to use for CourseManagementProvider Tests, carried over from Batch Testing

CRN Type	Term code - crn	enrollment	instructor kname	Course info	Term
CRN with no enrollment	2006-06-60245	0	fzduts (Dennis Dutschke)	ITA 198 S01 Dir Group Study	Summer Special Session 2006
CRN with large enrollment number	2006-01-60001	84 (all valid knames)	ewlarsen (Eric Larsen)	LDA, 190 , 001, ProSeminar	Winter Quarter 2006
CRN with enrollment	2006-01-40018	14 (all valid knames)	calymos (Calvin Lymos)	AAS, 154, 001, University Gospel Choir	Winter Quarter 2006
CRN with enrollment	2006-03-82882	10	ltcmwc (Mark Connelly)	MSC 141 002 Army Mngmt Systems	Spring Quarter 2006
CRN with enrollment	2006-03-83634	10 (all valid knames)	eschang (Ernest Chang)	NPB 141P 001 Res In Physio Adapt	Spring Quarter 2006

Note

title	Additional data set to use for CourseManagementProvider Tests, using Fall Quarter 2006 data

CRN Type	Term code - crn	enrollment	instructor kname	Course info	Term
CRN with enrollment	2006-10-13185	7	jordi, (Donald Palmer)	ARE,200A,001,Microeconomic Theory	Fall Quarter 2006
CRN with enrollment, no inst	2006-10-18933	29	staff	EAP,350,001,France	Fall Quarter 2006
CRN with enrollment, no inst	2006-10-18954	45	staff	EAP,862,001,UK/Ireland/Wales	Fall Quarter 2006
CRN with enrollment	2006-10-26423	5	osleger	GEL,025,001,Geology National Parks	Fall Quarter 2006
CRN with enrollment	2006-10-28142	8	bossler	HIS,204,003,Historiography	Fall Quarter 2006
CRN with enrollment, no inst	2006-10-30220	6	staff	MAT,012,002,Precalculus	Fall Quarter 2006
CRN with enrollment	2006-10-32457	5	palmer, (Joaquim Silvestre)	MGP,223,001,Power and Influence	Fall Quarter 2006
CRN with enrollment	2006-10-32454	2	hemantb, (Hemant Bhargava)	MGP,207,001,Mgmt Info Systems	Fall Quarter 2006
CRN with enrollment, no inst, no enrollment	2006-10-21225	0	staff	ECS,298,017,Group Study	Fall Quarter 2006
CRN with enrollment, no inst, no enrollment	2006-10-40185	0	staff	SAS,097T,000,Tutoring Sci & Society	Fall Quarter 2006

Case 3a, Roster View Tests

Note

title	Case 3a, Roster View Test

Description = Test the capability of the CourseMangementProvider to accurately reflect within the SmartSite UI, the roster from a site administrator perspective

Category of Testing = functionality,regression

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

Info

title	Case 3a, Roster view, admin or instructor

Test Scenario, Case 3a

SU as instructor as given by Case 0d, and for this case use kerberos name palmer.
Data Used
CRN Type
Term code - crn
enrollment
instructor kname
Course info
Term
CRN with enrollment
2006-10-32457
5
palmer, (Joaquim Silvestre)
MGP,223,001,Power and Influence
Fall Quarter 2006
roster to be given
Verify roster is same as given
Do same as above for the admin user. Note, if the admin user is not a member of the site, then you will not see a tab. You will need to go to "WorkSite Setup" and click "Revise" to see roster information.

Case 3b, Roster Update Tests

Note

title	Case 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

title	Case 3b(1), Roster add

Test Scenario 3b(1), Roster Add

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
Record times when updates start, and when they are finished
Wait until external db refresh happens, based on recorded time(s)
Coordinator will advise testers when update has occured
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

title	Case 3b(2), Roster drop

Test Scenario 3b(2), Roster Delete

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
Record times when updates start, and when they are finished
Wait until external db refresh happens, based on recorded time(s)
Coordinator will advise testers when update has occured
Log in as instructor for one of these courses, and click Site Info to view updated roster deletes above
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

Test Results Case 3b(1),3b(2), Roster update functionality

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Roster add check	Pat Kava	x	roster added with Student xxxxx	Roster added with Student kerb name	P
Roster drop check	Pat Kava	x	roster changed with Student xxxxx removed	Roster changed accordingly with kerb name xxxx removed	P

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

Case 3c, Roster Accuracy Tests

Note

title	Case 3c, Roster Accuracy Tests

Description = Test the capability of the CourseMangementProvider to accurately reflect within the SmartSite UI, members in a Roster (site member) list

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

title	Case 3c, Roster accuracy check

Test Scenario 3c, Roster accuracy

Find Fall Quarter CRN available from the list above, one with roster
Log in as instructor for one of these courses, see roster appears
Verify roster with that of MyUCDavis website

Data to Be Used:
QA determines if there are additional updates from list of available sites above.

Test Cleanup
None

Test Results Case 3c Roster check

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Expected Result	Expected Result	Expected Result	Pass/Fail
Roster check	Pat Kava	instructor x	site has accurate number of members	site has accurate instructor kerb name, user name	site has accurate students kerb name, user name	Format correct for member list	Member list formatted correctly	P

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

Case 3d, Instructor Change Tests

Note

title	Case 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

title	Case 3d(1), Instructor add

Test Scenario 3d(1), Instructor Add

Coordinator will talk to Libby about adding:
instructor uid (612026), kerberos name jordi to CRN (2006-10-)10013 (mfharris is previous instructor)
instructor uid (610902),kerberos name palmer to CRN (2006-10-)10033 (oluwa is previous instructor)
Record times when updates start, and when they are finished
Wait until external db refresh happens, based on recorded time(s)
Coordinator will advise testers when update has occured
Log in as the respective instructor for one of these courses, and click Site Info to view updated member list (instructor) above
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

title	Case 3d(2), Instructor remove

Test Scenario 3d(2), Instructor Delete

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)

Record times when updates start, and when they are finished
Wait until external db refresh happens, based on recorded time(s)
Coordinator will advise testers when update has occured
Log in as instructor for one of these courses, see if site tabs for CRNs appear
Log in as admin, see if instructors appear for courses

Description = Test the capability of the CourseMangementProvider to accurately reflect within the SmartSite UI, students added to a Banner roster 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

title	Case 3a(1), Roster add

Test Scenario 3a(1), Roster Add

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

Category of Testing = functionality,regression

Prerequisite Steps

Test Scenario 3a(2), Roster Delete

Info

title	Case 3a(2), Roster remove

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

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

Coordinator will talk to Libby about adding:
kerberos name mfharris (148041) to CRN 10037 (mfharris should be only instructor, replacing Staff)

Record times when updates start, and when they are finished
Wait until external db refresh happens, based on recorded time(s)
Coordinator will advise testers when update has occured
Log in as instructor mfharris for one of these courses, see if site tabs for CRNs appear
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 and data what roster to updateabove.

Test Cleanup
None

Test Results Case 3a3d(1),3a3d(2), Roster Add 3d(3) Instructor update functionality

Would yield an example Summary Test Result of:

Test	User	User Acting As	Result	Expected Result	Pass/Fail
Roster Instructor add check	Pat Kava	x	roster CRN xxxx added with Student instructor xxxxx	Roster added with Student kerb name	P	Roster drop Instructor added to list	P
Instructor remove check	Pat Kava	x	CRN changed with instructor xxxxx removed	Member list changed with kerb name xxxx removed	P
Instructor change staff to instructor check	Pat Kava	x	roster changed with Student xxxxx removed	Roster changed accordingly changed staff for course 2006-10-10037 to instructor kerb name mfharris	Member list changed with kerb name xxxx removed	P

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.

...

Versions Compared

Old Version 93

New Version Current

Key

TEST PLAN OVERVIEW

TEST ENVIRONMENT

DEPENDENCIES

ROLES AND RESPONSIBILITIES

PROVIDER DOCUMENTATION

TEST ENVIRONMENT

UNIT AND INTEGRATION TEST RESULTS

Unit Test Results

Integration Test Results

TEST PLAN PROCESS

TEST CASES

PRELIMINARY TESTS

Case 0 #Access,Login Test Cases

DEPENDENCIES

ROLES AND RESPONSIBILITIES

PROVIDER DOCUMENTATION

UNIT AND INTEGRATION TEST RESULTS

Unit Test Results

Integration Test Results

TEST PLAN PROCESS

TEST CASES

PRELIMINARY TESTS

Case 0 #Access,Login Test Cases

USERDIRECTORYPROVIDER TESTS

Case 1 #UserDirectorProvider Test Cases

USERDIRECTORYPROVIDER TESTS

Case 1 #UserDirectorProvider Test Cases

GROUPPROVIDER TESTS

Case 2 #GroupProvider Test Cases

COURSEMANAGEMENTPROVIDER TESTS

Case 3 #CourseManagementProvider Test Cases

GROUPPROVIDER TESTS

Case 2 #GroupProvider Test Cases

COURSEMANAGEMENTPROVIDER TESTS

Case 3 #CourseManagementProvider Test Cases

Recording Results