senior design – acceptance test plan review the goal is to: define the criteria for approving the...

Senior Design – Acceptance Test Plan ReviewSenior Design – Acceptance Test Plan Review

The goal is to: define the criteria for approving the application.The goal is to: define the criteria for approving the application.• Tightly coupled to the Requirements document. Tightly coupled to the Requirements document. • Should be traceable to the requirements document.Should be traceable to the requirements document.

Acceptance testing generally involves running a suite of tests on the completed system. Each individual Acceptance testing generally involves running a suite of tests on the completed system. Each individual test, known as a case, exercises a particular operating condition of the user's environment or feature of the test, known as a case, exercises a particular operating condition of the user's environment or feature of the system, and will result in a pass or fail, or system, and will result in a pass or fail, or boolean, outcome. There is generally no degree of success or , outcome. There is generally no degree of success or failure. The test environment is usually designed to be identical, or as close as possible, to the anticipated failure. The test environment is usually designed to be identical, or as close as possible, to the anticipated user's environment, including extremes of such. These test cases must each be accompanied by test case user's environment, including extremes of such. These test cases must each be accompanied by test case input data or a formal description of the operational activities (or both) to be performed—intended to input data or a formal description of the operational activities (or both) to be performed—intended to thoroughly exercise the specific case—and a formal description of the expected results.thoroughly exercise the specific case—and a formal description of the expected results.

Acceptance Tests/Criteria (in Acceptance Tests/Criteria (in Agile Software Development) are usually created by business customers and ) are usually created by business customers and expressed in a expressed in a business domain language. These are high level tests to test the completeness of a . These are high level tests to test the completeness of a user story or stories 'played' during any sprint/iteration. These tests are created ideally through or stories 'played' during any sprint/iteration. These tests are created ideally through collaboration between business customers, business analysts, testers and developers, however the business collaboration between business customers, business analysts, testers and developers, however the business customers (product owners) are the primary owners of these tests. As the user stories pass their acceptance customers (product owners) are the primary owners of these tests. As the user stories pass their acceptance criteria, the business owners can be sure of the fact that the developers are progressing in the right criteria, the business owners can be sure of the fact that the developers are progressing in the right direction about how the application was envisaged to work and so it's essential that these tests include both direction about how the application was envisaged to work and so it's essential that these tests include both business logic tests as well as UI validation elements (if need be).business logic tests as well as UI validation elements (if need be).

http://en.wikipedia.org/wiki/Boolean_logic

http://en.wikipedia.org/wiki/Agile_Software_Development

http://en.wikipedia.org/wiki/Domain_Specific_Language

http://en.wikipedia.org/wiki/User_story


WHAT’S INCLUDED?WHAT’S INCLUDED?

IntroductionIntroductionTest ApproachTest ApproachTest Assumptions and ExclusionsTest Assumptions and ExclusionsEntry and Exit CriteriaEntry and Exit CriteriaTesting ParticipantsTesting ParticipantsTest CasesTest Cases


INTRODUCTIONINTRODUCTION

BackgroundBackgroundStructure of the DocumentStructure of the DocumentReferencesReferencesGlossaryGlossary


INTRODUCTION INTRODUCTION

Background:Background:

This document provide the plan for completing the testing activities This document provide the plan for completing the testing activities required for the Acceptance Test Plan of VODKA . VODKA is a tool to required for the Acceptance Test Plan of VODKA . VODKA is a tool to manage the financial accounts of student organizations within a manage the financial accounts of student organizations within a school or university. It is described in greater detail in the Software school or university. It is described in greater detail in the Software Requirements Specification for VODKARequirements Specification for VODKA

..


INTRODUCTION – INTRODUCTION –

Structure of the Document:Structure of the Document:

•Section 2 - Describes the overall approach to the Acceptance Test Section 2 - Describes the overall approach to the Acceptance Test Plan processPlan process

•Section 3 - Describes in more detail individual issues covered or not Section 3 - Describes in more detail individual issues covered or not covered by the Acceptance Test Plan processcovered by the Acceptance Test Plan process

