Acceptance Test Plan

Transcription

1 Acceptance Test Plan

2 CURRENT DOCUMENT STATUS Version Number 1.0 File Name POS Connect Delivery Date 1/22/2013 Owner Description Taite Hughes, Martin Barbella, Sidhant Garg, Pradit Modi, Ryan Christen, Mohamadou Kone POS Connect Testing guidelines REVISI ON HISTO RY Revision Version Description of Change Changed By Effective Date Initial Revision Taite Hughes, Martin Barbella, Sidhant Garg, Pradit Modi, Ryan Christen, Mohamadou Kone 1/22/2013

3 TABLE OF CONTENTS 1 INTRODUCTION 1.1 Overview 1.2 Summary 1.3 Definitions and Acronyms 2 ACCEPTANCE TEST APPROACH 2.1 Acceptance Test Approach Summary 3 ACCEPTANCE TEST PROCESS 3.1 Establish Acceptance Test Framework 3.2 Plan Acceptance Test Activities 3.3 Develop Acceptance Test Cases Sources for Test Cases Test Procedures Development Testing Priority Test Tools Develop Test Traceability Documentation 3.4 Set Up the Acceptance Testing Environment 3.5 Execute Tests Record Issues/Defects Retesting Corrected Software Document Acceptance Test Results 4 ACCEPTANCE TEST ENTRANCE / EIT CRITERIA 4.1 Acceptance Test Entrance Criteria 4.2 Acceptance Test Exit Criteria 5 TEST CASES 5.1 Customer Test Cases Common Browsing a Store Cart Management and Checkout 5.2 POS Connect Website Test Cases

4 5.2.1 Common Downloading the Client 5.3 Online Store Management Test Cases Common Logging In Inventory Management Theme Management 5.4 Sales Test Cases Common Shipping Inventory Management 5.5 Client Test Cases Common Modifications Syncing 5.6 Conflict Test Cases Common Conflicts 5.7 Logging Test Cases Common Logged Information 6 RISKS 6.1 Insufficient Test Time 6.2 Incomplete Requirements 6.3 A Test Environment is not the same as the Production Environment 7 TRACEABILITY MATRI

5 1. INTRODUCTION 1.1 Overview This document is the Acceptance Test Plan (ATP) for POS_Connect software. This document is to be used to compare against the system created to ensure that the correct functionality has been implemented. The ATP contains the information and tests necessary for the acceptance testing. These tests are for validating that the system performs the functions that are required of it. The contents of the ATP are created with accordance to the requirement specification document, and thus the document traces back to the specifications in the requirement specification document. 1.2 Summary POS_Connect is a self contained standalone product. It is targeted at small businesses for the purpose of integrating with an existing local POS and creating a client editable web store with a focus on simple

6 user interface controls for clients that have little to no technical knowledge. 1.3 Definitions and Acronyms POS_Connect : The name of the product for which this document is being written. POS : Point of Sale, the part of the system that deals with transactions of goods or services for companies. ATP : Acceptance Test Plan. It is the document responsible for the information reguarding testing and building a correct and functional product. Visual Studio 2010 : A development environment for coding in specific microsoft developed languages. NetBeans IDE : A development environment that uses PHPUnit plug in order to do unit test. PHP Unit A testing framework we use to do unit test of the web application. Github : A web based hosting service for software development projects that handles source control. Github Issue Tracker : A system for monitoring the code and code progress within a Github environment. 2. ACCEPTANCE TEST APPROACH 2.1 Acceptance Test Approach Summary The test teams use a combination of white and black box testing with a primary focus on testing for success of components. There are some some testing for failure of systems where test for pass is inadequate. Test teams are also required to achieve maximum code coverage. This means that ideally 100% of all code written is executed, but 95% or higher is acceptable. 3. ACCEPTANCE TEST PROCESS 3.1 Establish Acceptance Test Framework The Acceptance Test Plan establishes the acceptance test framework used by the to plan, execute, and document acceptance testing of POS_Connect. Industry best practices for acceptance testing and data derived from the acceptance test team s interface with the software development processes form the basis for the Acceptance Test framework. 3.2 Plan Acceptance Test Activities A successful acceptance test effort requires planning. The acceptance test team identifies the tasks that need to be accomplished, including milestones. The functional requirements and POS_Connect documents are the primary drivers for identifying those tasks. The acceptance test schedule is the timeline of acceptance testing activities and deliverable due dates. For each acceptance testing effort, a test schedule is developed identifying the major test preparation, test execution, and test reporting activities, as well as providing interim checkpoints to measure the

