Cutlass - Rup Mtp Master Test Plan Artifact

Coventry University Track Locate and Assemble Version: 1.0 Master Test Plan Date: 22/11/2011 Nagarjuna Murthy

CONFIDENTIAL (C) TEAM-3, 2011 Page 1 of 15

TEAM 3

COVENTRY UNIVERSITY TRACK LOCATE AND ASSEMBLE (CUTLASS)

Master Test Plan

Version 1.0



Revision History

Date Version Description Author

22/Nov/2011 1.0 Master Test Plan Nagarjuna Murthy



Table of Contents

1. Introduction 5 1.1 Purpose 5 1.2 Scope 5 1.3 Intended Audience 5 1.4 Document Terminology and Acronyms 5 1.5 References 5

2. Evaluation Mission and Test Motivation 6 2.1 Background 6 2.2 Evaluation Mission 6 2.3 Test Motivators 6

3. Target Test Items 6

4. Outline of Planned Tests 6 4.1 Outline of Test Inclusions 6 4.2 Outline of Test Exclusions 7

5. Test Approach 7 5.1 Testing Techniques and Types 7

5.1.1 Data Integrity Testing 7 5.1.2 Function Testing 7 5.1.3 User Interface Testing 8 5.1.4 Installation Testing 8

6. Entry and Exit Criteria 9 6.1 Test Plan 9

6.1.1 Test Plan Entry Criteria 9 6.1.2 Test Plan Exit Criteria 9 6.1.3 Suspension and resumption criteria 9

6.2 Test Cycles 9 6.2.1 Test Cycle Entry Criteria 9 6.2.2 Test Cycle Exit Criteria 9 6.2.3 Test Cycle abnormal termination 9

7. Deliverables 9 7.1 Test Evaluation Summaries 9 7.2 Incident Logs and Change Requests 9

8. Testing Workflow 10

9. Environmental Needs 10 9.1 Base System Hardware 10 9.2 Base Software Elements in the Test Environment 11 9.3 Productivity and Support Tools 11

10. Responsibilities, Staffing and Training Needs 11 10.1 People and Roles 11 10.2 Staffing and Training Needs 12

11. Iteration Milestones 13



12. Risks, Dependencies, Assumptions and Constraints 13

13. Management Process and Procedures 14 13.1 Measuring and Assessing the Extent of Testing 14 13.2 Assessing the deliverables of this Test Plan 14 13.3 Problem Reporting, Escalation and Issue Resolution 14 13.4 Managing Test Cycles 14 13.5 Approval and Signoff 15



Master test plan 1. Introduction 1.1 Purpose

The purpose of the MTP is to collect all the required information to guide and control the overall test plans for CUTLASS. MTP will actually contain the information of each and every test to be executed during the test process and it will describe and categories each executed tests, it also gives information about the tests pass-fail criteria. MTP document for CUTLAS supports the following objectives:

1. Target if each test is to trace the last or miss placed devices, which are registered to CUTLASS

2. Target is to test whether it is compatible to different devices and different operating systems.

3. Target is to test whether the system maintains data base of each and every element of the system.

1.2 Scope The MTP will describe the different levels at which the tests are evolutes on the components of CUTLASS. At the level of unit testing, prior to each test the system has to go through reviews and has to be successful in order to be tested. The system test defines the interface between the following: 1. GUI 2. Main application of CUTLASS

The following performance measures will be tested

1. Successful registration of electronic devices to CUTLASS website 2. Response time for identifying and locating time registered devices 3. Response time to send the status report of devices to CUTLASS

1.3 Intended Audience:

This MTP is written for Coventry university students to safeguard their electronic devices, i.e., to register into track their devices in case of lost or misplaced. The CUTLASS management will also use their test plan in order to maintain the database of registered students and various management reports

. 1.4 Documents Terminology and Acronyms

• CUTLASS – Coventry University Track Locate and Assembler. • MTP – Master Test Plan. • GUI – Graphical User Interface. • TBD – To Be Decided.

1.5 References

http://www.dcs.ed.ac.uk http://www.RUP/rationalunifiedprocess



2. Evaluation Mission and Test Motivation

2.1 Background This test plan was designed as a guide to the CUTLASS testing efforts. This test plan will safeguard the student devices by tracking and locating of the devices. It gives the various information about the devices and maintains a database of each student.

2.2 Evaluation Mission Firstly, testing will be conducted in order to check whether it satisfies the requirements set forth by the CUTLASS use cases. Secondly, testing is conducted in order to check the quality of the designed components.