•Section 4 - Describes the criteria which have to be satisfied for the Section 4 - Describes the criteria which have to be satisfied for the Acceptance Test Plan projectAcceptance Test Plan project

•Section 5 - Describes the roles and responsibilities of the staff Section 5 - Describes the roles and responsibilities of the staff members involved in the Acceptance Test Plan projectmembers involved in the Acceptance Test Plan project

•Section 6 - Describes the test cases used during the Acceptance Test Section 6 - Describes the test cases used during the Acceptance Test Plan.Plan.



References:References:

•Software Requirements Specification for VODKASoftware Requirements Specification for VODKA



Glossary:Glossary:

• Test Team Leader - The person in charge of all the testers.Test Team Leader - The person in charge of all the testers.• Project Leader - The person in charge of the whole project.Project Leader - The person in charge of the whole project.• Client's Representatives - Client's Representatives are people who Client's Representatives - Client's Representatives are people who overlook the Acceptance Test Plan execution on behalf of the overlook the Acceptance Test Plan execution on behalf of the customerscustomers• Software Requirements Specification - A Software Requirements Software Requirements Specification - A Software Requirements Specification is a document which describes the behavior of a Specification is a document which describes the behavior of a system.system.• Functional Requirements - Functional Requirements define the Functional Requirements - Functional Requirements define the internal workings of the software.internal workings of the software.• Unit Tests - A procedure in the software to validate that individual Unit Tests - A procedure in the software to validate that individual modules and other units of source code are working properlymodules and other units of source code are working properly

•..•..•..


TEST APPROACH AND CONSTRAINTSTEST APPROACH AND CONSTRAINTS

IntroductionIntroduction

This section describes the overall approach, particular techniques and testing tools This section describes the overall approach, particular techniques and testing tools which will be used during the Acceptance Test Plan of the VODKA and any constraints which will be used during the Acceptance Test Plan of the VODKA and any constraints that may apply.that may apply.

Test ObjectivesTest Objectives

The Acceptance Test Plan process will prompt the client to evaluate VODKA and verify The Acceptance Test Plan process will prompt the client to evaluate VODKA and verify whether it performs in accordance with the client's requirements, listed in the Software whether it performs in accordance with the client's requirements, listed in the Software Requirements Specification.Requirements Specification.

Test StructureTest Structure

The Acceptance Test Plan will consist of a subset of test cases and methods, previously The Acceptance Test Plan will consist of a subset of test cases and methods, previously utilized in the Unit Tests, Integration Test and System Test conducted on the VODKA . utilized in the Unit Tests, Integration Test and System Test conducted on the VODKA . The test cases will be carefully selected and agreed upon by both the developer and The test cases will be carefully selected and agreed upon by both the developer and the client, and will allow for the most adequate verification of the functional the client, and will allow for the most adequate verification of the functional requirements of the VODKA , as listed in the Software Requirements Document, without requirements of the VODKA , as listed in the Software Requirements Document, without the extensiveness of the full-scale System Test.the extensiveness of the full-scale System Test.

It is essential that all appropriate Unit Tests, Integration Test and the System Test were It is essential that all appropriate Unit Tests, Integration Test and the System Test were successfully performed for VODKA prior to the Acceptance Test Plan and their results successfully performed for VODKA prior to the Acceptance Test Plan and their results were reported and presented to the client.were reported and presented to the client.


TEST ASSUMPTIONS AND EXCLUSIONSTEST ASSUMPTIONS AND EXCLUSIONS

IntroductionIntroductionTest ObjectivesTest ObjectivesTest StructureTest Structure



IntroductionIntroductionThis section provides greater details about what issues and features of VODKA will be This section provides greater details about what issues and features of VODKA will be covered by Acceptance Test Plan process, and what issues and features of VODKA will covered by Acceptance Test Plan process, and what issues and features of VODKA will not be coverednot be covered

AssumptionsAssumptionsIt is assumed that all issues covered by the Acceptance Test Plan were also previously It is assumed that all issues covered by the Acceptance Test Plan were also previously addressed by the Unit Tests, Integration Test and System Test of VODKA .addressed by the Unit Tests, Integration Test and System Test of VODKA .

