test plan on iit website

IIT Official Website Software Test plan

Institute of Information Technology

University of Dhaka

1 | T e s t P l a n

Report On

Software Test Plan of IIT

Website Software Testing and Quality Assurance

SE-605

Prepared By:

Md. Samsuddoha BSSE-0309

Md. Shafiuzzaman BSSE-0322

Submitted to:

Mohammad Ashik Elahi

Software Testing and Quality Assurance Eng.

M&H Informatics BD Ltd.

Institute of Information Technology

University of Dhaka

2 | T e s t P l a n

5th December 2013

Contents 1. Test Plan Identifier: ......................................................................................................................... 4

2. References: ..................................................................................................................................... 4

3. Introduction .................................................................................................................................... 5

3.1 Objectives...................................................................................................................................... 5

3.2 Scope ............................................................................................................................................. 5

3.3 Definitions and Acronyms ............................................................................................................. 6

4. Test Items ........................................................................................................................................ 7

5. Software Risk Issues ........................................................................................................................ 8

6. Features to be tested .................................................................................................................... 10

7. Features not to be tested ............................................................................................................. 13

8. Process Overview .......................................................................................................................... 13

9. Testing Process.............................................................................................................................. 14

10. Test Strategy ............................................................................................................................. 15

Unit Testing: ...................................................................................................................................... 16

Integration Testing ............................................................................................................................ 17

System Testing .................................................................................................................................. 17

Functional test .................................................................................................................................. 17

User Interface Testing ....................................................................................................................... 17

11. Item Pass/Fail Criteria ............................................................................................................... 18

12. Suspension Criteria ................................................................................................................... 18

13. Test Deliverable ........................................................................................................................ 19

14. Remaining Test Tasks ................................................................................................................ 20

15. Environmental Needs ................................................................................................................ 20

16. Staffing and Training Needs ...................................................................................................... 21

17. Responsibilities ......................................................................................................................... 22

18. Schedule .................................................................................................................................... 23

19. Approval .................................................................................................................................... 23

3 | T e s t P l a n

4 | T e s t P l a n

Test Plan Identifier

1. Test Plan Identifier: This is the test plan on IIT Website. This is an official website that is being developed for the Institute of Information Technology which is one of the leading institutes of Dhaka University as well as Bangladesh. IIT is rapidly moving towards evolution of Digital Bangladesh. To build technological Bangladesh, we need to make sure our people are aware about new era technology and information. IIT is going to make executives of software industry to fulfill our dreams. So as to meet the basic necessity we build IIT web site for IIT to gather all the information of IIT. For this purpose we want to make the website as an example of excellence which will support the institute as well as all the users. This test plan will ensure the functional test of this system and it will support the whole system that is being developed accurately. This test plan contains the test approach, how different types of testing will take place and an excel shit containing the test scenarios and expected result. This is the first version of test plan and it is at level 1 at this moment because, when new feature will include in it, software test team will enrich this test plan according to change. Though in this project we only cover the result part so we emphasize on the result relevant activities, relevant test scenarios.

References

2. References: This test plan for IIT Official Website is developed on some supporting documents. Refer to the actual version of the document as stored in the configuration management system. Here is the list for those reference documents.

Project Plan IIT Official Website Software Requirements Specification Detail design document Test plan template IEEE-829. International Standard Testing.

For this test plan, we followed IEEE-829 format and the Software Requirements Specification document.

5 | T e s t P l a n

Introduction of the Test Plan

3. Introduction

This document is intended to give a complete planning of a systematic strategy for

software testing of IIT official website. IIT official website is composed of numerous

features. This test plan is actually designed to ensure those features work up to the

mark. Both directly and indirectly affected elements will be addressed here.

In following paragraphs we will discuss the purpose of the plan, its scope and define the

acronyms used in this document.

3.1 Objectives

This document supports the following objectives:

Identify existing project information

Identify the approach that should be followed.

Identify the features that should be tested.

List the recommended test requirements.

Recommend and describe the testing strategies to be employed.

Identify the required resources and provide an estimation of the test efforts.

Fix the schedule of intended testing activities.

Identify the risks associated with the test strategy.

List the deliverable elements of the test activities.

3.2 Scope

Testing will begin at the component level and work toward the integration of the entire

system. This document will mainly provide the blue print of high level testing

approaches of IIT official website. It will provide a guidance to the test engineers and a

set of milestones for the manager. It will validate major system functions of IIT official

website against the customer requirements. So the whole software specification will be

strictly followed in every steps. As the system has a large set of features, we have

prioritized the features and testing will take place according to this priority.

6 | T e s t P l a n

