Test Plan<\/p>\n
\u00a0<\/p>\n
Version 1.0\u00a0\u00a0<\/p>\n
Prepared by:\u00a0<\/p>\n
Linus Wahome Kingori<\/p>\n
Marcus Vinicius Santos Nogueira<\/p>\n
Kamala keerthy Kola<\/p>\n
\u00a0<\/p>\n
\u00a0<\/p>\n
Supervised by:\u00a0<\/p>\n
Dr. Hitesh Gupta\u00a0<\/p>\n
December 2020\u00a0<\/p>\n
Table of Contents<\/p>\n
1. TEST PLAN IDENTIFIER 4<\/p>\n
2. INTRODUCTION 4<\/p>\n
2.1 OBJECTIVES 4<\/p>\n
2.2 DEFINITIONS 4<\/p>\n
3. TEST ITEMS 5<\/p>\n
4. APPROACH 5<\/p>\n
4.1 UNIT TESTING 6<\/p>\n
4.2 INTEGRATION TESTING 6<\/p>\n
5. TEST CASES 6<\/p>\n
Test case definitions 7<\/p>\n
5.1 TEST CASE 1 \u2013 General 8<\/p>\n
5.2 TEST CASE 2 \u2013 ADD BUS 9<\/p>\n
5.3 TEST CASE 3 \u2013 RESERVERVATION 9<\/p>\n
5.4 TEST CASE 4 \u2013 RESERVERVATION 10<\/p>\n
5.5 TEST CASE 5 \u2013 RESERVERVATION 11<\/p>\n
5.6 TEST CASE 6 \u2013 RESERVERVATION 12<\/p>\n
5.7 TEST CASE 7 \u2013 SHOW MENU 12<\/p>\n
5.8 TEST CASE 8 \u2013 SHOW MENU 13<\/p>\n
5.9 TEST CASE 9 \u2013 SHOW MENU 14<\/p>\n
5.10 TEST CASE 10 \u2013 SHOW MENU 14<\/p>\n
5.11 TEST CASE 11 \u2013 SHOW MENU 15<\/p>\n
5.12 TEST CASE 12 \u2013 BUSES AVAILABLE MENU 15<\/p>\n
5.13 TEST CASE 13 \u2013 BUSES AVAILABLE MENU 16<\/p>\n
5.14 TEST CASE 14 \u2013 BUSES AVAILABLE MENU 16<\/p>\n
5.15 TEST CASE 15 \u2013 EXIT MENU 17<\/p>\n
6. Test Execution 18<\/p>\n
BUG IMAGES 19<\/p>\n
TEST CASE 1 19<\/p>\n
TEST CASE 9 19<\/p>\n
TEST CASE 11 20<\/p>\n
TEST CASE 14 21<\/p>\n
7. TEST DELIVERABLES 21<\/p>\n
8. TEST PLAN APPROVAL 22<\/p>\n
1. TEST PLAN IDENTIFIER<\/p>\n
Information technology (IT) ticketing system<\/p>\n
2. INTRODUCTION<\/p>\n
The primary purpose of the test plan for the\u00a0Information technology (IT) ticketing system is to explain the testing details of the use cases of this system. The project test plan describes the scope, objectives, specify the approach taken to\u00a0testing this application and define the deliverables expected. The test plan for the system also indicates the personnel responsible for each task and also specifies the risks associated with the test plan.<\/p>\n
2.1 OBJECTIVES<\/p>\n
The principal objectives of the test plan for the IT ticketing system are as follows:<\/p>\n
To Define the scope of what will be tested. <\/p>\n
To identify the features that will be tested.<\/p>\n
To define all the activities necessary to prepare for and conduct the testing process on the System<\/p>\n
To Specify how the testing results will be evaluated. <\/p>\n
Organise the activities and timescales.<\/p>\n
To define the pass and fail criteria for each item that will be tested.<\/p>\n
To Estimate the risks to testing plan and how to mitigate them. <\/p>\n
Define the deliverables expected.<\/p>\n
To define any suspension criteria and resumption techniques<\/p>\n
2.2 DEFINITIONS<\/p>\n
Follow below some of the definitions and terms that are related to the test plan of the Bus ticket booking.<\/p>\n
Pass\/Fail criteria:\u00a0Rules and that are used to determine whether a software\u00a0item passes or fails a test.<\/p>\n
Anomaly:\u00a0Any condition that varies from expectations based on design documents, requirements specifications, standards etc. It is often used to find anomalies by testing the software.<\/p>\n
Test execution:\u00a0A collection of one or more test cases on the test of the environment.<\/p>\n
Test Item:\u00a0A software item that is an objective of testing.<\/p>\n
Test Plan:\u00a0A document describing what should be tested by whom, when, how, and why. It is based on scope, approach, resources defined during the Software Requirements Specifications (SRS) Process\u00a0<\/p>\n
Test Summary Report:\u00a0A document summarizing all process and outcomes that include the results and testing activities.\u00a0<\/p>\n
Testing:\u00a0The process of analysing and testing a software item to detect the differences\u00a0between the existing and required conditions.<\/p>\n
SRS: will allow for a complete understanding of what is needed for this system.\u00a0\u00a0<\/p>\n
Software Design Specification (SDS): The purpose of the Software Design Document (SDS) is to describe a system’s design that wants to ensure that the final output application meets all the end customer requirements specified at the beginning of the project. It is a description of the software components and sub-systems to be provided as part of the product. It contains specific information about the expected classes, functions, input, and outputs.<\/p>\n
TEST ITEMS<\/p>\n
This section of the test plan lists all the items of the Bus booking ticket System project that will be tested:<\/p>\n
Add Bus<\/p>\n
Make a reservation<\/p>\n
Show reservation<\/p>\n
Buses Available<\/p>\n
APPROACH<\/p>\n
Describes the overall approach for testing the Bus booking ticket. A test approach is the test strategy that defines how testing should be carried out. There are two techniques:\u00a0Proactive –\u00a0An approach in which the test design process is initiated as early as possible in order to find and fix the defects before the build is created and\u00a0Reactive –\u00a0An approach in which the testing is not started until after design and coding is completed.<\/p>\n
4.1 UNIT TESTING<\/p>\n
During the unit testing, every module will be tested trying to check for errors. We will try to discover the mistakes in the code of the Bus ticket online System. We want to isolate each part of the program and correct bugs. In the case of our application, all menus and the C++ functions will be tested. The main benefits for this this are:<\/p>\n
Unit testing\u00a0saves time and money<\/p>\n
Unit testing\u00a0helps gauge performance.\u00a0<\/p>\n
Unit testing\u00a0improves code coverage and reduce code complexity<\/p>\n
The disadvantages are for example it might not identify every errors.<\/p>\n
4.2 INTEGRATION TESTING<\/p>\n
In Integration Testing, the individual software modules are combined and tested as a whole unit. The integration testing generally follows unit testing where each module is tested as a separate unit. The main purpose of the integration testing is to test the functional and performance requirements on the major items of the project.<\/p>\n
All the modules of the project developed individually would be combined together and tested as a whole system in the integration testing.<\/p>\n
5. TEST CASES<\/p>\n
The following are the test cases for the Buses booking System:<\/p>\n
GENERAL<\/p>\n
Customer specified an invalid option in the main menu<\/p>\n
ADD BUS <\/p>\n
Admin try to add a bus without specifying a bus number, Drivers name, Arrival time, departure, from and to<\/p>\n
Reservation<\/p>\n
The customer tries to book a non-existent seat, For example, we have 32 seats available, and the customer tries to book seat 33.<\/p>\n
Check whether the user can book seat already booked.<\/p>\n
Check if the customer can book a ticket using an invalid bus number.<\/p>\n
User tries to Book a ticket without inform seat number, passenger name.<\/p>\n
Show menu. <\/p>\n
User tries to access informing a wrong bus number.<\/p>\n
User tries to access without informing a bus number.<\/p>\n
Check if the search result has the details like the availability of seats.<\/p>\n
Check if the user is getting the real-time results of the buses like all seats available and the seats already reserved.<\/p>\n
Check if the available seats are being visualized twice<\/p>\n
.<\/p>\n
Buses available<\/p>\n
Check whether the application is showing all information about the bus specified: Driver name, Arrival time, Departure time, From, To and bus number <\/p>\n
Check whether show all buses available <\/p>\n
Check whether all information about the buses is clear and well presented<\/p>\n
Exit<\/p>\n
Check if the customer or admin can leave the system.<\/p>\n
Test case definitions<\/p>\n
ID<\/p>\n
ID of the test case.<\/p>\n
TC-