Master Test Plan Assignment 2 - Amel94/ITC303-XCoders GitHub Wiki

MASTER TEST PLAN

VERSION INFORMATION Version Date Remarks Author 0.1 20/12/19 123 Pramodya de Silva

Introduction 5.3 Project and project objective Objective of this project is to plan and prepare for the projects implementation’s system supports to analyse existing threats and risks to the project. Resource Allocation system supports to control all the workload in a project 5.4 Objective of the master test plan The objective of the Master Test Plan (MTP) is to inform all who are involved in the test process about the approach, the activities, including the mutual relations and dependencies, and the (end) products to be delivered for the test project Resource Allocation system. The master test plan describes this approach, the activities and (end) products that need further elaboration in the other system test plans. These system test plans need to be abstracted from this master test plan. 1.1 Involved in creating the master test plan Name Function Responsibility Amel Testing Write MTP Pramodi Testing Review MTP pramodi Testing Approve MTP

2 Assignment formulation 5.5 Client The client is the party that gives the assignment for the creating of the MTP and the execution of the tests. 5.6 Supplier Supplier The supplier is the person responsible for creating the MTP and/or the execution of the test assignment. 5.7 Scope Projects Systems (incl. release or version) Functionality Conversions Administrative Organization (AO) procedures Test levels Test activities Interfaces.

2.1 Preconditions and assumptions Preconditions concern conditions that third parties like the client, the project or the users, impose to the test process and within which the test process must operate. The following demands are enforced:

Preconditions, The test project must be finished not later than determined date; The prevailing project plan is boundary for this master test plan and the execution of the test project is based on this

Assumptions are external circumstances or events that must occur to ensure the test process’ success, but that cannot be controlled by the test process. In other words, these are the requirements of the test process.

Assumptions, The line organizations are responsible for the execution of the following activities: Reviewing test specifications / test scripts, within the fixed period of days; Providing resources for UAT that are dedicated and prepared  The delivery planning of the project has to be tuned with, and where necessary adapted to, the sequence that is desired from the test project.  The documents identified as test basis need to be accepted by stakeholders (including the test team), before the test specification can be started.  Changes on baselined documents need to follow the formal change procedure.  The test environments are delivered on time and correctly working in conformity with the environment plan and specification.  Test specification for a test level will start no earlier than when the entrance criteria for it are met.  Test execution for a test level will start no earlier than when the entrance criteria for it are met 3 Documentation This chapter describes the documentation used in relation with the master test plan. The described documentation concerns a first inventory and will be elaborated, actualized and detailed at a later stage, during the separate test levels.

3.1 Basis for the master test plan

The following documents are used as basis for this master test plan.

Document name Version Date Author Assign the work for the employees 1 18/12/2019 Pramodya de silva Checking the progress of the project 2 20/12/2019 Pramodya de silva 3.2 Standards

The following conventions and standards are applied for this test plan.

Document name Version Date Author TMap 1 2019 T. Koomen, L. van der Aalst, B. Broekman en M. Vroon

3.3 Test basis The test basis contains the documentation that serves as basis for the tests that have to be executed. The overview below describes the documentation that is the starting point for testing.

Document name Version Date Author Functional or technical design 1 18/12/2019 Pramodya de Silva System architecture 2 20/12/2019 Pramodya de Silva Data models 3 21/12/2019 Pramodya de Silva User manuals 4 22/12/2019 Pramodya de Silva Old test ware 5 23/12 Pramodya de Silva AO procedures 6 23/12/2019 Pramodya de Silva 4 Test strategy The time available for testing is limited; not everything can be tested with equal thoroughness. This means that choices must be made regarding the depth of testing. Also, it is strived to divide test capacity as effective and efficient as possible over the total test project. This principle is the basis of the test strategy.

The test strategy is based on risks: a system must function in practice to an extent that no unacceptable risks for the organization arise from it. If the delivery of a system brings along many risks, thorough testing needs to be put in place; the opposite of the spectrum is also true: 'no risk, no test'.

The first step in determining the test strategy is the execution.

The test strategy is subsequently based on the results of the risk analyses. The test strategy lays down what, how and when (in which test level) is being tested and is focused in finding the most important defects as early as possible for the lowest costs. This can be summarized as testing with an optimal use of the available capacity and time. The test strategy is described in §4.2.

