Course Batch Creation Test Plan, Unit and Integration Testing
TEST PLAN DATE
Testing occurred, 9/5/06, 4:15pm-5:15pm.
TEST PLAN OVERVIEW
Scope of testing
This testing is designed to document the unit and integration test results of the programming team. For certain test cases, as described in the Test Cases section, the level of testing previously performed to handing off to QA will be documented. The level of involvement by system admins and programmers will be detailed for each test case.
Purpose for this testing
The automatic course creation mechanism for SmartSite. Course sites, when done automatically via chron jobs, can be created and/or updated in several ways
- On-Demand List of courses (White list)
- Will create only a pre-defined list of course sites
- Not specific to a Term
- Excluded List of courses (Black list)
- Will not be created by any mechanism
- Auto-update of existing course sites with group update (e.g. provider id)
- Sets existing sites with the assigned provider id value, and will not provision a duplicate site with same provider id from full other batch run
- Full run of course creation for a designated term (will not batch white or black lists, as well as not create sites with Provider Id to be set)
Additional Items slated for testing
- Manually update provider Id for a site
- Need to be done as a an admin user, or one that has access to admin realm
- -See the results of the realms being refreshed (Jon's patch)-
KNOWN ISSUES / PREVIOUS BUGS FIXED
- There is one known issue for this testing, related to the Home Page web content displayed for course sites. Currently, the Course Description information displays course title, which will be changed to description when the external data is mapped to a description field.
JIRAs that explain features to be tested in this plan
http://jira.ucdavis.edu:8080/jira/browse/SAK-23 (Add ability to customize pages and tools added to pages (both default and provisional) when provisioning course sites)
http://jira.ucdavis.edu:8080/jira/browse/SAK-25 (Remove admin user from sites, during course creation script)
http://jira.ucdavis.edu:8080/jira/browse/SAK-119 (Course White List)
http://jira.ucdavis.edu:8080/jira/browse/SAK-121 (Batch provisioning should make a toolset based on OOTB and other (provisional and contrib) tools)
http://jira.ucdavis.edu:8080/jira/browse/SAK-136 (Add Course title (from Banner) is the field presently mapped for course description information when provisioning sites. A course description (short and long) should be mapped from external data so that it can be referenced by certain course tools)
http://jira.ucdavis.edu:8080/jira/browse/SAK-140 (Course Black List)
http://jira.ucdavis.edu:8080/jira/browse/SAK-141 (Batching is done under a 'batch admin' user)
http://jira.ucdavis.edu:8080/jira/browse/SAK-146 (Set Provider Id For Manually Created Courses)
other non-batch related JIRAs covered:
http://jira.ucdavis.edu:8080/jira/browse/SAK-143 (enable distributed authentication using AFS file system)
TODO http://jira.ucdavis.edu:8080/jira/browse/SAK-133 (AuthZ refresh test)
JIRAs that reference test scenarios described in this test plan
TEST ENVIRONMENT
- Hardware Setup
Server Type
Location
database
bricker.ucdavis.edu with banner-test (external db), and sakai dev (internal db)
application
isaac.ucdavis.edu, sakai-dev
web server
url,
http://sakai-dev.ucdavis.edu
- 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
**Batch admin account (e.g. ssbatchadmin)
**Programmers have access to testable sites (via SU tool, admin workspace)
**SU tool and Quartz tools are available in admin workspace/realm
**All login accounts that reference kerberos names can be "provided"
- External-Banner Test Data to be Used As Representative Course Scenarios (see each test case)
- A few test course sites need to be created in advance so that the batch job can modify these sites with a respective provider Id. These sites are documented in the Provider Id Test Section.
DEPENDENCIES
- At least UserDirectoryProvider enabled to allow user accounts to be looked up automatically via kerberos name (Note:all Providers will be enabled)
- Distributed authentication using AFS (SAK-143)
- Sakai-dev will be used in its current state
- We will be referencing sakai-test external for populating course data
ROLES AND RESPONSIBILITIES
- Unit/Integration Testers (Programmers, Managers, etc)*
which would include any of the following persons that may be available:- Application admins (Programmers available, including Thomas, Lisa W., James, Brian, Jon G., Scott)
- Database mViews admin (Brian Donnelly)
Programmers/Managers available ??:
Sandra
Thomas
Brian
Jon G.
James
(Emily)
All of the above users will have access to the admin realm in Sakai, in addition to:
ssbatchadmin
COURSE SITE BATCHING DOCUMENTATION
- Requirements
The requirements for batching are documented at https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/Course+Batching+Strategy
JUNIT TEST RESULTS
The JUnit tests results are located on the server at:
/var/sakai/ucd-data/course-batch-unit-tests-082006
Also, the test results can be found here https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/Course+Batch+Creation+Unit+Test+Results
All unit tests passed!!
TEST PLAN PROCESS
This Course Batching Unit/Integration Test Plan will be coordinated by Scott Amerson, and will document the results of unit testing and integration testing for the batching process before handing off to QA. All tests must pass 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).
*NOTE: The order of the test cases will be as follows.
White List Testing,
Black List Testing,
Provider Id Testing, and
Full Batch Run
- Site Functionality Testing, Course Management Testing, and Provider Id testing are each part of the White List testing scenario.
- In order to test the Black List functionality, we will need to have a superset of CRNs that are trying to be added at the same time. To accomplish this, we will use the White List scenario with a same CRN that is included in the Black List file. See Black List Test Scenario for more information.
TEST CASES
Key for Test Case Scenarios
Prerequisite Steps = actions needed before performing any of the given tests
Category of Testing = the described testing is at what level?
Description = description of the test performed
White List
White List Testing
Description = Test the capability of the system to add "on-demand" course sites that are listed in a file. Courses are not required to have any enrollment in order to be created.
Category of Testing = unit, integration
Prerequisite Steps
- Scott will add a list of CRNs (valid or not) as the white-list.txt file in /var/sakai/ucd-data folder on the server, in the form of TERMYR-TERMCD-CRN for each entry. Use this file file to use here
- Scott will que the batch job to run, only for the above list (5 min elapsed time needed)
- Scott will give maintain permissions on the applicable sites, to the appropriate users
- Brian = look up CRN 1995-01-76288
- Sandra = look up CRN 2006-06-60005
- Scott will assist users in accessing the site(s) if needed
- Thomas = view logs, look for CRN 20061-06-111, 2006-03-60024
- Jon G. = look up CRN 2006-sfs-sfsfdfsdfsfsfs
- Scott will advise programmers that the batch has been run and sites have been created
- Thomas and Scott will monitor server activity while testers are using sakai-dev.
Test Scenario
- Above users will perform functionality testing for each CRN, including :
**perform functionality test https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/Course+Site+Functionality+Tests%2C+SmartSite+Batch+Integration+Testing+Matrix for each site
**perform course management test https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/SmartSite+Course+Site%2C+Course+Management+Integration+Test+Matrix for each site
**perform provider id test https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/SmartSite+Provider+Id+Update+of+Existing+Sites%2C+Integration+Test+Matrix for each site
- Data to Be Used:
Scenario
Course
Roster Count
Instructor Kerb Name
Course Details (Catalog Root, Suffix, Section, Description)
Test Case Used In
File Associated
Invalid CRNs
Invalid CRN (Number)
20061-06-111
NA
NA
NA
NA
White List
white-list.txt
Invalid CRN (Number)
2006-03-60024
NA
NA
NA
NA
White List
white-list.txt
Invalid CRN (Bogus Text)
2006-sfs-sfsfdfsdfsfsfs
NA
NA
NA
NA
White List
white-list.txt
*additional,not used for this testing* Invalid CRN (Number) available
1995-03-76288
NA
NA
NA
NA
White List
white-list.txt
Valid CRNs
CRN with no enrollment
1995-01-76288
0
fzthorn, (Robert Thornton)
PLB, 092, 012, Internship
Winter Quarter 1995
White List
white-list.txt
CRN with enrollment
2006-06-60005
11 (all valid knames)
acham (Christine Acham)
AAS, 198, S01, Directed Gp Study
Summer Special Session 2006
White List
white-list.txt
CRN with enrollment
2006-03-93307
10 (all valid knames)
fzvasili (S Spyridakis)
HIS 111C 001 Ancient History
Spring Quarter 2006
White List
white-list.txt,black-list.txt
Test Cleanup
- Scott will remove all sites created in this step when all test cases are completed.
White List Test Results
Would yield an example Summary Test Result of:
Test |
User Role |
User Acting As |
Result |
Expected Result |
Pass/Fail |
---|---|---|---|---|---|
Site xxxxx (created): Functionality Results |
samerson |
fzolupon |
All tests pass |
batching of course succeeded |
P |
Site xxxxx (created): Course Management Test Results |
samerson |
QA Admin |
All tests pass |
course content correct |
P |
Site xxxxx (created): Provider Id Test Results |
samerson |
QA Admin |
All tests pass |
provider id correct, roster number correct |
P |
or..
Test |
User |
User Acting As |
Result |
Expected Result |
Pass/Fail |
---|---|---|---|---|---|
Site xxxxy (not created):Test Results |
samerson |
QA Admin |
All tests pass, not provisioned |
course not created, correct |
P |
Black List
Black List Testing
Description = Test the capability of the system to not add course sites that are listed in a file. Courses in this list will never be batch created.
Category of Testing = unit, integration
Prerequisite Steps
- Scott will add a list of CRNs (valid or not) to the white-list.txt file in /var/sakai/ucd-data folder on the server, in the form of TERMYR-TERMCD-CRN for each entry. This list will be different than that used for the White List Test Scenario. Use this white list
- Scott will add a list of CRNs (valid or not) to the black-list.txt file in /var/sakai/ucd-data folder on the server, in the form of TERMYR-TERMCD-CRN for each entry. Use this black list file file to use here
- Scott will que the batch job to run (White List), (5 min time elapse needed)
- Scott will advise programmers that the batch has been run
- Thomas and Scott will monitor server activity while testers are using sakai-dev.
Prerequisite Steps needed for Scenario #2 only (in addition to Scenario #1 steps)
- Scott will update existing hand created sites manually (TBD site ids) with an associated CRN as the provider id
Test Scenarios
*Scenario #1 = Black list consulted when white list batch run is executed*
- James. = will look for CRN 2004-03-60097 as user admin. This CRN will be listed in the White List files only
- Brian = will look for CRN 2006-01-60001 that is listed both in the white-list.txt and black-list.txt files
- Sandra = will look for both CRN 2006-01-40018 that are listed both in the white-list.txt and black-list.txt files
- Thomas = view logs, internal sakai db, will look for both CRN 2006-03-82882, 2006-03-83634 that are listed in the black-list.txt files only
- Scott = help as needed
- Data to Be Used:
Scenario
Course
Roster Count
Instructor Kerb Name
Course Details (Catalog Root, Suffix, Section, Description)
Test Case Used In
File Associated
Valid CRNs
CRN with no enrollment
2004-03-60097
0
dlmiller (Douglas Miller)
ECN, 298 , 026, Group Study
Spring Quarter 2004
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
*Scenario #2 = Black list consulted when existing site already has provider id that matches black list entry*
- Jon G. = will look for CRN 2006-03-69857 as user ccjon. This CRN will be listed in the Black List, but have no existing site that has the provider ids matching the CRNs
- Brian = will look for CRN 2006-03-65306,2006-06-60435 that is listed both in the provider id reference for sites ^^^^^^^^, and (((((((( and black-list.txt file
- Thomas = view logs, internal sakai db
- Scott = help Jon
- Data to Be Used:
Scenario
Course
Site id
Roster Count
Instructor Kerb Name
Course Details (Catalog Root, Suffix, Section, Description)
Test Case Used In
File Associated
Valid CRNs
CRN with enrollment
2006-03-69857
10
jrlund (Jay Lund)
ECI 299 019 Research
Spring Quarter 2006
Black List
black-list.txt
CRN with enrollment (large)
2006-03-65306
177 (all valid knames)
fzsegel (Leigh Segel)
BIS 103 002 Bioenergetics/Metabolism
Spring Quarter 2006
Black List
white-list.txt,black-list.txt
CRN with no enrollment
2006-06-60435
0
fzblanch (Marc Blanchard)
COM 152 S01 Literature Of Americas
Summer Special Session 2006
Black List
white-list.txt,black-list.txt
Test Cleanup
- Scott will remove all sites created in this step when all test cases are completed.
Black List Test Results
Would yield an example Summary Test Result of:
Test |
User |
User Acting As |
Result |
Expected Result |
Pass/Fail |
---|---|---|---|---|---|
Site xxxxy (not created):Test Results |
samerson |
QA Admin |
All tests pass, not provisioned |
course not created, correct |
P |
Update Existing Site with Provider Id
Update existing sites with appropriate provider id, enabling dynamic rosters (**When CourseManagementProvider enabled**)
Description = Test the capability of the system to update existing course sites with associated provider ids. This functionality can be done either in the UI or batch, however we want to
test the ability to run this at any time.
Category of Testing = unit, integration
Prerequisite Steps
Results Recording Steps summarized in:
**perform provider id test https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/SmartSite+Provider+Id+Update+of+Existing+Sites%2C+Integration+Test+Matrix for each site
- Scott will add a list of sites and provider ids (valid or not) to the provider-id.txt file in /var/sakai/ucd-data folder on the server, in the form of site id, TERMYR-TERMCD-CRN for each entry. Use this file use file here
- Scott will que the batch jobs to run, just the provider id que batch run, (5 min time elapse needed)
- Scott will advise programmers that the batch has been run
- Thomas and Scott will monitor server activity while testers are using sakai-dev.
*Data To Be Used:
Scenario |
Course |
SiteId or Title |
Instructor Kerb Name |
Course Details (Catalog Root, Suffix, Section, Description) |
Test Case Used In |
File Associated |
|
---|---|---|---|---|---|---|---|
InValid CRNs |
|||||||
No CRN (null CRN value) |
null |
NA |
NA |
NA |
NA |
Provider Id |
provider-id.txt |
Valid CRNs and Sites |
|||||||
CRN valid |
2006-03-93327 |
Scott's Test Course To Be Provided |
stenzel (John Stenzel) |
MST 020C A02 Late Med & Early Modern (roster=10) |
Spring Quarter 2006 |
Provider Id |
provider-id.txt |
CRN valid |
2006-03-92472 |
A Second Course To Be updated By Batch |
paully (Paul Manriquez) |
WLD 910 001 Wkload - Math Pre 16A (roster=10) |
Spring Quarter 2006 |
Provider Id |
provider-id.txt |
CRN valid |
2006-03-83569 |
Third Course Site Example |
goldberg (Jack Goldberg) |
NPB 101 001 Systemic Physiology |
Spring Quarter 2006 |
Provider Id |
provider-id.txt |
Test Scenario
- Jon G. = will look for site Scott's Test Course To Be Provided's providerid and roster, logging in as admin
- Sandra = will look for site A Second Course To Be updated By Batch's providerid and roster, logging in as ssbatchadmin
- James= will look for site Third Course Site Example's providerid and roster, logging in as admin (after Jon G. done)
- Brian = will validate provider ids and rosters
- Thomas = view logs, internal sakai db
- Scott = help Sandra, Jon, and log in as himself for manual updates
Manual Process Check (update provider ids for sites manually):
- After site Scott's Test Course To Be Provided,A Second Course To Be updated By Batch, and Third Course Site Example's provider ids are validated,
Scott will update site Second Course Site Example with:
providerId = 2006-03-76517
and.. site Third Course Site Example with:
providerId = 2006-03-75796 - Thomas will check site Second Course Site Example and site Third Course Site Example's provider id and rosters
Test Cleanup
- Scott will remove all sites created in this step when all test cases are completed.
Provider Id Update Test Results
Would yield an example Summary Test Result of (both batch and manual updates):
Test |
User |
User Acting As |
Result |
Expected Result |
Pass/Fail |
---|---|---|---|---|---|
Site xxxxx: Provider Id Update Results |
samerson |
admin |
provider id is ....., roster is same as CRN for provider id |
provider id updated and seen in site tool under "provider id", roster reflects provider id roster |
P |
Site Functionality
Site functionality
Description = Test the capability of the system to add sites with the correct pages, tools, tabs, and look and feel.
Category of Testing = unit, integration, functionality
Prerequisite Steps
Results Recording Steps summarized in:
**perform functionality test https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/Course+Site+Functionality+Tests%2C+SmartSite+Batch+Integration+Testing+Matrix for each site
looking for expected results
Test Scenario
- -Look and Feel- *
- Pages *
- Tools on each page *
- Click-through on tools *
- Order *
- Tabs *
Test Cleanup
- Scott will remove all sites created in this step when all test cases are completed.
Course Management Data Presented in Admin Tools
Course Management data present
Description = Test the course management content displayed in admin tools.
Category of Testing = unit, integration, functionality
Prerequisite Steps
Results Recording Steps summarized in:
**perform course management test https://confluence.ucdavis.edu:8443/confluence/display/UCDSAKAI/SmartSite+Course+Site%2C+Course+Management+Integration+Test+Matrix for each site
looking for expected results
- Site navigation *
- WorkSite Setup navigation *
- Site Info tool *
Test Cleanup
- Scott will remove all sites created in this step when all test cases are completed.
Full Batch Run on Term
Full Batch Run
Description = Test the batch method for a whole term
Category of Testing = unit, integration, performance
Prerequisite Steps
- After all tests have been run, Scott will recompile the Batch code to run for 2004 Winter
- Scott will add the black list file that contains one CRN from Winter 2004 into the /var/sakai/ucd-data directory.
- This test will run in the evening of test day
- Scott and Thomas will analyze the Sakai internal db to check for errors in creation
- Data to Use:
Scenario
Course
Roster Count
Instructor Kerb Name
Course Details (Catalog Root, Suffix, Section, Description)
Test Case Used In
File Associated
Valid Term
Term with large number CRNs
2004-01
NA
NA
32573 sites
Winter Quarter 2004
Full Batch Run
NA
Valid CRN
2004-01-40200,2004-01-42003
NA
NA
NA
NA
White List
black-list.txt
Test Cleanup
- Scott will ask Geeta to drop the devel schema when this test is completed.
Recording Results
The test results will be recorded in the above summary tables by integration testers, and a summary of this data will be ready for QA and the Sakai Development team to review.
Feedback Mechanism
The above results will be analyzed by the SmartSite programming team, and management to determine the steps needed and whether or not to hand off to QA. Results of this test should be discussed as near to the Monday meetings as possible.