Test plan on iit website

  • 4,738 views
Uploaded on

This is a master test plan on a web site.

This is a master test plan on a web site.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,738
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
257
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. IIT Official Website Software Test plan Institute of Information Technology University of Dhaka
  • 2. 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 1 |Test Plan
  • 3. 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 2 |Test Plan
  • 4. 3 |Test Plan
  • 5. 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. 4 |Test Plan
  • 6. 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. 5 |Test Plan
  • 7. 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. A major checkpoint or a sub-goal identified on the project or testing schedule. Milestone 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. A description of how testing will be conducted. Includes any issues that affect the effectiveness or efficiency of testing. Metrics that describe a situation in which testing will be completely or partially halted (temporarily). Strategy Suspension Criteria System Testing Test Item Test Deliverable Unit Testing White-Box Testing 6 A (relatively) comprehensive test undertaken to validate an entire system and its characteristics. Typically based upon the requirements and design of the system. A programmatic measure of something that will be tested (i.e. a program, requirement specification, version of an application, etc.). Any document, procedure, or other artifact created during the course of testing that's intended to be used and maintained. A level of test undertaken to validate a single unit of code. Typically conducted by the programmer who wrote the code. 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). |Test Plan
  • 8. 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:   Google Chrome  7 Mozilla Firefox Internet Explorer |Test Plan
  • 9. 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 club  Modify course  Create Profile  Add faculty member  Edit Profile  Modify faculty  Upload document member  Download document  Assign course  Delete document  Add Batch  Attendance  Modify Batch  Add project/thesis  Add Student  Add group  Modify Student  Create admission form  Add club 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:  8 The probability that the negative event will occur. |Test Plan
  • 10.  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. 9 |Test Plan
  • 11. 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 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 10 3 1 Add faculties in the system |Test Plan
  • 12. 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 11 3 Edit any information about groups |Test Plan
  • 13. 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 1 It is important for admin as well as user Processing 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 1 ensure privacy and reliability receiver Authentication This feature should strictly be managed to 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. 12 |Test Plan
  • 14. 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. It can be done manually by admin. As there is a limited schedule we will skip this feature. It will be done by admin manually, so this feature needs not to be tested. Testing network security is out of our scope. Password Recovery Change User Status Network Security 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. 13 |Test Plan
  • 15. Testing Process 9. Testing Process This is a generic diagram for following the testing process. b. Design System Test a. Organize Project c. Design/Build Test Proc. e. Design/Build f. Signoff Test Proc. d. Organize Project 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. 14 |Test Plan
  • 16. 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: 15 |Test Plan
  • 17. 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. 16 |Test Plan
  • 18. 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. 17 |Test Plan
  • 19. 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. 18 |Test Plan
  • 20.  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. 19 |Test Plan
  • 21. 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 database  Access to the environments used by the IIT users  20 Access to the IIT official website Systems functional structure created by Mind map |Test Plan
  • 22.  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. 21 |Test Plan
  • 23. 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 Project Manager Test Manager Responsibility Managing the total implementation      Test Planner     Test Engineer SQA Project Leader          Developer 22   Create Test plan Identify test data Execute test conditions and mark-off results Prepare software error reports Administrate error measurement system 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. Designing the tests Creating the test procedures Cresting the test data Executing tests Preparing Bug reports 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 Ensure Unit Testing Review each module before merging Candidate Timing Mr. A Start to end of the project Mr. X All, part-time ……….. ……...... ……….. All, part-time ………….. …………… ……………. ………….. Testing time ……………. All, part-time …………. …………. …………. Development time |Test Plan
  • 24. 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*** 23 |Test Plan