2.3 Test Motivators Testing CUTLASS will be motivated by the desire to safeguard electronic devises of the students and to ensure the desired requirements are met and also to maintain a complete database about all the registered students’ devices.

3. Target Test Items The targets to be tested have been identified as follows:

• Hardware Nominated electronic medium identifier

• Software Java platforms-Java 1.4.1

• Database – Oracle • Operating systems - Windows 98/ME

- Windows NT/2000/XP/7 - Macintosh - Android

4. Outline of Planned Tests

4.1 Outline of Test Inclusions The following test will be done on CUTLASS

• Security testing • Functional testing • Data integrity testing • Installation testing • UI testing



4.2 Outline of Test Exclusions The following testing on CUTLASS will not be conducted, as they do not categorize under project scope

• Load testing • Failure testing

5. Test Approach

5.1 Testing Technologies and Types 5.1.1 Data Integrity Test

Data integrity test will be conducted to ensure that the collected data is secured and not corrupted by the internal data structure testing is done independent of the user interface.

Technique objective Verify the data integrity of the imported data

independent of UI

Technique Verify the correct information from the devices and

maintain a database

Oracle The collect SQL file located in CUTLASS website

Required tools Java compiler and debugger

Success criteria All data elements should be stored securely without

any loss of data

5.1.2 Function Testing Functional testing will be conducted to render the functional requirement of CUTLASS

Technique objective Verify the functional requirements

Technique Verify the system requirements put forth in the

use case of CUTLASS

Oracle CUTLASS use cases

Required tools • Back up recovery tools (TBD)

• Data generation tool (TBD)

• Installation monitoring tools like CPU,

hard disk and memory (TBD)

Success criteria The following are successfully tested

• Key features



• Use case defined by CUTLASS

5.1.3 User Interface Testing

UI testing verifies the interaction between the system software and the user. The UI testing goal is to make sure UI provide the appropriate information and access to the users via CUTLASS website

Technique objective Navigate through the functions and

requirements, use of access

methods like mouse movement,

authentication and key strokes

Technique Device equipment testing such as

GPS, camera and internet

connection

Oracle Requirements are verify based on

their functionality

Required tools Program interface test

Success criteria Proper navigation information above

the registered devices and

authentication

5.1.4 Installation Testing

Installation testing is to ensure that the software can be installed correctly without any problem and at different condition such as adding and removing additional devices, installing in different OS. The purpose is to verify whether the installed software operating correctly.

Technique objective • To install the software in registered

device in different OS

• Update the new version of software

Technique • Install to a new device of different OS

and verify basic function

• Install to a previously installed devices

and upgrade to a new version

Oracles Functionality test plans



Required tools Electronic devices like laptops, cell phones

and iPods.

Success criteria The technique supports the testing of the

installed software by setting are own

configuration

6. Entry and Exit Criteria

6.1 Test Plan 6.1.1 Test Plan Entry Criteria

Installation process complete and the configuration has been informally reviewed by the team

6.1.2 Test Plan Exit Criteria All use case requirements are verified.

6.1.3 Suspension and Resumptions Criteria • Testing will be suspended if the system configuration does not support • Test resumes when the complete code and configuration is reviewed

6.2 Test Cycles

6.2.1 Test Cycle Entry Criteria Primarily, the test is planed, designed and implemented, and then the complete integration and system test is performed. Finally the evaluation test is performed to check whether the testing has successfully reached the requirement specification.

6.2.2 Test Cycle Exit Criteria

Test specified at the beginning of the iteration have completed successfully and iteration of the next test begins.

7. Deliverables The following artefacts will be testing deliverables, available to stockholders.

7.1 Test Evaluation Summaries The results of the test conducted will be outlined in these summaries.

7.2 Incidents Logs and Change Requests Incidents log entries will be made for the devices, which are registered, to CUTLASS. The log will be used to trade the status and location of the loss/misplaced registered devices.



Any changes or modification to the requirements must be processed through change request, which will make the required modification for the proposed changes. These changes are incorporated into CUTLASS after receiving the changes completely.

8. Testing Workflow

The outlook of the test work flow is as shown below. The complete description of the test workflow will be decided in the later stages.

Fig 1: Testing Work Flow

9. Environmental Needs

9.1 Base System Hardware The following table set forth the system resource for the test effort presented in this test plan.

System Resources

Resource Quantity Name and Type

Database Server 1 TBD

—Network or Subnet TBD

—Server Name TBD