7 progress of acceptance testing. 3.3 Develop Acceptance Test Cases Sources for Test Cases The acceptance test team uses the requirements, existing documentation, and actual execution of the existing test software to aid in development of the acceptance test cases. The acceptance test team reviews the software documentation, other documentation, and existing software to identify software components and features. The acceptance test team also attends requirements and design meetings and interviews persons involved in the system analysis, development, test, and operations to identify gaps and clarify questions Test Procedures Development All tests cases must follow the same procedure to be tested. They must be properly researched, assigned a priority, added to the Acceptance Test Plan, properly executed, and documented, in this order. This method allows for a universally known process making test teams more efficient Assigning Test Priority Assigning a test priority provides built in mitigation for schedule risks. Therefore, prior to the test effort, the most critical system features are identified and assigned a priority level. The most critical items are tested first, followed by progressively less critical items. This ensures the critical items are tested when insufficient test time is allocated for acceptance testing. This approach also provides immediate feedback on the critical system features early in the acceptance test so the developers can begin addressing serious defects immediately. Any test cases that are not run are recorded and all parties (stakeholders and development team) will be made aware of the problem in the test summary report Test Tools a Windows Visual Studio 2010 b Netbeans IDE NetBeans IDE is a development environment that uses PHPUnit plug in order to do unit test. c PHPUnit PHPUnit is a testing framework we use to do unit test of the web application. d Github issue tracker for recording and tracking known bugs Develop Test Traceability Documentation Test traceability is used to verify that functional requirements are accounted for, and appropriately tested, in the delivered software. It provides traceability between the requirements and the test cases. The acceptance test team develops the traceability from the requirements documents for the software. (See section 7 for Traceability Matrix)

8 3.4 Establish Testing Environment The acceptance test environment is made up of two different testing environments. Test teams are expected to be familiar with and have both environments functional prior to executing any test cases. The first environment is Windows Visual Studio 2010 for testing all client based C# related code. The other environment is Netbeans IDE running PHPUnit for testing all PHP related server code. Both environments are linked to the project s Github Issue tracking service where all information regarding bugs is recorded. 3.5 Execute Tests Acceptance test execution is an iterative process that begins with the initial execution of the planned tests. If no defects are discovered, then the test procedure have passed. If defects are discovered, they are documented, the defect is assigned to and fixed by a member of the development team, and the module is retested. Ideally, acceptance testing continues until all the acceptance tests are successfully executed. However, the acceptance test team recognizes that the system has firm deadlines. Thus, early in acceptance testing, the acceptance test team focuses on critical functionality and new features. If test time expires before completion of the acceptance tests, the acceptance test team provides the stakeholder with a list of the untested tests along with a risk analysis regarding the untested functionality Record Issues/Defects As the acceptance test team identifies issues and defects, the acceptance test team records them. For each incident, the defect tracking system, hosted on Github, documents what occurred, how it occurred, when it occurred, the tester who discovered it, and a preliminary assessment of the severity or priority of the problem. The acceptance test team tracks and reports on open defects until they are closed Retesting Corrected Software Upon receipt of a software correction, the acceptance test team re executes acceptance test procedures to retest each corrected defect. If the incident does not re occur the acceptance test team recommends closure of the defect. If the incident continues to occur, the acceptance test team informs the stakeholder and the development team and the defect remains open Document Acceptance Test Results At the end of the acceptance test, the acceptance test team produces a report summarizing the results of the acceptance test. The Test Summary Report is a short report summarizing the test activities, and identifies outstanding deficiencies and issues. The acceptance test team delivers

