Referencing Styles : Open The purpose of the Master Test Plan (MTP) is to provide an overall test planning and test management document for multiple levels of test (either within one project or across multiple projects). In view of the software requirements and the project's (umbrella) quality assurance planning, master test planning as an activity comprises selecting the constituent parts of the project’s test effort; setting the objectives for each part; setting the division of labour (time, resources) and the interrelationships between the parts; identifying the risks, assumptions, and standards of workmanship to be considered and accounted for by the parts; defining the test effort's controls; and confirming the applicable objectives set by quality assurance planning. The Master Test Plan is a governing document for all detailed or ‘Level’ Plans. Required sections for the Assessment task are: 8.1 (MTP Section 1) Introduction Introduce the following subordinate sections. This section identifies the document and places it in context of the project-specific lifecycle. It is in this section that the entire test effort is described, including the test organization, the test schedule, and the integrity schema. A summary of required resources, responsibilities, and tools and techniques may also be included in this section. 8.1.2 (MTP Section 1.2) Scope Overview Describe the purpose, goals, and scope of the system/software test effort. Describe the inclusions, exclusions, and assumptions/limitations. Approach Describe your test approach - ensure you address your test strategy. The test approach identifies the rationale for testing or not testing, and it identifies the rationale for the selected order of testing. The test approach will identify the types of testing to be done (by test Domain) for each of the different level plans. 8.1.4 (MTP Section 1.4) System overview and key features Describe the mission or business purpose of the system or software product under test (or reference where the information can be found, e.g., in a system definition document, such as a Concept of Operations). Describe the key features of the system or software under test [or reference where the information can be found, e.g., in a requirements document or COTS documentation]. 8.1.5 (MTP Section 1.5) Test overview Describe the test organization, test schedule, integrity level scheme, test resources, responsibilities, tools, techniques, and methods necessary to perform the testing. 8.1.5.1 (MTP Section 1.5.1) Organization Describe the relationship of the test processes to other processes such as development, project management, quality assurance, and configuration management. Include the lines of communication within the testing organization(s), the authority for resolving issues raised by the testing tasks, and the authority for approving test products and processes. This may include (but should not be limited to) a visual representation, e.g., an organization chart. 8.1.5.2 (MTP Section 1.5.2) Master test schedule Describe the test activities within the project life cycle and milestones. Summarize the overall schedule of the testing tasks, identifying where task results feed back to the development, organizational, and supporting processes (e.g., quality assurance and configuration management). Describe the task iteration policy for the re-execution of test tasks and any dependencies. 8.1.5.4 (MTP Section 1.5.4) Resources summary Summarize the test resources, including staffing, facilities, tools, and special procedural requirements (e.g., security, access rights, and documentation control). 8.1.5.5 (MTP Section 1.5.5) Responsibilities Provide an overview of the organizational content topic(s) and responsibilities for testing tasks. Identify organizational components and their primary (they are the task leader) and secondary (they are not the leader, but providing support) test-related responsibilities. 8.1.5.6 (MTP Section 1.5.6) Tools, techniques, methods, and metrics Describe documents, hardware and software, test tools, techniques, methods, and test environment to be used in the test process. Describe the techniques that will be used to identify and capture reusable testware. Include information regarding acquisition, training, support, and qualification for each tool, technology, and method. Document the metrics to be used by the test effort, and describe how these metrics support the test objectives. 8.2 (MTP Section 2) Details of the Master Test Plan Introduce the following subordinate sections. This section describes the test processes, test documentation requirements, and test reporting requirements for the entire test effort. 8.2.1 (MTP Section 2.1) Test processes including definition of test levels Identify test activities and tasks to be performed for each of the test phases and document the test activities and tasks for each. There may be a different number of Level Test Plans used. Some examples of possible test levels include unit, security, UAT, usability, performance, stress, System Integration Testing, Disaster recovery, Implementation and regression. In this section you must describe which Level Test phases have been select and the reasoning behind each. Describe the sequence and duration of each Level phase and any special considerations included in your plan. You are required to build a Master Test Plan Report using IEEE829 extract in Appendix 2. Your report will describe which test phases will be used, which resources will be used in each phase and your approach to testing in each phase. Ensure you include assumptions, constraints and anything else that is relevant to the execution of your plan. When answering question 1 take the following into account… 1. The Rainbow Company has selected hosted service which claims to meet all of their requirements – there is no software development required, however the system must be configured for the Rainbow company and tested to ensure it meets the Rainbow company requirements. 2. The solution is entirely web based – all functions are carried out through a web browser. 3. Rainbow has a ‘bring your own device’ policy - all of your staff have devices, Internet access and web browsers. 4. You have a 25 working days to complete all tests. 5. Configuration of the system will take 2 working days. This includes the collection of information from the business and is NOT part of your 25 day timeframe. 6. Ensure you explain your decisions for the time allowed and sequence for each test phase, including your test approach, contingency and resource usage. 7. The following resources are available full time for the 25 days period – do not use resources unless they are necessary for the plan and ensure you identify which resources are required for each phase. a. 2 senior ICT testers – available for 25 days b. 3 junior ICT business analysts – available for 25 days c. 1 ICT security staff for 2 working days d. 1 ICT network staff available for 2 working days e. 1 ICT server ops staff available for 3 working days f. 2 ICT service desk staff available for a total of 10 working days (i.e. 5 days per person). g. 2 business managers available for 5 working days h. 3 business office staff available for 15 working days 8. The test tools you have are: a. Jira as your defect registration tool – all staff are trained and use this on a regular basis b. Selenium for automated browser tests – it takes 2 hours to set up a functional test with variable data; your senior testers are the only people trained to do this work c. An in-house comparison tool to compare test results (this is your primary regression test tool) d. The project will be managed using Microsoft Project Plans by Project Manager from your PMO.Question 2 When preparing your business case for a Collaborative Lifecycle (CLC) tool to improve testing and quality outcomes taking into account the following information…  You are the Solution Development Manager AND Test Manager (both sets of responsibilities and resources are yours). The Service Desk, Server Operations, DBA, Networking and other ICT resources are managed by other people.  There are a lot of projects and consequently a lot of test work lined up for the next 4 to 6 years – some of the projects are in-house builds others are acquisitions.  You currently operate a PMO and waterfall process but will be migrating to Agile over the next 6 to 9 months.  The current track record for ICT project delivery is very poor. Just over 30% of projects are a complete disaster; about 20% meet business expectations and the other 50% are usable but do not meet business need and often need tailoring or support. As a consequence the relationship between the business and ICT is very low.  The last project went live a few weeks ago and was a success - the business is happier (but still not trusting of ICT). There is a 2 month gap before the next project starts – testing is scheduled to comments 6 weeks after that.  Your resources (including managers) consist of the follows: 30 developers (avg cost of employment to the business is $150k each) 10 testers (avg cost of employment to the business is $90k each) 8 Business Analysts (avg cost of employment to the business is $125k each)  The level of capability and technical skills varies within each group but it is fair to say that 25% do not have the right level of skills and overall 5% consistently under perform.  The cost to hire a new person is 30% of the annual salary  The cost of redundancy is 100% of the annual salary  You have determined that with a CLM (Collaborative Lifecycle Management) system in place you can transition to Agile in the next 6 to 9 months which will change the way ICT works dramatically – not just Development and Testing, but the PMO and service delivery. For Test and Dev you estimate you need no more than 5 agile teams with a maximum of 8 people per team to delivery all of the projects (your estimate includes 15% spare capacity).  The only constraint on the selected solution is your cost justification. It is for you to decide which product(s) you select, how they are licensed and run etc and you must then justify the decision on the basis of costs and benefits. All of your costs and benefits must be realistic and include acquisition, training, on-going licenses and support costs.  The business ROI for projects is 2 years – that is, savings must outstrip costs within 2 years; projects that have a faster ROI are more likely to be approved