test plan on iit website
DESCRIPTION
This is a master test plan on a web site.TRANSCRIPT
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
11 | T e s t P l a n
Features Priority Description
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
12 | T e s t P l a n
Features Priority Description
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.
13 | T e s t P l a n
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.
14 | T e s t P l a n
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
15 | T e s t P l a n
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:
16 | T e s t P l a n
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.
17 | T e s t P l a n
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.
18 | T e s t P l a n
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.
19 | T e s t P l a n
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.
20 | T e s t P l a n
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
21 | T e s t P l a n
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.
22 | T e s t P l a n
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
23 | T e s t P l a n
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***