4.1 Product risk analyses The product risks are determined in cooperation with the client and the other parties involved. This product risk analyses (PRA) is comprised of two steps: • Make an inventory of the risks that are of interest • Classify the risks. During the risk assessment the test goals were also formulated. These can be found together with the corresponding characteristics in table below. Test goal Description Characteristic Bug detection It’s a short-term objective that requires a scrutinous approach which can be provided by manual software testing. functionality, performance, user-friendliness, suitability, Software quality and Reliability To maintain system quality and reliability we must keep bugs at low level. Functionality User Satisfaction

5 Approach In this chapter each test level in the test strategy (the what) will be translated to a concrete test

Test level Goal System Test Resources properly Allocated Functional Acceptance Test Number of quality Assurance techniques used Production Acceptance Test Probability of quality and functional errors. 5.1 Evaluation 5.2 The Functional Acceptance Test GOAL all the required functionality that's specified within its functional requirements. Short description Functional testing is a software testing process used within software development in which software is tested to ensure that it conforms with all requirements. Functional testing is a way of checking software to ensure that it has all the required functionality that's specified within its functional requirements.

5.3 Phasing per test level

In the Planning phase, the test manager formulates a coherent approach that is supported by the client to adequately execute the test assignment. This is laid down in the test plan. In the Control phase the activities in the test plan are executed, monitored, and adjusted if necessary. The Setting up and maintaining infrastructure phase aims to provide the required test infrastructure that is used in the various TMap phases and activities. The Preparation phase aims to have access to a test basis, agreed with the client of the test, of adequate quality to design the test cases. The tests are specified in the Specification phase and executed in the Execution phase. This provides insight into the quality of the test object. The test assignment is concluded in the Completion phase. This phase offers the opportunity to learn lessons from experiences gained in the project. Furthermore activities are executed to guarantee reuse of products.

The deliverables are:

Phase Product Comment Delivery Date Planning Master test plan 23/12/2019 Test plan for each test level

Management Risk report 23/12/2019

Setting up and maintenance infrastructure Detail specification test environment 23/12/2019

Preparation Report detail intake for each test level 23/12/2019

Specification Test script pretest 23/12/2019 Test script for each test level

Execution Defect log 23/12/2019 Status report Completion End report 23/12/2019 Release advice (for each test level)

5.4 Review plan List the deliverables that have to be reviewed by the stakeholders.  Master test plan  Test plan for each test level  End report  Defect log

Deliverable Authors Type review Reviewers Master Test paln Pramodya Report QA Test plan for each test level Amel Report QA End Report Amel Report QA

5.5 Entrance and exit criteria for each test level For the phase Specification and Execution, the following entrance criteria are defined:

Entrance criteria for Specification phase:

Entrance criteria for Execution phase:

The following exit criteria are defined for the FAT: User Acceptance Test For the phase Specification and Execution, the following entrance criteria are defined:

Entrance criteria for Specification phase:

Entrance criteria for Execution phase:

The following exit criteria are defined for the UAT:

5.6 Go/No go There will be a release advice written after the finishing of the total test project. This summarizes the results of the several test levels and, based on that, what risks are identified when the Resource allocation system, is deployed to production. This also details if the acceptance criteria for each test level are met.

Based on this release advice the stakeholders can take a Go/No decision.

For a Go there should be no open defects that have the impact that the system is no longer useable for the user organization or is not manageable by the functional and technical administrators.

The mentioned norms for defects that are preventing the system going into production is not measurable beforehand. However, the weight and impact of the defects shall be determined during the defect management process. This will be done by the test manager in close cooperation with the stakeholders. Defects that are preventing the system from going into production will be marked as such in the defects tracking system. They will be addressed in the decision process as described earlier.

Organization 5.8 Roles, tasks and responsibilities Describe for each role the tasks and the responsibilities.

Role Department / Name employee(s) # hours per week Period Description of tasks and responsibilities Test manager IT department 8 -Write MTP -Coordinate overall test process> Test coordinator IT department 10 -Write test plan -Coordinate test Tester IT department 10 -Make test specifications -Execute (re)tests Optional: Functional administrators

5.9 Structure of meetings Mention all types of meetings within the test project, the objective of the meeting, the frequency and who needs to be present.

Type Goal Frequency Who Project meeting Discuss overall project progress Weekly Project manager Test manager Progress meeting for each test level Discuss progress for each test level Weekly Test manager Testers defect triage Discuss and prioritize defects found during test Weekly Test manager – owns Technical lead Project Manager Business lead 5.7 Structure of reporting Mention all types of written communication.

Type Goal Frequency Who Risk report Gives insight in the recognized risks of the tests Ad-hoc Test team Release advice Gives advice about quality/risks of the implementation of the test object Once-only Project manager End report Gives insight in the evaluation of the test process and test object Once-only Project manager Progress report Gives insight in the progress of thee tests and quality/risks of the test object Weekly Test manager to key stakeholders Defect reports Gives insight to defects and their status’. Weekly Test manager to key stakeholders 5.8 Completion This describes the procedures for the completion process at the end of the project.

