BENEFISHER Software Test Specification Version 2.0 11/25/2014 TEAM WAKATI ! TABLE OF CONTENTS 1. INTRODUCTION 3 1.1 PURPOSE 4 1.2 SCOPE 4 1.3 ABBREVIATIONS, ACRONYMS, AND DEFINITIONS 4 1.4 REFERENCES 6 1.5 OVERVIEW OF CONTENTS OF DOCUMENT 6 2. TEST PLAN DESCRIPTION 7 2.1 PRODUCT SUMMARY 7 2.2 RESPONSIBILITIES 9 2.3 SCHEDULE 9 3. TEST DESIGN SPECIFICATION 11 3.1 TESTING APPROACH 11 3.2 FEATURE OR COMBINATION OF FEATURES NOT TO BE TESTED 12 3.3 ENVIRONMENTAL NEEDS 12 3.4 SUSPENSION / RESUMPTION CRITERIA 12 3.5 RISKS AND CONTINGENCIES 13 4. TEST SPECIFICATION 14 4.1 SEARCH 17 4.2 MAP 41 4.3 RESULTS 53 5. REQUIREMENTS TRACEABILITY 65 9. APPROVALS 69 ! !2 of !69 ! 1. INTRODUCTION
 This document is the Software Test Specification for the Benefisher project sponsored by Code for Sacramento, to be completed by Team Wakati. Project Team Team Wakati is comprised of undergraduate students majoring in Computer Science at California State University, Sacramento. The team members are enrolled in a two-semester senior project course required of all undergraduate majors. Successful delivery of the desired software product will fulfill the senior project requirement for the student team members. Name Email Phone Adrian Chambers [email protected] (707) 430-3775 Anthony Cristiano [email protected] (925) 321-7648 James Doan [email protected] (949) 690-4212 Daniel Green [email protected] (209) 402-3658 Jesse Rosato [email protected] (916) 541-5386 Table 1.1 Team Wakati Members Project Sponsor Code for Sacramento is a Code for America Brigade, whose mission is "to help government work for the people, by the people" [1]. Code4Sac has aligned the goal of improving access to public services data with their central missions of “connecting citizens and governments to design better services” and “open[ing] civic data” [1]. To that end, the sponsor has proposed the project under discussion. Name Role Email Brandon Pugh Brigade Captain [email protected] Ash Roughani Community Organizer [email protected] Table 1.2 Code for America Representatives 
 ! !3 of !69 ! 1.1 Purpose The purpose of the STS is to describe the plan for testing the software, and to specify the test cases and test procedures necessary to demonstrate that the software satisfies the requirements as specified in the project’s System Requirements Specification document. 
 1.2 Scope The plan contains a list and brief description of the use cases to be tested and the software components associated with each test case. The plan also provides a schedule for the testing and the assignment of team members to their respective testing tasks. The process for documenting resolving software errors and/or anomalies that are found during the testing is also specified. The test specification includes a list of the features to be tested for each of the use cases, the description each test case needed to fully test the use case, and the test procedures, or steps, necessary to execute each of the test cases. 
 1.3 Abbreviations, Acronyms, and Definitions TERM DEFINITION Applications Program Interface (API) Implemented declarations of how a software component will interact with other software components. A common example of an API is a web service that provides data via a collection of resource addresses. Microsoft Internet Explorer A Microsoft Windows web browser. End-to End Testing Tests user scenarios and various path conditions by verifying that the system runs and performs tasks accurately with the same of data from beginning to end, as intended. Google Chrome A multi-platform web browser. Graphical User Interface (GUI) The visible, 'tactile' interface of a software system, usually a mouse- or touch-based system. Mozilla Firefox An open-source, multi-platform web browser. N/A Not Applicable Quality Assurance (QA) A set of methods for monitoring the software development process to ensure quality deliverables. Requirements Traceability Matrix (RTM) A series of rows and columns used to relate portions of a software engineering document to specific requirements. Software feature A distinguishing characteristic associated with a use case (e.g. its functionality, performance, ease of use, performance, etc.). ! !4 of !69 ! TERM DEFINITION Sprint.ly A web application that helps organize software development tasks. TBD To Be Determined Test case specification A specification of inputs, expected results, and a set of execution steps associated with the testing of a feature (or features) associated with a use case. Software problem report A document reporting on any event that occurs during the testing process which requires investigation (see appendix A for a copy of the Software Problem Report form). Software Design Specification (SDS) Software Design Specification Software Requirements Specification (SRS) A software engineering document that establishes the requirements for the system under consideration. Software Testing Specification (STS) A software engineering document that establishes a baseline plan for testing a system. System test report A document summarizing testing activities and results. It also contains an evaluation of the degree to which the software product satisfies to the system requirements for each of the use cases. Test log A chronological record of relevant details about the execution of tests. Web browser An application for making HTTP requests and handling HTTP responses by rendering web pages and executing their included scripts. Table 1.3 Abbreviations, Acronyms, and Definitions ! !5 of !69 ! 1.4 References 1. Software Requirements Specification. Chambers, A., Cristiano, A., Doan, J., Green, D., and Rosato, J., Team Wakati, Sacramento, CA, May 1, 2014. 2. Software Design Specification. Chambers, A., Cristiano, A., Doan, J., Green, D., and Rosato, J., Team Wakati, Sacramento, CA, Oct. 17, 2014. 3. “AngularJS API Docs”, [online], AngularJS, https://docs.angularjs.org/api/ngMock/service/$httpBackend, [Oct. 25, 2014]. 4. "Nock", Teixeira, P. [online], https://github.com/pgte/nock, [Oct. 24, 2014]. 5. “Open Eligibility Project”, [online], http://openeligibility.org/, [April 14, 2014] 1.5 Overview of Contents of Document Test Plan Description This section provides a summary of the Use Cases and the plan for carrying out the system test phase of the team’s software development process. More specifically, this section contains a brief description of each Use Case to be tested, the team member (or members) assigned to test each Use Case, the testing schedule, and the risk management plan. Test Design Specification This section describes the details of the test approach, lists the use cases that are and are not to be tested, lists the environmental needs, and details the pass/fail and suspension/resumption criteria. Test Specification This section contains subsections for each of the features to be tested. Each subsection specifies the use cases to be tested, the procedures necessary to run the test cases, and the items being tested. Requirements Traceability This section provides for a cross referencing of each use case to its test specification and also to its design components. The appropriate section and its title in each document are provided. Approvals This section contains the list of the key signatories necessary to sign-off on the STS, thereby agreeing to the scope and content of the test plan and test cases specified within the document. Approval constitutes a guarantee that the development team has produced a test specification sufficient for validating the software to be delivered to the sponsor. ! !6 of !69 ! 2. TEST PLAN DESCRIPTION
 The Benefisher application is made up of many features that allow users to search for public services. Each feature is made up of a number of use cases, and each use case can be tested in a number of ways. This section details each of the features, their respective use cases, how Team Wakati plans to test each use case, who will be responsible for testing specific use cases, the planned schedule, and the risk plan in case certain use cases are not tested properly. 2.1 Product Summary Benefisher is a public services search application that makes it easy for users to find the best services related to their needs. Benefisher is a single-page application designed for ease-of-use. That simplicity belies a fairly complex interconnection of components. ! !7 of !69 ! Features Use Cases Components View Client Server Database Search Search for Service layout.jade app.js app.js search_result Search by Need index.jade services.js index.js search_query Search by Situation scripts.jade map-controller.js search.js Search by Need & map.jade search-service.js neuralnet.js Situation notification.jade interaction- interactions.js Browse service.js Select Pre-Defined Need notification- Select Pre-Defined service.js Situation Remove from Screen Save Search Query Map Search for Service layout.jade app.js app.js search_result Browse Map index.jade services.js index.js search_query Interact with Results scripts.jade search- search.js search_result_int Remove from Screen search.jade controller.js neuralnet.js eraction Click Result on Map search-service.js service interaction- service.js Results Search for Service layout.jade app.js app.js search_result Browse index.jade services.js index.js search_result_int Save Interaction Data scripts.jade results- search.js eraction Interact with Results results.jade controller.js interactions.js Expand Results notifcation.jade search-service.js Get Directions interaction- Call Service service.js Navigate to Site notification- Email Service service.js Remove from Screen Click Result on Map Table 2.1 Feature-Use Case-Component Matrix ! !8 of !69 ! 2.2 Responsibilities The roles and responsibilities of each team member during the testing process are listed in the table below. These roles are intended to be fluid, and each member may assume various roles as needed during testing. Name Role Responsibilities Adrian Chambers Test Lead Oversee and coordinate test process. Anthony Cristiano Recorder Record test results. James Doan Tester Execute test procedures and augment automated tests. Daniel Green Tester Execute test procedures and augment automated tests. Jesse Rosato Tester Execute test procedures and augment automated tests. Table 2.2 Testing Roles and Responsibilities 2.3 Schedule The schedule for testing the application is as follows: Figure 2.1 Testing Schedule ! !9 of !69 ! Activity Description Exit Criteria Alpha Testing All tests are executed and recorded All tests have been executed and reported. according to specified test procedures. Alpha Defect Correct critical defects, and as many non- All critical defects have been corrected, Correction critical defect as time allows. Add and all non-critical defects have been remaining non-crtical defects to the corrected or the time limit for this activity project's backlog. has passed. Beta Testing All tests are executed and recorded All tests have been executed and reported. according to specified test procedures. Server Testing The application is installed on a staging All tests have been executed and reported. server, and all tests are executed and recorded according to specified test procedures. Beta Defect Correct critical defects, and as many non- All critical defects have been corrected, Correction critical defect as time allows. Add and all non-critical defects have been remaining non-crtical defects to the corrected or the time limit for this activity project's backlog. has passed. Test Reporting Use the results of testing to generate the The test report is complete. test report. Table 2.3 Testing Activities ! !10 of !69