3.3 Definitions and Acronyms

Name Description

IEEE The Institute of Electrical and Electronic Engineers, Inc. Publisher of engineering standards.

Integration Testing A level of test undertaken to validate the interface between internal components of a system. Typically based upon the system architecture.

Black-Box Testing A type of testing where the internal workings of the system are unknown or ignored (i.e., functional or behavioral testing). Testing to see if the system does what it's supposed to do.

Milestone A major checkpoint or a sub-goal identified on the project or testing schedule.

Smoke Test A test runs to demonstrate that the basic functionality of a system exists and that a certain level of stability has been achieved. Frequently used as part of the entrance criteria to a level of test

Software Risk Analysis

An analysis undertaken to identify and prioritize features and attributes for testing.

Strategy A description of how testing will be conducted. Includes any issues that affect the effectiveness or efficiency of testing.

Suspension Criteria

Metrics that describe a situation in which testing will be completely or partially halted (temporarily).

System Testing A (relatively) comprehensive test undertaken to validate an entire system and its characteristics. Typically based upon the requirements and design of the system.

Test Item A programmatic measure of something that will be tested (i.e. a program, requirement specification, version of an application, etc.).

Test Deliverable Any document, procedure, or other artifact created during the course of testing that's intended to be used and maintained.

Unit Testing A level of test undertaken to validate a single unit of code. Typically conducted by the programmer who wrote the code.

White-Box Testing Testing based upon knowledge of the internal (structure) of the system. Testing not only what the system does, but also how it does it (i.e. Structural Testing).

7 | T e s t P l a n

Test Items

4. Test Items

In this section we will provide a list of all those components that has been identified as

test items. It is assumed that unit testing will be done thorough black box testing and

testing of all module interfaces will be ensured.

The interfaces between the following subsystems will be tested:

Manage Gallery

Manage News and Events

Manage Program

Manage Semester

Manage Course

Manage Faculty

Manage Batch

Manage Student

Achievements

Club

Profile

Document

Attendance

Project and Thesis

Manage Group

Manage Exam

Manage Admission

The external interfaces to the following browser will be tested:

Mozilla Firefox

Google Chrome

Internet Explorer

8 | T e s t P l a n

The basic performance test:

Add album

Modify album

Upload picture

Delete picture

Add achievements

Add news/events

Modify news/events

Create program

Modify program

Create semester

Modify semester

Create course

Modify course

Add faculty member

Modify faculty

member

Assign course

Add Batch

Modify Batch

Add Student

Modify Student

Add club

Modify club

Create Profile

Edit Profile

Upload document

Download document

Delete document

Attendance

Add project/thesis

Add group

Create admission form

The most critical performance measures to test are:

1. Response time for remote login.

2. Response time for updating information.

3. Response time for requested services.

Software Risk Issues

5. Software Risk Issues

There are several parts of the project that are not within the control of the application

but have direct impacts on the process and must be checked as well. Our main goal is to

design a test strategy that utilizes a balance of testing techniques to cover a

representative sample of the system in order to minimize risk. When conducting risk

analysis, two major components are taken into consideration:

The probability that the negative event will occur.

9 | T e s t P l a n

The potential loss or impact associated with the event.

We identify following risk issues associated with the test approaches of IIT official

website.

Not Enough Training/Lack of Test Competency: As the system will be tested

by the third year students of IIT, there lacks competency and experience among

them. So there is a possibility of misunderstanding and misapplication of testing

techniques.

Us versus Them Mentality: This common problem arises when developers and

testers are on opposite sides of the testing issue. As the developers and testers

have lack of experience, there may arise this kind of situations.

Lack of Test Tools: As the system is a voluntary task, IIT management may have

the attitude that test tools are a luxury. Manual testing can be an overwhelming

task. Trying to test effectively without tools is like trying to dig a trench with a

spoon.

Lack of User Involvement: Users play one of the most critical roles in testing.

They make sure the software works from their perspective. It will be really hard

to involve the users of IIT official website in the testing process.

Not Enough Schedule or Budget for Testing: As this project is being developed

as a semester project, there is not provided enough time to conduct the test

processes. It will be a challenge to prioritize the plan to test the right things in

the given time.

Not Enough Budget for Testing: As this is not a commercial project, there lacks

budget for testing which may affect the testing process.

Rapid Change: There are continuously coming some changes in requirements of

the system which may affect in testing process.

10 | T e s t P l a n

Features to be tested

6. Features to be tested

The following is a list of the areas to be focused on during testing of the application.

Features Priority Description

Add album 3 To show the photos of different events of IIT

in an arranged order user can add an album

Modify album 3 Edit an existing album by adding or deleting

