Lab 3 – Prototype Test Plan/Procedure for READ
CS 411W Lab III
Version 1
Prototype Test Plan/Procedure
For
READ
Prepared by: Marcus Zehr – Black Team
Date: 04/17/2013
1
Lab 3 – Prototype Test Plan/Procedure for READ
2
Table of Contents
1. Objectives …......……………………...…………...………………………..…………...……3
2. References …... ...………………………………….………………………..……………...…5
3. Test Plan ………………………………………………………………………………………5
3.1 Testing Approach ………………………………………………..…...…….....………6
3.2 Identification of Tests ……………………………………………………………...…8
3.3 Test Schedule ...………………………………………..…………..………..……….11
3.4 Fault Reporting and Data Recording ………………………………...…….....…….12
3.5 Resource Requirements ……………………………………..………..……………..13
3.6 Test Environment ...………………………………………………..……...…………13
List of Figures
Figure 1. READ’s MFCD ...…………………..………………………..…………..……………..6
List of Tables
Table 1. READ Test Cases ……….………..……..………………………………………...……..8
Table 2. Prototype Demonstration Schedule ………..….………………………………...……..11
Table 3. Fault Reporting Information ……….……………………………………….…...……..12
Lab 3 – Prototype Test Plan/Procedure for READ
3
1. Objectives
There are more than 4,700 research institutions in the United States (Digest of Education
Statistics).These institutions can display and their research through abundant publications and
upload them to the Internet. However, many of the organizations associated with these
institutions lack an efficient method or procedure for uploading and maintaining documents such
as these publications. This is a problem for research institutions and is important to fix so that
institutions may be appropriately recognized for work which is completed. In doing this, research
institutions may further advertise specific areas of research being performed at any given time.
The current process for many organizations to present their publications online is nonautomated, slow, and tedious which means there are many areas to improve upon to properly
display and advertise an institutions’ publications. One main reason for this is that the
responsibility to update the system may rest upon a sole individual or administrator. This is the
issue that will be addressed through the development of the READ web application for research
institutions.
The Repository for Electronic Aggregation of Documents, READ, aims to automate the
currently manual process of submitting an organizations’ publications and grant information. It
will also keep this information better organized and allow publications and grants to be
searchable using filters while being displayed in an easy to read format. In addition to this,
READ will provide the ability for users to verify that their grant and publication information is
correct. Ultimately READ will ease the burden of keeping up with numerous publications to
allow researchers to spend more time working and less time managing files.
READ is an online database which has an abundance of capabilities including the ability to
store information about, publications, and links to outside grants publications; providing a way
Lab 3 – Prototype Test Plan/Procedure for READ
4
for users to browse and search through publications using a number of filters such as author,
publish date, keywords, and type of document; It allows a user to advertise their research, both
past and current, as well as information about any grants which apply to them. It minimizes the
need for a user to manually organize their publications by utilizing the Schaefer Scraper to
automatically find publications on the Internet. READ however will not provide access to
copyrighted material or gather research material for anyone outside of Old Dominion University.
The Schaefer Scraper will be used by READ to search for publications matching a registered
users credentials and extract pertinent information found in the publications such as the title,
author or authors, publication date, and type of publication. This information is then inserted into
the database along with a link to that specific publication and a notification email is sent to that
user to authorize the newly uploaded publication information. Based on the actions of the user
and patterns of denied publications, READ will learn when not to notify a user to authorize
certain publications when they are found.
With READ in place, any user will be able to browse the database using an assortment of
filters for publications. Publications may be searched by publish date, author or keywords, and
whether or not the full text is available. Grants may be searched by total amount, grant status,
funding agency, or investigators.
Each user will have a profile which will display information including the user’s name, job
title, personal photo, email address, affiliated organization, and homepage. The users’ profile
page will also include graphical representations of the number of publications they have authored
and time which they were published as well as any funding received through the participating
publications. In addition to the graphical representations, the profile page for each user will
include a list of that specific user’s publications.
Lab 3 – Prototype Test Plan/Procedure for READ
5
The initial consumer for READ is Old Dominion University’s Computer Science Department
(ODUCS). Dr. Michele Weigle, a professor at ODU with her Ph.D. in Computer Science, had
requested a solution for this particular issue and is acting as group mentor for this project. The
ODUCS Department features 37 faculty members, 11 currently enrolled Ph. D students, and 11
Master’s students according to its website. These are all individuals who would be able to take
advantage of a system which could make it easier to discover relevant and up to date research,
but they do not begin to cover the number of people who would find READ to be an
indispensable resource in the future.
Once testing is complete at ODUCS then READ may be utilized by other departments within
Old Dominion University. Potentially READ could then be used at other universities to help with
their organizational and research needs as well as government institutions, research institutions,
and libraries.
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>.
Zehr, Marcus. Lab 1 – READ Product Description, CS411, Black Team, Spring 2013
Zehr, Marcus. Lab 2 – READ Product Description, CS411, Black Team, Spring 2013
3. Test Plan
READ will be tested in multiple categories which include: User interface, back-end user
interface, database, and data scraper. Each of these categories will have a set of test cases which
need to be fulfilled in order to prove the functionality of READ to the user.
Lab 3 – Prototype Test Plan/Procedure for READ
6
3.1 Testing Approach
The READ prototype will incorporate the use of simple hardware and software solutions
which have been integrated together seamlessly in order to perform its duties with ease in the
hands of the users. Figure 1 illustrates the major functional components of the READ prototype.
This solution consists of a single server which will house three main software components: a
web interface, a publication link database, and Schaefer’s Scraper.
Figure 1 - READ's MFCD
The web interface itself will have both public and private areas available for access to users.
The private areas will require a user to log on to their account in order to access and will allow
for the user to perform various tasks. The user will then be allowed access to their own profile
page and administrative abilities. Inside the web interface the user may access the search filters
for publications and grants as well as other users’ public profiles.
The publication link database’s main function is to house and provide links to any external
publications and grant information to the users. This database will also contain files which have
Lab 3 – Prototype Test Plan/Procedure for READ
7
been uploaded by the users including publications, grants, and other files which may be related
to either.
The last internal component is the Schaefer Scraper which is an automated tool that will
search specific external web sites for new publications submitted via a list of authors provided as
input within a XML file. The scraper will do this by looking for publications by the included
authors, collect and parse the results, and then export them into the READ link database for
further use.
The prototype which will be implemented will be modeled using the Old Dominion
University's Computer Science Department’s publications and hosted on a virtual machine
running a Linux based operating system. It will also include all of the features of the real world
project and be instrumental to maintain and upkeep publications and grants for the university.
The READ Prototype will have the ability to search through the database and filter the results
based on user queries, implement RSS Feeds, allow for users to log on, edit, and upload data, and
give functional control of the web application to administrators. By utilizing the Schafer Scraper,
it will also find publications and insert them into the READ database. The users of this system
will be able to log on and access their own publication and grant information and have the ability
to edit this information. They will also be able to upload personal information and upload files to
the READ database. These functions of the prototype will allow for easy access to numerous
publications, grants, and tech reports written by Old Dominion University faculty and students.
This will all be located in a well-organized and easy to navigate user interface which will utilize
a filter and search page, displays for publications and grants, a profile display system, and a RSS
feed.
Lab 3 – Prototype Test Plan/Procedure for READ
8
3.2 Identification of Tests
Table 1 will display all of the test cases which will test READ.
Module
ID
1
2
Module
User
Interface
Back-end
User
Interface
Sub-Module
Sub-Module
Requirement
ID
Requirement
ID
Objective
Publication
Query Page
1.1
1.1
Browse through all publications
on the system
Grant Query
Page
1.2
1.2
Main Page
1.3
1.3
Login Page
1.4
1.4
Profile Page
1.5
1.5
List information on the specific
user which is logged in
Publication
Add Page
1.6
1.6
Allow the user to submit
publications manually into the
system
Grant Add
Page
1.7
1.7
Allow the user to submit grants
manually into the system
Profile Edit
Page
1.8
1.8
Publication Edit
Page
1.9
1.9
Grant Edit Page
1.1
1.1
Administration
Page
1.11
1.11
Houses all abilities which are
restricted solely to system
administrators
Publications
Page
2.1
3.1.1
Default publication display
Grants Page
2.2
3.1.2
3.2.1
3.2.2
Filtered publication display
Default grants display
Filtered grants display
Login
2.3
3.3.1
Verify username validity and
authenticity
Browse through all grants on
the system
Home page of READ. Displays
most recent documents and
allows for navigation to other
parts of the UI
Allow registered users to log
into READ for authentication
purposes
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
Lab 3 – Prototype Test Plan/Procedure for READ
Module
ID
2
3
4
Module
Back-end
User
Interface
Database
Data
Scraper
Sub-Module
Sub-Module
Requirement
ID
Requirement
ID
Editing
2.4
3.4.1
3.4.2
Profile Page
2.5
3.5.1
Profile Editing
2.6
3.6.1
9
Objective
Verify publication editing
Verify grants editing
Verify that profile page is
displaying properly
Verify profile editing
Database
Access
3.1
Verify that the basic database
account can log into the
database server
Add Author
3.2
Verify that the basic database
account can add authors to the
Auths table
Add Paper
4.3
Verify that the basic database
account can add publications
to the Paper table.
Owns table
test
4.4
Verify that the basic database
account can link publications to
authors
Add Grants
4.5
Verify that the basic database
account can add grants to the
Grants table.
Add Tags to
Grants
4.6
Verify that the basic database
account can link tags to Grants
Add Tags to
Publication
4.7
Add CO_PI
4.8
Add AuthString
4.9
Microsoft
Academic
Scraper
5.1
BibTex Parser
5.2
3.4.7
Verify that the basic database
account can link tags to
publications
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
5.2.1
5.2.2
5.2.3
Trigger Parser
Empty Results
Process All Items
Lab 3 – Prototype Test Plan/Procedure for READ
Module
ID
4
Module
Data
Scraper
Sub-Module
Sub-Module
Requirement
ID
BibTex Parser
5.2
Database
Updater
5.3
Email
Notification
5.4
Requirement
ID
5.2.4
5.2.5
5.2.6
5.3.1
5.3.2
5.3.3
5.3.4
10
Objective
Empty Attributes
Parse Specific Attributes
Correct Format
Update
No Overwrite
Required Data
One Author At A Time
Table 1 – READ Test Cases
------------------------------------- This space intentionally left blank -------------------------------------
Lab 3 – Prototype Test Plan/Procedure for READ
11
3.3 Test Schedule
The following table will display the demonstration schedule for testing the READ prototype
within the testing environment.
Prototype Demonstration Schedule
Timestamp
0:00
0:05
0:10
0:15
Demo. Section
Requirements
Met
Required Preparation
Introduction to READ:
Faculty Member Search
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
* 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.
Administrative
Functionality:
Add a Faculty User
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
* Create a fake Gmail
account for fake faculty user.
Parser Demonstration:
For New User
3.1.4
3.1.5.2.1,5-17
3.1.5.3.2,4,9,10
Faculty User:
Edit and Approve New
Update
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
* Prepare a BibTex file
containing at least 5
publication entries for the
fake new faculty member.
(none)
Lab 3 – Prototype Test Plan/Procedure for READ
12
Prototype Demonstration Schedule
Timestamp
0:20
Demo. Section
Requirements
Met
Required Preparation
MAR Scraper
Demonstration using
Real-World Data
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
* 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 – Prototype Demonstration Schedule
3.4 Fault Reporting and Data Recording
The following table demonstrates how error reporting and data recording will occur.
Component
Recording Process

Hardware


User Interface


Back-end User Interface


Database


Data Scraper

Table 3 - Fault Reporting Information
Report failures through a visual inspection of the computer
tower
Document through hardcopy forms
Report failures through a visual inspection of the READ
website and navigation screens
Document through hardcopy forms
Report failures through a visual inspection of output printed
on the monitor
Document through hardcopy forms
Report failures through a visual inspection of the returned
SQL statements
Document through hardcopy forms
Report failures through a visual inspection of the data returned
from the scraper
Document through hardcopy forms
Lab 3 – Prototype Test Plan/Procedure for READ
13
3.5 Resource Requirements
The resources required for this prototype to function are very minimal. These required
resources include a computer with an active connection to the Internet, a compatible web
browser, READ’s source code, and a server.
3.6 Test Environment
The test environment for the prototype will be proportionate to the final product in size and
scope once it is completed. Testing of this prototype will occur within a lab environment located
inside one of ODU’s computer science department buildings.