The Acceptance Test Plan will cover:The Acceptance Test Plan will cover:• The functional requirements of the system listed in the Software Requirements The functional requirements of the system listed in the Software Requirements SpecificationSpecification• Usability of the systemUsability of the system• Consistency of the user related system documentationConsistency of the user related system documentation



ExclusionsExclusionsIt is assumed that all issues not covered by the Acceptance Test Plan were previously It is assumed that all issues not covered by the Acceptance Test Plan were previously addressed by Unit Tests, Integration Tests and System Tests of VODKAaddressed by Unit Tests, Integration Tests and System Tests of VODKA

The Acceptance Test Plan will not cover:The Acceptance Test Plan will not cover:• The non-functional requirements of the system (except the aforementioned Usability) The non-functional requirements of the system (except the aforementioned Usability) listed in the Software Requirements Specificationlisted in the Software Requirements Specification• Structural integrity of the source code.Structural integrity of the source code.


ENRTY AND EXIT CRITERIAENRTY AND EXIT CRITERIA

IntroductionIntroductionEntry CriteriaEntry CriteriaExit CriteriaExit Criteria



IntroductionIntroductionThis section lists the criteria which must be satisfied in order for the Acceptance Test This section lists the criteria which must be satisfied in order for the Acceptance Test Plan to begin, as well as the criteria which must be satisfied in order for the Acceptance Plan to begin, as well as the criteria which must be satisfied in order for the Acceptance Test Plan to stop.Test Plan to stop.

Entry CriteriaEntry CriteriaThe Acceptance Test Plan can be initiated after the following preconditions are met:The Acceptance Test Plan can be initiated after the following preconditions are met:

• VODKA has successfully undergone Unit Tests, Integration Test and System Test.VODKA has successfully undergone Unit Tests, Integration Test and System Test.• The testing environment which satisfies the System Requirements of Software The testing environment which satisfies the System Requirements of Software Requirements Specification has been setup and inspected by the client's representativeRequirements Specification has been setup and inspected by the client's representative• A copy of the latest version of the Software Requirements Specification has been A copy of the latest version of the Software Requirements Specification has been receivedreceived• A copy of the latest version of the user-related documentation has been receivedA copy of the latest version of the user-related documentation has been received• The latest released version of VODKA has been appropriately resourced.The latest released version of VODKA has been appropriately resourced.• A consent of the Project Leader has been obtained.A consent of the Project Leader has been obtained.• A consent of the Client has been obtained.A consent of the Client has been obtained.• A consent of the Test Team Leader has been obtained.A consent of the Test Team Leader has been obtained.



Exit CriteriaExit Criteria

The Acceptance Test Plan should be halted after either of the following:The Acceptance Test Plan should be halted after either of the following:• All Priority 1 requirements were tested without any deviation from expected behavior. All Priority 1 requirements were tested without any deviation from expected behavior. (Success)(Success)• At least one Priority 1 requirement deviated from the documented specification. At least one Priority 1 requirement deviated from the documented specification. (Failure)(Failure)• By mutual agreement between Client's Representative and the Tester, in which both By mutual agreement between Client's Representative and the Tester, in which both parties' supervisors should be notified and the Acceptance Test Plan should be parties' supervisors should be notified and the Acceptance Test Plan should be rescheduled for a later date. (Failure)rescheduled for a later date. (Failure)


TESTING PARTICIPANTSTESTING PARTICIPANTS

IntroductionIntroductionRoles and ResponsibilitiesRoles and ResponsibilitiesTraining RequirementsTraining RequirementsProblem ReportingProblem ReportingProgress ReportingProgress Reporting



IntroductionIntroductionThis section describes the roles and responsibilities of the staff members involved in This section describes the roles and responsibilities of the staff members involved in the Acceptance Test Plan, as well as the procedure of reporting the test results and any the Acceptance Test Plan, as well as the procedure of reporting the test results and any problems that came up during testing.problems that came up during testing.

Roles and ResponsibilitiesRoles and Responsibilities

