Test Plan and Cases (TPC) Version 1.0 Version no x.xx

Test Plan and Cases (TPC)

Soccer Data Web crawler

Team No.02

First Name / Last Name / Role
Trupti / Sardesai / Project Manager
Wenchen / Tu / Prototyper
Subessware / Selvameena Karunamoorthy / System/Software Architect
Pranshu / Kumar / Requirements Engineer
Zhitao / Zhou / Feasibility Analyst
Yan / Zhang / Operational Concept Engineer
Qing / Hu / Life Cycle Planner
Amir ali / Tahmasebi / Shaper

10/19/2014

Version History

Date / Author / Version / Changes made / Rationale /
10/19/14 / AT / 1.0 / ·  Added introduction and a draft of our test cases. / ·  Initial draft for Soccer data Webcrawler
11/29/14 / AT / 2.0 / ·  Added Schedule and resources section / ·  To complete Test Plan and cases

Table of Contents

Test Plan and Cases (TPC) i

Version History ii

Table of Contents iii

Table of Tables iv

1. Introduction 5

1.1 Hardware preparation 6

1.2 Software preparation 6

1.3 Other pre-test preparations 6

1.4 Requirements Traceability 6

2. Test Identification 7

2.1 Test Identifier 7

Table 2: TC-01-01 Gather Team Info 7

2.2 Test Identifier 8

2.3 Test Identifier 9

3. Resources and schedule 10

3.1 Resources 10

3.2 Staffing and Training Needs 10

3.3 Schedule 11

iii

TPC_T02_F14a_V2.0.doc Version Date: 11/29/14

Test Plan and Cases (TPC) Table of Contents

Table of Tables

Table 1: Requirements Traceability Matrix 6

Table 2: TC-01-01 Gather Team Info 7

Table 3: TC-02-01 Gather Team Info 8

Table 4: TC-03-01 Gather Team Info 9

Table 5: Testing Schedule 11

iii

TPC_T02_F14a_V2.0.doc Version Date: 11/29/14

Test Plan and Cases (TPC) Version 2.0

1.  Introduction

For this project, we plan to incorporate both unit testing and integration testing to verify and validate the capabilities of our system. As for the unit tests, we will generate a set of unit tests that will test the fined grained components of the system, meaning these tests will be used to test the classes and methods of the classes that are used in our project. By developing a comprehensive unit test suit and running them often, we can make sure new changes are not breaking any of the functionalities that were added in the previous iterations.

In addition to unit tests, we will also have integration tests that are going to run less frequently than the unit tests. These integration tests are to test the more general functionalities of the system and they would require some human interaction. For our project, we are planning to have our IV&V person run these tests and make sure the outcome of these tests match the expected results.

We are hoping with these two methods of testing we can achieve a high level confidence in our system. Also these tests will be provided to our client so they could be used by the developers that are going to maintain the system after the development phase of the project is over.


1.1  Hardware preparation

As for hardware systems required for testing plan, we will not need anything besides the systems that are used for development.

1.2  Software preparation

We will be looking into using a python library called Unit test for our unit testing. Unit test is testing framework for python that is very similar to JUnit, and the usage should be very straight forward.

1.3  Other pre-test preparations

N/A

1.4  Requirements Traceability
Requirement ID / Verification Type / Test Case ID (if applicable)
CR-1 The web crawler shall gather team information from the websites in the website list. / Testing / TC-01 Gather team information
CR-2 The web crawler shall gather player information from the websites in the website list. / Testing / TC-02 Gather player information
CR-3 The web crawler shall get number of followers, the comments and the number of retweets for a specified twitter account. / Inspection
CR-4 The web crawler shall get comments, name and number of members, likes from specified Facebook pages. / Inspection
CR-5 As a developer, I can update/revise the player data as the season progresses / Testing / TC-03 Update player information
CR-6 As a developer, I can add/delete/update the specific websites visited, fields to capture from the website and frequency of crawler refreshes for each specified website. / Demonstration

Table 1: Requirements Traceability Matrix

2.  Test Identification

2.1  Test Identifier

TC-01 Gather team info

2.1.1  Test Level

Software item level

2.1.2  Test Class

Capability Test

2.1.3  Test Completion Criteria

Team Information should be gathered from a webpage correctly and match the expected information that we have gathered by hand.