9 this report on a mutually agreed upon time frame shortly after the end of acceptance test. This report provides the stakeholder with information to make an informed system software acceptance or rejection decision. 4. ACCEPTANCE TEST ENTRANCE / EIT CRITERIA 4.1 Acceptance Test Entrance Criteria The acceptance test plan can be initiated when: POS Connect undergoes Unit Tests, Integration Tests, and System Tests A copy of the latest version of the Software Requirements Specification is received Consent of the Project Leader is obtained Consent of the Project Advisor is obtained Consent of the Project Stakeholder is obtained 4.2 Acceptance Test Exit Criteria The acceptance test plan is terminated when one of the following conditions has been met: All of the requirements outlined in the Software Requirements Specification is met (Success) At least one requirement deviated from the specification (Failure) 5. TEST CASES 5.1 Customer Test Cases Common For all customer test cases, a user is browsing a web store that is set up by POS Connect in a web browser Browsing a Store The user s cart is empty. The user navigates to a store located on a subdomain of the POS connect domain. The main page for the expected store is displayed. The main page for a particular store is rendered in a user s browser. The user clicks on the Products Page link on the navigation.

10 Products are displayed along with short descriptions, images (if they are available), buttons to add products directly to the cart, and options to filter by categories and search the products. A user is on the products page. The user clicks on a particular product. The product detail page for the product in question is displayed, which contai picture of the product (if available), the long description of the product, price, and a button to add the product to the cart. A user is on the products page. The user enters keywords into the search box and presses enter. A subset of the products are displayed which match the keywords entered by user. A user is on the products page. The user selects a product category by clicking on the link for the category in question. A subset of the products are displayed which belong to the selected category Cart Management and Checkout A user is somewhere on an individual store s site. The user selects the view cart option from the navigation. The user is brought to the cart page, which allows them to view the items pres in their cart, change quantities of the items, remove items entirely, or proceed checkout. A user is on the checkout page on a site that has chosen to use PayPal for checkout. The user provides the requested information and presses a button to proceed t

11 the payment page. The user is directed to PayPal to finish the checkout process. A user is on the checkout page on a site that has chosen to use authorize.net fo checkout. The user provides the requested information and presses a button to proceed t the payment page. The user is directed to authorize.net to finish the checkout process. 5.2 POS Connect Website Test Cases Common For POS Connect Website test cases, a user is someone who has navigated to the main page for POS Connect in a web browser. These users are potential clients who are seeking to learn more about POS connect, or who want to start using POS Connect Downloading the Client None. A user navigates to the main page for POS Connect. A link for the home page is displayed in the navigation. It shows up with a different background color than the other links from the home page. Other lin show up with a different background color. A search box is displayed on the top right hand side of the page. A user is on the main page for POS Connect. The user selects the download option in the navigation. The download page is displayed. A user is on the POS Connect download page. The user fills out the required information to create an account and clicks the submit button.

12 The installer is downloaded through the user s web browser, and an account i created for the user. 5.3 Online Store Management Test Cases Common For Online Store Management test cases, users are the owners of web stores managed by POS Connect. Unless otherwise noted, they already have authenticated using their credentials on their own store s site Logging In The user is not yet authenticated and clicks on the log in link on their own sto site. This leaves them on the login page for their store. User tries to log in with valid credentials. The user is brought to the main administration page. The user is not yet authenticated and clicks on the log in link on their own sto site. This leaves them on the login page for their store. User tries to log in with invalid credentials. An error is displayed, and the user is unable to proceed to the administration page Inventory Management A user is on the product administration page. This displays a list of items that a part of the store s inventory. The user selects a particular product. The administrative detail page for that product is displayed. A user is on the administrative product detail page for a particular item. The user edits the long description, stock, image, name, or any other displaye information about the product.

