CS 451 Software Engineering Software Engineering Yuanfang Cai - - PowerPoint PPT Presentation

CS 451 Software Engineering Software Engineering

Yuanfang Cai Room 104 University Crossings Room 104, University Crossings 215.895.0298 f i@ d l d yfcai@cs.drexel.edu

Drexel University

1

Senior Design – Acceptance Test Plan Review

 The goal is to  define the criteria for approving the application.

Ti htl l d t th R i t d t

 Tightly coupled to the Requirements document.  Should be traceable to the requirements document.  WHAT’S INCLUDED?  WHAT S INCLUDED? 1.

Introduction

2

Test Approach

2.

Test Approach

3.

Test Assumptions and Exclusions

4.

Entry and Exit Criteria y

5.

Testing Participants

6.

Test Cases

Drexel University

2

Senior Design – Acceptance Test Plan Review

• 1. INTRODUCTION

Structure of the Document:

Section 2 Describes the overall approach to the Acceptance Test Plan Section 2 - Describes the overall approach to the Acceptance Test Plan process Section 3 - Describes in more detail individual issues covered or not covered by the Acceptance Test Plan process the Acceptance Test Plan process Section 4 - Describes the criteria which have to be satisfied for the Acceptance Test Plan project Section 5 - Describes the roles and responsibilities of the staff members involved in the Acceptance Test Plan project Section 6 - Describes the test cases used during the Acceptance Test Plan. .

Drexel University

3

Senior Design – Acceptance Test Plan Review—an Example

• 1. INTRODUCTION

Background:

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

References:

• Software Requirements Specification for VODKA

q p

Drexel University

Senior Design – Acceptance Test Plan Review—an Example

• 1. INTRODUCTION

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.
• Client's Representatives - Client's Representatives are people who overlook

th A t T t Pl ti b h lf f th t the Acceptance Test Plan execution on behalf of the customers

• Software Requirements Specification - A Software Requirements

Specification is a document which describes the behavior of a system.

• Functional Requirements - Functional Requirements define the internal

workings of the software.

• Unit Tests - A procedure in the software to validate that individual modules

p and other units of source code are working properly.

Drexel University

Senior Design – Acceptance Test Plan Review—an Example

• 2. TEST APPROACH AND CONSTRAINTS

Introduction

This section describes the overall approach particular techniques and 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 that may apply.

Test Objectives

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 Requirements Specification.

.

Drexel University

6

Senior Design – Acceptance Test Plan Review

• 2. TEST APPROACH AND CONSTRAINTS

Test Structure

The Acceptance Test Plan will consist of a subset of test cases and methods 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 . The test cases will be carefully selected and agreed upon by both the developer and the client and will allow for the agreed upon by both the developer and 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 the extensiveness

• f the full-scale System Test.
• f the full scale System Test.

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

Drexel University

.

7

Senior Design – Acceptance Test Plan Review

• 3. TEST ASSUMPTIONS AND EXCLUSIONS

 Introduction  Introduction  Test Assumption  Test Exclusions

Drexel University

Senior Design – Acceptance Test Plan Review

3 TEST ASSUMPTIONS AND EXCLUSIONS

• 3. TEST ASSUMPTIONS AND EXCLUSIONS

Introduction

This section provides greater details about what issues and features of VODKA will be d b A T Pl d h i d f f VODKA ill covered by Acceptance Test Plan process, and what issues and features of VODKA will not be covered

A ti Assumptions

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 . The Acceptance Test Plan will cover: The functional requirements

• f

the system listed in the Software Requirements S ifi ti Specification Usability of the system Consistency of the user related system documentation

Drexel University

Senior Design – Acceptance Test Pl R i Plan Review

• 3. TEST ASSUMPTIONS AND EXCLUSIONS

Exclusions

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 VODKA The Acceptance Test Plan will not cover:

• The non-functional requirements of the system (except the aforementioned

U bili ) li d i h S f R i S ifi i Usability) listed in the Software Requirements Specification

• Structural integrity of the source code.

Drexel University

Senior Design – Acceptance Test Pl R i Plan Review

• 4. ENRTY AND EXIT CRITERIA

 Introduction  Introduction  Entry Criteria  Exit Criteria

Drexel University

Senior Design – Acceptance Test Pl R i Plan Review

• 4. ENRTY AND EXIT CRITERIA