photos or changing the description of album

Add achievements 3 Different achievements of IIT will be listed

Add news/events 1 This will work as notice board of IIT

Modify news/events 1 Change any components of the existing

news or events

Upload picture 3 Upload photo in the album

Delete picture 3 Delete photo from the album

Create Program 1 Create program such as bachelor, masters

Modify Program 1 Edit an existing program

Create Semester 1 Create semesters for each program

Modify Semester 1 Edit an existing semester

Create Course 1 Create course under every semester

Modify Course 1 Edit an existing course

Add faculty member 1 Add faculties in the system



Modify faculty member 1 Edit information of any faculty

Create Batch 1 Add batch under a program

Modify Batch 1 Edit information of any batch

Create Student 1 Add students in the system

Modify Student 1 Edit information of any student

Create Club 3 Add clubs

Modify Club 3 Edit club information

Add Profile 1 Create profile of faculty, student, staff and

admin

Edit Profile 1 Change any information of profile of faculty,

student, staff and admin

Upload Document 1 Upload any document in the website

Download Document 1 Download any document in the website

Delete Document 1 Delete any document in the website

Maintain Attendance 1 Maintain student attendance

Add project/thesis 2 Add project or thesis information

Modify project/thesis 2 Change project or thesis information

Add Group 3 Create different groups of students or

faculties

Modify Group 3 Edit any information about groups



Add admission form 2 Create admission form for any program

Modify admission form 2 Edit any field of admission form

Submit admission form 2 Submit admission form by external user

Login 1 Login as authenticate user

Logout 1 Logout from the system

Change password 2 Change password by the user

Appropriate Error Message

Processing

1 It is important for admin as well as user

Technological Feature

Database

1 Access to database is frequently needed operation. So this technical feature should be tightly in control for management system.

Quality Features

Ensure the Email is

sent to the expected

receiver

1 This feature should strictly be managed to

ensure privacy and reliability

Authentication 1 Without authentication confidentiality and

integrity are not guaranteed.

Filtering 1 This feature is needed because some

messages need not be sent to all groups.

Proper information

update

1 Proper information update procedure should

work properly otherwise updated

information will not work for the system.


Features not to be tested

7. Features not to be tested The following is a list of the areas that will not be specifically addressed.

Features

Description

Registration

It needs not to be tested because registration will be done by admin manually.

Password Recovery

It can be done manually by admin. As there is a limited schedule we will skip this feature.

Change User Status

It will be done by admin manually, so this feature needs not to be tested.

Network Security Testing network security is out of our scope.

Process Overview

8. Process Overview

The following represents the overall flow of the testing process:

1. Identify the requirements to be tested. All test cases shall be derived using the current Program Specification.

2. Identify which particular test(s) will be used to test each module. 3. Review the test data and test cases to ensure that the unit has been thoroughly

verified and that the test data and test cases are adequate to verify proper operation of the unit.

4. Identify the expected results for each test. 5. Document the test case configuration, test data, and expected results. 6. Perform the test(s). 7. Document the test data, test cases, and test configuration used during the testing

process. This information shall be submitted via the Unit/System Test Report (STR).

8. Successful unit testing is required before the unit is eligible for component integration/system testing.

9. Unsuccessful testing requires a Bug Report Form to be generated. This document shall describe the test case, the problem encountered, its possible cause, and the sequence of events that led to the problem. It shall be used as a basis for later technical analysis.

10. Test documents and reports shall be submitted. Any specifications to be reviewed, revised, or updated shall be handled immediately.


Testing Process

9. Testing Process This is a generic diagram for following the testing process.

Figure: Test Process Flow

The diagram above outlines the Test Process approach that will be followed.

Organize Project: It involves creating a System Test Plan, Schedule & Test

Approach, and assigning responsibilities.

Design System Test: It involves identifying Test Cycles, Test Cases, Entrance &

Exit Criteria, Expected Results, etc. In general, test conditions, expected results

will be identified by the Test Team in conjunction with the Development Team.

The Test Team will then identify Test Cases and the Data required. The Test

conditions are derived from the Program Specifications Document.

Design Test Procedure: It includes setting up procedures such as Error

Management systems and Status reporting.

Build Test Environment: It includes requesting, building hardware, software

and data set-ups.

Execute System Tests: The tests identified in the Design Test Procedures will

be executed. All results will be documented and Bug Report Forms filled out

and given to the Development Team as necessary

Signoff: Signoff happens when all pre-defined exit criteria have been achieved.

a. Organize

Project

b. Design

System Test

c. Design/Build

Test Proc.

d. Organize

Project

e. Design/Build

