Lab 3 –Prototype Test Plan/Procedure 1
Running Head: LAB 3 – Prototype Test Plan/Procedure
CS 411W Lab III
Prototype Test Plan/Procedure
For
READ
Prepared by: Jacob Phillmon, Black Group
Date: 4/17/2013
Lab 3 –Prototype Test Plan/Procedure 2
Running Head: LAB 3 – Prototype Test Plan/Procedure
1
Objectives ............................................................................................................................... 3
2
References ............................................................................................................................... 5
3
Test Plan.................................................................................................................................. 5
3.1
Testing Approach ............................................................................................................. 6
3.2
Identification of tests ........................................................................................................ 7
3.3
Test Schedule ................................................................................................................... 8
3.4
Fault Reporting and Data Recording................................................................................ 9
3.5
Resource Requirements .................................................................................................. 10
3.6
Test Environment ........................................................................................................... 10
Lab 3 –Prototype Test Plan/Procedure 3
Running Head: LAB 3 – Prototype Test Plan/Procedure
1 Objectives
READ, a repository for electronic aggregation of documents is a system designed
specifically for Old Dominion University’s Computer Science Department. The department is
composed of a group of faculty members, most of which produce numerous publications
detailing their research every year. In an attempt to organize the faculty’s publications into a
single viewable location, the department had a system in place where publications were manually
submitted by the faculty and later added to the system manually by the system’s administrator.
The process cost such a large amount of time just to update the system that most of the faculty
stopped submitting publications all together. This can be seen in the systems display itself, as the
last submitted publication dates back to the year 2008 (Recent Publications). The page also lacks
any filter capabilities; all publications are displayed with those most recently published at the top
and older ones going to the. The display page is no longer linked to the department’s homepage
because it is out of date and no longer in use. The READ system is designed to encourage use of
the new system through by automating the process of updating the system as well as adding
additional browsing capabilities. Eventually the system may be expanded to be included in other
departments at Old Dominion University as well as other organizations that require a system to
organize their publications and grants.
The READ prototype is intended to demonstrate the effectiveness of implementing a self
updating publication. The first objective is to ensure that the READ database is setup in a way
that the Schaefer Scraper can efficiently scrape and store grant and publication information into
Lab 3 –Prototype Test Plan/Procedure 4
Running Head: LAB 3 – Prototype Test Plan/Procedure
it. The database will be checked for completeness by comparing multiple BibTex files to the data
that is actually stored in the database.
The second functional objective is to demonstrate the proper use of the READ user
interface. The interface will be tested thoroughly to ensure that access to editing and adding
publications and grants to the system will be limited to registered authors and system
administrators. The overall layout of the interface will be checked to make sure that publication,
grant, and profile information are displayed correctly. Interface functionality, such as publication
and grant filtering and profile editing, will be tested manually over the system interface. Due to
the fact that the READ interface is mainly only visual in its functionality, most testing will have
to be done manually.
The final objective is to demonstrate the effectiveness of the Schaefer Scraper’s ability to
automatically update the system with publications recently created by ODU CS faculty members.
The scraper will be tested to ensure that it is periodically adding new publications to the system
as well as adding them under the correct authors. Publication data that is added to the system will
have to be manually checked to ensure it is being added to the database correctly. Since the
scraper will run periodically at set intervals of time, it will find publications that may already
exist in the READ system. Automated testing will be conducted to ensure that duplicate
publication entries are not being added to the system.
The main purpose of testing and demonstrating the READ prototype is to ensure that all
bugs and errors are accounted for in the current system. Those that are able to be fixed will be
corrected in a timely manner, while those that cannot will be left to future CS 411 groups to
handle. Overall it will lead to a quality product for the ODU CS faculty
Lab 3 –Prototype Test Plan/Procedure 5
Running Head: LAB 3 – Prototype Test Plan/Procedure
2 References
Digest of Education Statistics. 2011. National Center For Educational Statistics
Web. 19 Nov 2012.
<http://nces.ed.gov/programs/digest/d11/tables/dt11_001.asp?referrer=
report>.
Phillmon, Jacob. (2013). Lab I – Read Product Description. Chesapeake, VA: Author.
Phillmon, Jacob. (2013) Lab 2 – Prototype Specification for READ. Chesapeake, VA: Author
"Recent Publications." Department Of Computer Science. N.p., n.d. Web. 13 Feb. 2013.
<http://www.cs.odu.edu/recent_publications.shtml>.
3 Test Plan
The following sections will describe the types of tests that will be performed, the timing
schedule required to conduct them, and the methods and procedures used for each of them.
Intentionally left blank
Lab 3 –Prototype Test Plan/Procedure 6
Running Head: LAB 3 – Prototype Test Plan/Procedure
3.1 Testing Approach
Figure 1 – Prototype Major Functional Component Diagram
The system will have each component tested individually if possible, but will test for
components concurrently if required, such as submitting fields on the READ UI to be inserted
into the READ database. Tests done on the read database will be done at a component level to
ensure that it is setup properly. Most of the UI tests will be done manually by one of the READ
developers in order to make sure that it is visually appealing as well as functioning properly.
Since the UI requires the database to be functional in order for it to be functioning properly, all
tests done on it will be at a system level. The Schaefer Scraper will be divided into two phases of
testing: scraper testing and parser testing. Scraper testing will deal with searching for
publications created by registered ODU CS faculty members, while parser testing will deal with
inserting publication information into the database. The scraper and parser will require the read
database to be fully developed in order to function properly, so all testing will be done on a
Lab 3 –Prototype Test Plan/Procedure 7
Running Head: LAB 3 – Prototype Test Plan/Procedure
system level. Publications and grants used in the READ system will not be simulated; they will
be actual documents created by the ODU CS faculty.
3.2 Identification of tests
Module
ID
Module
Sub-Module
Publication
Query Page
Grant Query
Page
1
2
3
User
Interface
Back-end
User
Interface
Database
Sub-Module
Requirement
Requirement ID
ID
1.1
1.1
1.2
1.2
Main Page
1.3
1.3
Login Page
1.4
1.4
Profile Page
1.5
1.5
Publication Add
Page
1.6
1.6
Grant Add Page
1.7
1.7
Profile Edit Page
1.8
1.8
Publication Edit
Page
1.9
1.9
Grant Edit Page
1.10.
1.1
Administration
Page
1.11
1.11
Publications Page
2.1
Grants Page
2.2
Login
2.3
3.3.1
Editing
2.4
3.4.1
3.4.2
Profile Page
2.5
3.5.1
Profile Editing
2.6
3.6.1
Database Access
3.1
3.4.9
Add Author
3.2
3.4.3
3.1.1
3.1.2
3.2.1
3.2.2
Objective
Browse through all publications
on the system
Browse through all grants on the
system
Home page of READ. Displays
most recent documents and
llows for navigation to other
parts of the UI
Allow registered users to log
into READ for authentication
purposes
List information on the specific
user which is logged in
Allow the user to submit
publications manually into the
system
Allow the user to submit grants
manually into the system
Allow the user to submit
changes to their profile page
Allow the user to alter their own
publication information in
READ
Allow the user to alter their own
grant information in READ
Houses all abilities which are
restricted solely to system
administrators
Default publication display
Filtered publication display
Default grants display
Filtered grants display
Verify username validity and
authenticity
Verify publication editing
Verify grants editing
Verify that profile page is
displaying properly
Verify profile editing
Verify that the basic database
account can log into the
database server
Verify that the basic database
Lab 3 –Prototype Test Plan/Procedure 8
Running Head: LAB 3 – Prototype Test Plan/Procedure
4
Add Paper
4.3
3.4.4
Owns table test
4.4
3.4.7
Add Grants
4.5
3.4.5
Add CO_PI
4.8
3.4.8
Add AuthString
4.9
3.4.9
Microsoft
Academic
Scraper
5.1
Bibtext Parser
5.2
Database Updater
5.3
Email
Notification
5.4
Data
Scraper
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.3.1
5.3.2
5.3.3
5.3.4
account can add authors to the
Auths table
Verify that the basic database
account can add publications to
the Paper table.
Verify that the basic database
account can link publications to
authors
Verify that the basic database
account can add grants to the
Grants table.
Verify that the basic database
account can link grants to
authors who are COPIs on
grants
Verify that the Authstrings table
can be filled out by the basic
database account
Trigger Parser
Empty Results
Process All Items
Empty Attributes
Parse Specific Attributes
Correct Format
Update
No Overwrite
Required Data
One Author At A Time
Table 1: Test Identification Table
Table 1 depicts all the tests that will be conducted on the READ system, each of which is
grouped by category. Detailed information on each test can be found in section 4.1.
3.3 Test Schedule
The READ team will be given 45 minutes to demonstrate the read prototype. Table 4.2
represents the planned time schedule for demonstrating the READ prototype. Each member of
the READ team will take part in presenting the areas they had a major role in developing.
Lab 3 –Prototype Test Plan/Procedure 9
Running Head: LAB 3 – Prototype Test Plan/Procedure
Timestamp
Demo. Section
0:00
Introduction to READ –
Faculty Member Search
0:05
Administrative Functionality –
Add a Faculty User
0:10
Parser Demonstration -- For
New User
0:15
Faculty User – Edit and
Approve New Update
0:20
MAR Scraper Demonstration
using Real-World Data
Requirements Met
3.1.1.1.1-3
3.1.1.2
3.1.1.3.1-3
3.1.2.1.1
3.1.3
3.1.4
3.1.1.4.1
3.1.1.5.1-3
3.1.1.7.1
3.1.2.3.1
3.1.3
3.1.4
3.1.4
3.1.5.2.1,5-17
3.1.5.3.2,4,9,10
3.1.1.8.1-3
3.1.2.2.1
3.1.3.5.1
3.1.3.6.1
3.1.3
3.1.4
3.1.5.4.1-8
3.1.1.3.1-3
3.1.1.4.1,2
3.1.1.5.1-3
3.1.1.8.1-3
3.1.3
3.1.4
3.1.5.1.,4
3.1.5.2.1-17
3.1.5.3.1-10
3.1.5.4.1-8
Required Preparation
- Run the scraper successfully for at least 5
current faculty members, including M.
Weigle.
- Ensure that the updates are included on the
front page of READ.
- Create a fake Gmail account for fake faculty
user.
- Prepare a BibTex file containg at least 5
publication entries for the fake new faculty
member.
(none)
- Remove all publication data for one pub
owned by M. Weigle.
- Prepare M. Weigle’s profile page with
picture, etc ‘nice-looking’ data.
Table 2: READ Prototype Demonstration Schedule
3.4 Fault Reporting and Data Recording
Each person in the group will be required to record the results on the tests they developed.
Visual and functional tests on the READ UI will be observed and recorded by a single READ
team member and documented as either pass or fail. Database contents will be verified whenever
a component of the READ system makes a modification to it. Functionality of the Schaefer
Lab 3 –Prototype Test Plan/Procedure 10
Running Head: LAB 3 – Prototype Test Plan/Procedure
Scraper will either be marked as partially or fully functional. Any faults or failures of system
tests will be noted in the list.
3.5 Resource Requirements
The READ prototype will require that the READ UI, database, and scraper scripts all be
run on an ODU server. Not all but some of the ODU CS faculty members must be added to the
READ system user portion of the database. A large number of publications must also be inserted
into the database, along with a few grants. A PC with connection to the internet will be used to
demonstrate the functionality of the READ system components. The PC must have putty
installed on the system in order to connect the READ virtual machine to display the exact
structure of the database.
3.6 Test Environment
The demonstration of the READ system will take place in a classroom located on ODU’s
campus. It will take place in front of ODU CS faculty, fellow group members, and the groups
mentor. The READ team will use a computer provided by ODU’s CS department to display the
READ UI using a projector. Proper network connectivity will be tested before starting the
presentation. Each team member will take turns explaining how the system fulfills the current
requirements, as well as any errors that may still exist.