Introduction

This section lists the criteria which must be satisfied in order for the Acceptance Test Plan 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 Test Plan to stop.

Entry Criteria Entry Criteria

The Acceptance Test Plan can be initiated after the following preconditions are met: 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 representative A copy of the latest version of the Software Requirements Specification has been received py q p A copy of the latest version of the user-related documentation has been received The latest released version of VODKA has been appropriately resourced. A consent of the Project Leader has been obtained.

Drexel University

A consent of the Project Leader has been obtained. A consent of the Client has been obtained. A consent of the Test Team Leader has been obtained.

Senior Design – Acceptance Test Pl R i Plan Review

• 4. ENRTY AND EXIT CRITERIA

Exit Criteria Exit Criteria

The Acceptance Test Plan should be halted after either of the following: All Priority 1 requirements were tested without any deviation from expected behavior. (Success) At least one Priority 1 requirement deviated from the documented specification. (Failure) 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 rescheduled for a later date. (Failure)

Drexel University

Senior Design – Acceptance Test Pl R i Plan Review

5 TESTING PARTICIPANTS

• 5. TESTING PARTICIPANTS

 Introduction  Introduction  Roles and Responsibilities  Training Requirements  Problem Reporting  Progress Reporting

Drexel University

Senior Design – Acceptance Test Pl R i Plan Review

• 5. TESTING PARTICIPANTS

Introduction

This 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 problems that came up during testing.

Roles and Responsibilities

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

Drexel University

Senior Design – Acceptance Test Pl R i

5 TESTING PARTICIPANTS

Plan Review

• 5. TESTING PARTICIPANTS

Training Requirements

All parties involved in the Acceptance Test Plan should be familiar with the user interface of VODKA ll i h h d i d h S f R i VODKA, as well as with the system documentation and the Software Requirements Specification.

P bl R ti Problem Reporting

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 b itt d t th j t L d d dd d d i i di t t ff ti submitted to the project Leader, and addressed during a periodic or urgent staff meeting depending on the severity of the problems.

P R ti Progress Reporting

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.

Drexel University

Senior Design – Acceptance Test Pl R i Plan Review

• 6. TEST CASES

 Introduction  Introduction  Test Cases for All Users  Test Cases for Specific Users

p

Drexel University

Senior Design – Acceptance Test Pl R i Plan Review

• 6. TEST CASES

Introduction

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 format: Name - The name of the test case Preconditions - Conditions needed to initiate the test case Actions - The actions expected form a tester Post conditions - The expected outcome of the test case

Drexel University

Test Cases Examples Test Cases Examples

Test Cases for all Users The following test cases are for all user accounts. 6 2 1 Logging In 6.2.1 – Logging In

Preconditions The user has a web browser opened visiting the VODKA b web page Actions The tester enters his username and password in the appropriate fields and submits for verification. pp p Post conditions The tester is logged in to the system if the verification is successful

• r
• r

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

Drexel University

Test Cases Examples Test Cases Examples

Test Cases for all Users The following test cases are for all user accounts. 6 2 1 Logging In 6.2.1 – Logging In

Preconditions The user has a web browser opened visiting the VODKA b web page Actions The tester enters his username and password in the appropriate fields and submits for verification. pp p Post conditions The tester is logged in to the system if the verification is successful

• r
• r

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

Drexel University

Test Cases Examples

T t C f ll U

Test Cases Examples

Test Cases for all Users The following test cases are for all user accounts. 6.2.2 – Accounts Information

Preconditions The user has logged into the VODKA system gg y Actions None Post conditions The tester is presented with the Accounts Summary page p y p g

Drexel University

Test Cases Examples

Test Cases for all Users

Test Cases Examples

Test Cases for all Users The following test cases are for all user accounts. 6.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

Drexel University

Test Cases Examples

The following test cases are for all user accounts

Test Cases Examples

The following test cases are for all user accounts. 6.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.

Drexel University

Post conditions The transaction is created.

Test Cases Examples

6 2 5 – Transaction Modification

Test Cases Examples

6.2.5 Transaction Modification

Preconditions The tester is at the Account Transactions Summary page. g Actions The tester selects the "Change Transaction" button next to a transaction. Post conditions The tester is presented the Change Transaction page 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

• transaction. Then clicks Change.

Post conditions The transaction is modified.

Drexel University