2.1.4  Test Cases
Table 2: TC-01-01 Gather Team Info
Test Case Number / TC-01-01
Test Item / This test case tests the basic functionality of the system to gather information related to a team and enters it into the database.
Test Priority / Must Have
Pre-conditions / We need to have pre-determined web page that we have gathered data from by hand
Post-conditions / The gathered data should be inserted into the DB with correct format and values.
Input Specifications / The URL of the pre-determined webpage.
Expected Output Specifications / Data that is be inserted into the DB
Pass/Fail Criteria / Data should match the per-defined data that is scraped from the webpage manually.
Assumptions and Constraints / The data that is on the pre-determined webpage is static and does not change.
Dependencies / NA
Traceability / CR-1 The web crawler shall gather team information from the websites in the website list.
2.2  Test Identifier

TC-02 Gather player info

2.2.1  Test Level

Software item level

2.2.2  Test Class

Capability Test

2.2.3  Test Completion Criteria

Player Information should be gathered from a webpage correctly and match the expected information that we have gathered by hand.

2.2.4  Test Cases
Test Case Number / TC-02-01
Test Item / This test case tests the basic functionality of the system to gather information related to a player and enters it into the database.
Test Priority / Must Have
Pre-conditions / We need to have pre-determined web page that we have gathered data from by hand
Post-conditions / The gathered data should be inserted into the DB with correct format and values.
Input Specifications / The URL of the pre-determined webpage.
Expected Output Specifications / Data that is be inserted into the DB
Pass/Fail Criteria / Data should match the per-defined data that is scraped from the webpage manually.
Assumptions and Constraints / The data that is on the pre-determined webpage is static and does not change.
Dependencies / NA
Traceability / CR-2 The web crawler shall gather player information from the websites in the website list.

Table 3: TC-02-01 Gather Player Info

2.3  Test Identifier

TC-03 Update player information

2.3.1  Test Level

Software item level

2.3.2  Test Class

Capability Test

2.3.3  Test Completion Criteria

When player information is updated, the data in the DB should match the updated data.

2.3.4  Test Cases
Test Case Number / TC-03-01
Test Item / The purpose of this test case is to test the capability of the system to update players info after the data has been inserted into the DB.
Test Priority / Must Have
Pre-conditions / We need some player information in the system
Post-conditions / The data in the DB should match the data the updated information.
Input Specifications / Updated information and the name of the player whose info should be updated.
Expected Output Specifications / Data that is retrieved form the DB either in JSON format or XML
Pass/Fail Criteria / The retrieved data from the database should match the updated information.
Assumptions and Constraints / There is some player information in the system.
Dependencies / NA
Traceability / CR-5 As a developer, I can update/revise the player data as the season progresses

Table 4: TC-03-01 Update Player Info

3.  Resources and schedule

For this project, the developers who were responsible for the components of the system did the initial testing. While the initial testing was done, our shaper/IV & V person started testing the system components. During this stage, our IV & V person communicated problem that were found to the developers so they can be fixed. After testing each component individually, the shaper started testing the system as a whole to make sure all components of our system were integrated with each other. We allocated about 2 weeks for testing our project; we dedicated 1 week for testing our system components individually and 1 week for testing the system as whole.

3.1  Resources

As for the resources required for testing, for determining the sanity of the data that was gathered by our system, we needed some team and player information that was collected by hand that could be used to verify the data our system gathered. We had a list of about 20 players that was provided by our client that we used for the testing purposes. We also selected some teams that we used for testing.

3.2  Staffing and Training Needs

Our testing process involved the development team, the IV & V person, and the client. The development team was in charge of training our IV & V person on how the system should be used. For the training purpose, developers delivered a brief informal user manual for their respected component to the IV & V person. Our IV & V person used these user manuals for initial testing of the system components; however, we did not limit our testing to what was in these user manuals, meaning the IV &V person tried to test cases that were not mentioned in these user manuals. Our IV & V person was the main person who was in charge of executing the test cases and verifying the results. The client was in charge of providing us with some players and teams that we could use for testing our system.

3.3  Schedule
Date / Test Identifier / Responsible person / Resources / Training needs
11/22/14 / TC-01-01 to TC-02-1 / Amir Tahmasebi / Player and team data gathered by hand. / Training on how the system should be used
11/22/14 / TC-03-01 / Amir Tahmasebi / Player data ingested into the DB / NA


Table 5: Testing Schedule

iii

TPC_T02_F14a_V2.0.doc Version Date: 11/29/14