Test Proc.

f. Signoff


Test Strategy

10. Test Strategy The testing will be done manually until the site is sufficiently stable to begin developing

automatic tests. The testing will cover the requirements for all of the different roles

participating in the site: guests, members, students, teachers, and administrators.

The following outlines the types of testing that will be done for unit, integration, and

system testing. While it includes what will be tested, the specific use cases that

determine how the testing is done will be detailed in the Test Design Document. The

template that will be used for designing use cases is shown in the following figure.

Tested By:

Date

Test Type

Test Case Number

Test Case Name

Test Case

Description

Specifications

Test ID

Scenario

Expected

Result

Actual

Result

Status

Procedural Steps

1

2

3

Figure: Test Case Template

An effective testing strategy includes automated, manual, and exploratory tests to efficiently reduce risk and tighten release cycles. Lacking of automated test software enforces the test manually. So the Tests come in several flavors:


Unit Testing:

Unit Testing is done at the source or code level for language-specific programming errors such as bad syntax, logic errors, or to test particular functions or code modules. The unit test cases shall be designed to test the validity of the programs correctness. This test will be performed by the developers.

(a) White Box Testing

In white box testing, the UI is bypassed. Inputs and outputs are tested directly at the

code level and the results are compared against specifications. This form of testing

ignores the function of the program under test and will focus only on its code and the

structure of that code.

(b) Black Box Testing

Black box testing typically involves running through every possible input to verify that

it results in the right outputs using the software as an end-user would. We have decided

to perform Equivalence Partitioning and Boundary Value Analysis testing for the

website.

(1) Equivalence Class Partitioning

In considering the inputs for our equivalence testing, the following types will be used:

Legal input values (Valid Input) – Test values within boundaries of the specification equivalence classes. This shall be input data the program expects and is programmed to transform into usable values.

Illegal input values (Invalid Input) – Test equivalence classes outside the boundaries of the specification. This shall be input data the program may be presented, but that will not produce any meaningful output.

Using these Valid and Invalid classes test engineer will generate test cases.

(2) Boundary Value Analysis

The acceptable range of values for this application was set by the development team. At

the time of testing developer will define the boundary value and generate test case for

performing the boundary value analysis.


Integration Testing

Integration tests exercise an entire subsystem and ensure that a set of components play nicely together.

System Testing

The goals of system testing are to detect faults that can only be exposed by testing the

entire integrated system or some major part of it. Generally, system testing is mainly

concerned with areas such as performance, security, validation, load, and configuration

sensitivity. But in our case well focus only on Performance and Load testing. We can

perform both of the testing using Visual Studio.

(a) Performance Testing

This test will be conducted to evaluate the fulfillment of a system with specified

performance requirements. It will be done using black-box testing method. And this will

be performed by:

Storing the maximum data in the file and trying to insert, and observe how the application will perform when it is out of boundary.

Deleting data and check if it follows the right sorting algorithm to sort the resulting data or output.

Trying to store new data and check if it over writes the existing once. Trying to load the data while they are already loaded.

(b) Load Testing

The test will perform after executing a performance test. This will help to develop the loading quality of the website. Tester will perform the test using visual studio and generate a performance graph.

Functional test

Functional tests verify end-to-end scenarios that your users will engage in.

User Interface Testing

User Interface (UI) testing verifies a user’s interaction with the software. The goal of UI testing is to ensure that the UI provides the user with the appropriate access and navigation through the functions of the target-of-test. In addition, UI testing ensures that the objects within the UI function as expected and conform to corporate or industry standards.

For the website, we will perform unit testing first. Because unit testing will ensure that the all components of the system is working properly or not. If a single unit not work properly the integration test is not necessary to perform because in the smallest component is not working well.


If the unit testing is work properly then we will perform integration test. Total system will be divided in some subsystem. And we will test that sub system work properly or not. If the integration test perform well then we will move to functional test as well as all other tests for total system is it work properly or not.

Item Pass/Fail Criteria

11. Item Pass/Fail Criteria The entrance criteria's for each phase of testing must be met before the next phase can

commence. Now the criteria’s for pass and fail are given below. These criteria are set

with the help of software requirements specification version 1.0

1. According to the given scenario the expected result need to take place then the

scenario will be considered as pass otherwise that criteria should be failed.

2. If an item tested 10 times, 9 times perfectly worked and single time do not work

properly then it will consider as fail case.

3. System crash will be considered as fail case.

4. After submitting a query in the system, if expected page won’t appear then it will be

considered as fail case.

Suspension Criteria

12. Suspension Criteria