13 These changes are immediately reflected on the web store, and are also made the local POS after the next sync occurs Theme Management A user is on the theme administration page. The user selects a new theme from a preselected set of themes. The theme used by the web store in question is changed to the newly selected theme. 5.4 Sales Test Cases Common For sales test cases, the user is a store owner who has already authenticated to the administration page for their store and has navigated to the sales section Shipping Sales have previously been made that have not yet been processed. User clicks on a button to print shipping labels for an order that has previousl been made. The shipping label is printed with the correct receiver's name and address on i and the items that are a part of the order are listed Inventory Management The user has just finished entering payment processing via the applicable serv (PayPal or authorize.net). POS Connect receives a message from the service that payment was successfu Stocks for the items that are a part of the order are reduced by the proper amounts, and the next time the store owner views the administrative page they will see this order listed as ready to ship. The user has just finished entering payment processing via the applicable serv (PayPal or authorize.net).

14 POS Connect receives a message from the service that payment was unsuccessful. Stocks for the items are not changed. The users see an entry in a list of denied payments the next time they log in to the system. 5.5 Client Test Cases Common For Client test cases, the user has already installed the POS Connect software on the same computer that is running their POS Modifications The user makes a change to their inventory via the normal methods used by In POS. POS Connect starts its next update cycle. Before sending sync information, these changes are reflected in the database used by POS Connect Syncing POS Connect has done all pre processing necessary (outlined above) for syncing. POS Connect begins a sync. Changes are sent to the web server, and these changes are reflected in the remote database. Changes that are made on the web server are received by the client, updated in the local database, and pushed to the database used by Intui POS. No additional preconditions. A user selects the force sync option in the POS Connect client. All preprocessing for a sync is done, even if it has not been scheduled to happ yet. After preprocessing, the normal sync procedure happens as outlined abov

15 5.6 Conflict Test Cases Common For conflict test cases, multiple orders are made which cannot be satisfied. The parties involved are a store owner, the owner of the store that POS Connect is managing a web store for, a local customer, a customer that has made a purchase in the physical store, and an online customer, a customer that made a purchase in the web store Conflicts A purchase was made in store that caused the inventory for an item to drop below what would be required to satisfy an order in the web store that was ma after the last sync. The sync process occurs, notifying the web server that the stock for the item i question has changed. The local customer is not affected in any way. The web store refunds or cance the payment for the web customer, and sends them an notifying them th the item they ordered was no longer in stock. Stock for that item are adjusted the stock of the physical store. 5.7 Logging Test Cases Common Logging test cases refer to test cases that demonstrate what information should be logged by the POS Connect system, and where it should be logged Logged Information A web store has already been configured with accurate inventory information A conflict has occurred. A new entry is added to the log of conflicts. This is logged both by the web server and by the client at the time of the next sync. A web store has already been configured with accurate inventory information A sale has happened on the web store. A new entry is added to the log of sales. This is logged both by the web serve

16 and by the client at the time of the next sync. 6. RISKS 6.1 Insufficient Test Time Risk: If the amount of time available is too short, the acceptance test team may not have enough time to complete acceptance testing or perform regression testing. Mitigation: Develop a critical path of tests, prioritized by importance. 6.2 Incomplete Requirements Risk: May result in insufficient testing of the system. Mitigation: Use the traceability matrices to track the testing/requirements relationship. 6.3 A Test Environment is not the same as the Production Environment Risk: May prevent the detection of some defects and issues. Mitigation: Note the differences and work to have them as close as possible. 7. TRACEABILITY MATRI REQ 1.1 REQ 2.1 REQ 3.1 REQ 4.1 REQ 4.2 REQ 5.1 REQ 6.1 REQ 7.1 REQ 8.1 REQ 8.2 REQ 9.1 REQ 10.1 REQ 10.2 REQ 11.1 REQ 11.2 REQ 12.1 REQ 12.2 REQ 13.1 REQ 13.2 REQ 14.1 REQ 14.2 REQ 15.1

17 REQ 15.2 REQ 15.3 REQ 15.4 REQ 15.5 REQ 15.6 REQ 15.7 REQ 15.8 REQ 15.9 REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ REQ 15.30