—Database Name TBD

Test Development PCs 3 TBD



9.2 Base Software Elements in the Test Environment The following base software elements are required in the test environment for the test plan.

Software Element Name Version Type and Other Notes

NT Workstation Service pack 6 Operating System

Windows XP Service Pack 2 Operating System

Google Chrome Any Version Internet Browser

MS Outlook Any Version email Client software

Network Associates Kaspersky Virus Checker

Any Active Version Virus Detection and Recovery Software

9.3 Productive and Support Tools The following tools will be employed to support the test process for this test plan. Tool Category or Type Tool Brand Name Vendor or In-house

Test Management -TBD- -TBD-

Defect Tracking CUTLASS Website In-house

DBMS tools Oracle Vendor

10. Responsibilities, Staffing and Training Needs 10.1 People and Roles This table shows the staffing assumptions for the test effort.

Human Resources

Role Minimum Resources Recommended

(number of full-time roles allocated)

Specific Responsibilities or Comments

Test Manager 1 Provides management supervision.

Responsibilities include:

• planning and logistics

• agree mission

• identify motivators

• acquire appropriate resources

• evaluate effectiveness of test effort



Human Resources

Role Minimum Resources Recommended

(number of full-time roles allocated)

Specific Responsibilities or Comments

Test Analyst

2 Identifies and defines the specific tests to be conducted.


• identify test ideas

• define test details

• determine test results

• document change requests

• evaluate product quality

Test Designer

1 Defines the technical approach to the implementation of the test effort.


• define test approach

• verify test techniques

• define testability elements and structure

Tester 4 Implements and executes the tests.


• implement tests and test suites

• execute test suites

• log results

• analyze and recover from test failures

• document incidents

Implementer 1 Implements and unit tests the test classes and test packages.


• Creates the test components required to support testability requirements as defined by the designer.

10.2 Staffing and Training Needs

Staffing is appointed and fixed prior to beginning of entire project. Roles of each staff are decided depending on the testing phase. Staff members are assumed to have the required knowledge and experience about testing, group discussions and group



learning will be in practice in case of any new technique has to be implemented at the later stages of the testing phase.

11. Iteration Milestone

The milestone of iteration is as follows. The schedule for the iteration milestone will be decided later in the elaboration phase of the project.

Milestone Planned

Start Date

Actual Start Date

Planned End Date

Actual End Date

Iteration Plan agreed

Iteration starts

Requirements baseline

Architecture baseline

User Interface baseline

First Build delivered to test

First Build accepted into test

First Build test cycle finishes

[Build Two will not be tested]

Third Build delivered to test

Third Build accepted into test

Third Build test cycle finishes

Fourth Build delivered to test

Fourth Build accepted into test

Iteration Assessment review

Iteration ends

12. Risks, Dependencies, Assumptions and Constraints

Risk Mitigation Strategy Contingency (Risk is

realized)

System Specific Risk

Tester will make use of the secondary memory in case of system crash.

Update the values in primary memory

Network Risk Tester will use any other alternate network • Redefine test data • Reinvestigate test data



13. Management Process and Procedures

13.1 Measuring and Assessing the Extent of Testing Some measures are used on a confidential basis depending on the test plan. The goal is to follow up with additional investigation and exploring new techniques. If the testing fails, it is re-investigated and the issue is fixed.

13.2 Assessing the Deliverables of this Test Plan

Deliverables are assessed after the test is successfully completed. In case of any changes need the appropriate changes are made according to the requirement via change request. The deliverables are then installed in the system and tested completely to check whether the final outcome is according to the requirement specification. The deliverables are reanalysed and retested if any changes are to be made.

13.3 Problem Reporting, Escalation and Issue Resolving

Issues will be escalated to the testing team via email. Developers fix the errors and bugs from the list produced in the project page. Issues are resolved according to the priority; issues are given priority depending upon the risk and damage that might cause to the project.

13.4 Managing Test Cycle

Test will be conducted in the cycle as shown below. Complete details will be decided in the later stage of the project.

Plan Test Design Test Evaluate Test

Perform Integration Test

Perform System Test

Implement Test

Fig 2: Managing Test Cycle

Test manager

Tester 1

Tester 2

System Engineer



13.5 Approval and Sign off Prior to iteration of each test plan the project manager has to endorse the initial test plan. Tester will sign off use cases as the tests are successfully completed.

Date post:	27-Oct-2014
Category:	Documents
Upload:	saud-ab-aljaloud
View:	336 times
Download:	11 times