Testing work is performed by the test team to ensure that all the functional activities are working well in the system properly. If some of these functions are not working properly in the system the further test procedure should not be continued to the next level. So here are some criteria’s for which we will be paused the test work for the website.

If sanity check failed.

If smoke test failed.

If interdepended modules are not working well.


Testing will only stop if the Web site Under Test (WUT) becomes

unavailable.

If the number or type of defects reaches a point where the follow on testing has no value, it makes no sense to continue the test; it just wasting resources.

Certain individual test cases may be suspended, skipped or reduced if prerequisite tests have previously failed e.g. usability testing may be skipped if a significant number of Web page navigational tests fail.

These criteria’s are to be used to suspend the testing activity resolved these criteria

specifying testing activities which must be redone when testing is resumed.

Test Deliverable

13. Test Deliverable The following documents will be generated as a result of these testing activities:

Master test plan (this document)

Individual test plans for each phase of the testing cycle

Test Design Specifications

Test log for each phase

Acceptance Test plan.

Unit test plan.

Screen Prototypes.

Test report.

Test scenario and expected result in an excel sheet.

System manual.


Remaining Test Tasks

14. Remaining Test Tasks

Task

Assigned To

Create Acceptance Test Plan

Project Manager, Clients

Create Integration Test Plan

Developers, Project Manager

Define Unit Test rules and Procedures

Developers, Project Manager

Define Turnover procedures for each level

Developers

Verify prototypes of Screens

Clients, Project Manager

Verify prototypes of Reports

Clients, Project Manager

Environmental Needs

15. Environmental Needs The following elements are required to support the overall testing effort at all levels

within the IIT official website project:

Access to the IIT official website

Access to the database

Access to the environments used by the IIT users

Systems functional structure created by Mind map


Use visual studio for performance and load testing.

Staffing and Training needs

16. Staffing and Training Needs This section outlines how to approach staffing and training the test roles for the project.

Staffing is fixed for the duration of this project. It is likely most of the staff will assume

some testing role.

The following roles are identified:

Project Manager: Responsible for managing the total implementation of the

Web site. This includes creating requirements, managing the vendor

relationship, overseeing the testing process.

Test Manager: Responsible for developing the master test plan, reviewing the

test deliverables, managing the test cycles, collecting metrics and reporting

status to the Project Manager, and recommending when testing is complete.

Test Engineer: Responsible for designing the tests, creating the test procedures,

creating the test data, executing tests, preparing incident reports, analyzing

incidents, writing automated test procedures, and reporting metrics to the test

manager.

The test manager and test engineers should be familiar with the Website development life cycle

methodology. This is a generic description of Staffing and Training needs because this

project is being developed by following a generic methodology. So, the name of

responsible persons for each task is not defined.


Responsibilities

17. Responsibilities Identify groups responsible for managing, designing, preparing, executing, witnessing,

checking and resolving that will help the whole team to deliver a quality full website.

Role Responsibility Candidate Timing Project Manager

Managing the total implementation Mr. A Start to end of the project

Test Manager Create Test plan Identify test data Execute test conditions and

mark-off results Prepare software error reports Administrate error

measurement system

Mr. X All, part-time

Test Planner Ensure Phase 1 is delivered to schedule and quality

Produce expected results Report progress at regular

status reporting meetings Manage individual test cycles

and resolve tester problems.

……….. ……...... ………..

All, part-time

Test Engineer Designing the tests Creating the test procedures Cresting the test data Executing tests Preparing Bug reports

………….. …………… ……………. …………..

Testing time

SQA Project Leader

Ensure delivered schedule and quality of the project

Regularly review testing progress

Manage risks issues relating to System Test Team

Provide resources necessary for completing system test

……………. All, part-time

Developer Ensure Unit Testing Review each module before

merging

…………. …………. ………….

Development time


Schedule

18. Schedule This section defines the following tasks.

Specify test milestones

Specify all item transmittal events

Estimate time required to do each testing task

Schedule all testing tasks and test milestones

For each testing resource, specify its periods of use.

Test Schedule:

Test Phase Responsible Person Time

Test Plan Creation Test Manager 1 Week

Test Specification Creation Test leads 2 Weeks

Test Spec. Team Review Project team 1 Week

Unit Testing Developer Developing time

Component Testing Testing team 1 Week

Integration Testing Testing Team 1 Week

Use Case Validation Testing Team 1 Week

User Interface Testing Testing Team 1 Week

Load Testing Testing Team 1 Week

Performance Testing Testing Team 1 Week

Release to Production Project Team 1 Week

This is the actual model for testing the whole project before delivering the project.

Approval

19. Approval The test plan will be approved by the whole team.

***The End***