SmartCal

Test Plan

COP4331, Fall 2014

Modification history:

Version	Date	Who	Comment
v0.0	09/14/2014	Carlos Pereda	Template
v0.1	09/14/14	Carlos Pereda	Added team contact info Introduction. Description of Test. Overall Stopping criteria. Description of Individual Test Cases.

Team Name: Group 9

Team Members:

• Salim Andraos andraos@knights.ucf.edu
• Joseph Burfield jburfield@knights.ucf.edu
• Sachin Nayee Sach@knights.ucf.edu
• Paul Perdue perdue1@knights.ucf.edu
• Carlos Pereda carloshpereda@knights.ucf.edu
• James Choi jchoi2012@knights.ucf.edu

---

Contents of this Document

1. Introduction:

Overall Objective for Software Test Activity

Reference Documents

2. Description of Test Environment

3. Overall Stopping Criteria

4. Description of Individual Test Cases

---

SECTION 1: Introduction

• The object of the test activity aims in the delivery a bug-free product. to achieve this goal. This goal will be achieved by identifying potential risks –conflicting requirments, ability to deliver, and selection of tools among others,- and looking at opportunities for improvement from the early phases of the project such as design. Also, during the coding phase; alpha and beta testers will be selected from non-team participants in order to find possible failures caused due to user errors, or coding errors.
• The value of the product will be based on how useful, and how user-friendly the application will be. The test proccess will allow the team to produce an application that will be easy to use, practical, and a must for any individual requiring an intelligent planner.

Reference Documents:

• Project Plan <include link here>
• SRS http://www.cs.ucf.edu/courses/cop4331/fall2014/cop4331-9/SRS.html#ReferenceDocuments
• Software Engineering: Theory and Practice. Pfleeger, Atlee. Fourth edition, Pearson.

---

SECTION 2: Description of Test Environment

SmartCal is an application originally designed to run on a Windows platform. Keeping opened the possibilities to expand to mobile platforms (Android and IOS). Due to its versatility, easy learning curve, attractive CGI, and excellent DBMS (SQL Server) the selected software platform is C#.Net. Alpha tester will be limited to team members, but beta tester will consist of both team and non-team members.

---

SECTION 3: Stopping Criteria

The criteria for ‘Stop and back’ on the severity of the faults found along the way.

• Undoubtedly conflicting requirements will require a re-evaluation of such requirements, and a re-design of them.
• Coding bugs depending on their severity; may be put in a log that will be revised daily for evaluation and fixing.
• “What if I do this…” will be put on a wish-list log, and will be evaluate by all team members on a weekly base.
• In order to consider the product good for delivery, it must be used not less to the full extent of its capabilities; for a period not less than 20 men/hours without incidents. Cosmetic error will be considered as errors, therefore stopping delivery of final product.

---

SECTION 4: Description of Individual Test Cases

Ø Requirements verification.

§ Test Objective: After completion of this test; the team will be able to determine the following:

· Requirements are clearly defined.

· There are enough requirements to enumerate and describe the goals to achieve.

· A requirement does not conflict with other requirements.

· Requirements are achievable.

§ Test description: This test is not quantitative, but qualitative. Goals are achieved after team discussion. Brainstorming rather than data comparison.

§ Test condition: Is given by the input of all team members.

§ Expected Results: Once, verified the requirements are in order, the next step will be the system design.

---

Template created by G. Walton (GWalton@mail.ucf.edu) on March 28, 1999 and last modified on August 15, 2000.

This page last modified by Carlos Pereda (carloshpereda@knights.ucf.edu) on September 14, 2014