6 Infrastructure

An important starting point is that different test levels are executed in separate test environments, like a DTAP model. This separation is made to facilitate the different demands of the test levels; a performance test has different demands than a usability test. In a test project not only one environment has to be described, but multiple.

6.1 Test environments

Test level Environment Requirements From To ST Test data Testing data 12/11/2019 13/11/2019 FAT files Testing files 13/11/2019 15/11/2019 UAT files Testing Files 15/11/2019 17/11/2019

6.2 Test tools Test tools that have used in the test project, are tools to test services or to measure performance. And the costs and take this up in the budget as is part of the test project.

Test level Test tool Comment ST hardware software means of communication facilities for the build and use of files procedures Budget

6.3 Office setup It’s necessary to do parallel testing with many users. A specific office environment might need to be created for that. Availability of fax machine or printers can be written down here as well

Test level Components Comment ST printers FAT Fax machines

7 Management 5.10 Test process management The management of the test process can be divided into three parts: • Progress and expenditure of budget and time: the management of the planning and guarding of the progress in terms of time, resources and means. This has been arranged as followed • Quality indicators: the aim of testing is to provide information and advice on the risks and quality of the object to be tested. To be able to provide this information, quality indicators are registered. This has been arranged as followed • Test statistics: the test manager builds statistics based on the above information. Statistics can supply insight into the progress of the test process and quality of the test object, including any trends. This has been arranged as followed 7.1 Test infrastructure management • Procedure office setup • Procedure test tool • Procedure test environment

5.11 Test product management Test ware and test project documents External products like the test basis and object under test 7.2 Defects procedure The defects management has been arranged in conformity with the defect procedure that is described as it is used within the organization. For the registration and maintenance of defects the following tool is being used such as procedure test tool etc. The responsibility for the observance of this defect’s procedure lies with the defect administrator

8 Test process risks and countermeasures This chapter makes an inventory of the most important potential project risks for the testing of Resource Allocation System. By anticipating what possibly might occur, it’s possible to mitigate the risk by taking the appropriate countermeasures. The risks apply directly to the test process, or apply to risks that can be of direct consequence for the test project. Registration and monitoring of these risks continues after the MTP has been written, it is a continuous process.

The test manager is aware of these points and monitors the countermeasures. The countermeasures that can’t be taken within the test organization can be discussed and assigned owners during the project meeting. This will be recorded in the action list and is monitored during the project meeting.

9 Global Estimation & Planning

9.1 Estimation The estimation is as follows: The estimation divided in personal and infrastructural costs.

Test level Who P C I P S E C Totals Overall Test manager 5% 15% 15% 5% 10% 25% 25% 100%

ST Test coordinator 10% 10% 10% 5% 10% 25% 25% 95% Test specialists 20% 20% 20% 5% 10% 10% 15% 100%

FAT Test coordinator 10% 10% 10% 5% 10% 25% 25% 95% End users 20% 20% 20% 5% 10% 10% 15% 100% Test specialists 10% 10% 10% 5% 10% 25% 25% 95% 20% 20% 20% 5% 10% 10% 15% 100% UAT Test coordinator 10% 10% 10% 5% 10% 25% 25% 95% End users 20% 20% 20% 5% 10% 10% 15% 100% Test specialists 5% 15% 15% 5% 10% 25% 25% 100%

Totals:

Preferably make a foundation for the estimation, elaborating on the used estimation technique and the basis for the estimation, for example the estimation of the development team. Describe, as much as possible, for each test level the planning for the infrastructure.

This table is an example. Attention! All resources mentioned with the test approach need to be listed here.

This estimation will be divided in sub activities in the detail test plans for each test level. 9.2 Planning The global planning has to consist at least of the following parts:  The activities to be executed (phases for each test level)  Relations with and dependencies with other activities (inside or outside the test process and between the test levels)  The amount of time for each test level  Needed and available resources (organization and infrastructure)

The activities to be executed are in the table below.

Activity Name Start Date End Date Duration Relations Planning pramodi 10/11/2019 10/12/2019 Month 9.3 Milestones The milestones of the test process of Resource Allocation system are detailed in the table below.

Mile stone description Date resource allocation is a plan for using available resources, for example human resources, especially in the near term, to achieve goals for the future. It is the process of allocating scarce resources among the various projects or business units. 10/01/2019