For the Acceptance Test Plan, the following roles were assumed by the following people:For the Acceptance Test Plan, the following roles were assumed by the following people:• Test Team Leader: Archit BawejaTest Team Leader: Archit Baweja• Client's Representative: A person in charge from the client's side who will overview the Client's Representative: A person in charge from the client's side who will overview the testing process.testing process.• Tester: A person who will execute the use case tests.Tester: A person who will execute the use case tests.



Training RequirementsTraining RequirementsAll parties involved in the Acceptance Test Plan should be familiar with the user All parties involved in the Acceptance Test Plan should be familiar with the user interface of VODKA, as well as with the system documentation and the Software interface of VODKA, as well as with the system documentation and the Software Requirements Specification.Requirements Specification.

Problem ReportingProblem ReportingAny problem pointed out by either the Client's Representative or the Tester must be Any problem pointed out by either the Client's Representative or the Tester must be documented and reported to the Test Team Leader. Later the problem report will be documented and reported to the Test Team Leader. Later the problem report will be submitted to the project Leader, and addressed during a periodic or urgent staff submitted to the project Leader, and addressed during a periodic or urgent staff meeting depending on the severity of the problems.meeting depending on the severity of the problems.

Progress ReportingProgress ReportingThe Acceptance Test Plan Report will be compiled once, after testing process is finished The Acceptance Test Plan Report will be compiled once, after testing process is finished by the Test Team Leader and submitted to the Project Leader.by the Test Team Leader and submitted to the Project Leader.


TEST CASESTEST CASES

IntroductionIntroductionTest Cases for All UsersTest Cases for All UsersTest Cases for Specific UsersTest Cases for Specific Users



IntroductionIntroductionThe test cases are distributed in sections covering functionality elements and use cases The test cases are distributed in sections covering functionality elements and use cases in the Software Requirements Specification. Each of the following test cases is in the in the Software Requirements Specification. Each of the following test cases is in the format:format:

• Name - The name of the test caseName - The name of the test case• Preconditions - Conditions needed to initiate the test casePreconditions - Conditions needed to initiate the test case• Actions - The actions expected form a testerActions - The actions expected form a tester• Post conditions - The expected outcome of the test casePost conditions - The expected outcome of the test case



Test Cases for all UsersTest Cases for all Users

The following test cases are for all user accounts.The following test cases are for all user accounts.

6.2.1 – Logging In6.2.1 – Logging In

Preconditions The user has a web browser opened visiting the VODKA web page

Actions The tester enters his username and password in the appropriate fields and submits for verification.

Post conditions The tester is logged in to the system if the verification is successfulorThe tester is not logged in to the system if the verification is not successful.





6.2.1 – Logging In6.2.1 – Logging In

What is missing?What is missing?

Preconditions The user has a web browser opened visiting the VODKA web page

Actions The tester enters his username and password in the appropriate fields and submits for verification.

Post conditions The tester is logged in to the system if the verification is successfulorThe tester is not logged in to the system if the verification is not successful.





6.2.2 – Accounts Information6.2.2 – Accounts Information

Preconditions The user has logged into the VODKA system

Actions None

Post conditions The tester is presented with the Accounts Summary page





6.2.3 – Accounts Transitions Summary6.2.3 – Accounts Transitions Summary

Preconditions The user has logged into the VODKA system

Actions None

Post conditions The tester is presented with the Accounts Summary page





6.2.4 – Transaction Creation6.2.4 – Transaction Creation

Preconditions The tester is at the Account Transactions Summary page.

Actions The tester selects the "Create Transaction" option.

Post conditions The tester is presented the Create Transaction page.

Preconditions The tester is at the Create Transaction page.

Actions The tester enters in all the details for a transaction. Then clicks Save.

Post conditions The transaction is created.



6.2.5 – Transaction Modification6.2.5 – Transaction Modification

Preconditions The tester is at the Account Transactions Summary page.

Actions The tester selects the "Change Transaction" button next to a transaction.

Post conditions The tester is presented the Change Transaction page.

Preconditions The tester is at the Change Transaction page.

Actions The tester enters in all the new information for the transaction. Then clicks Change.

Post conditions The transaction is modified.