Task Descriptor: Agree on the Testing Mission |
This task focuses on finding the right balance between the available testing resources and the objectives for the iteration.
Based on Method Task: Agree on the Testing Mission
Relationships
Roles | Primary: Test Manager | Additional: | Assisting:
Inputs | Mandatory: [Project Definition and Scope] [Project Risk] | Optional: [Technical Architecture] Test Plan | External: None
Outputs | Test Plan
Steps
Understand Iteration Objectives
Examine the iteration plan, and identify the scope and objectives of the plan. It is useful to supplement this examination with informal discussions with key project staff (such as the project manager, software architect, and customer sponsor). These meetings will often highlight concerns more explicitly than documented in the plan. Attending iteration kickoff meetings also provides useful information.
Investigate Options for the Scope of the Assessment Effort
The mission is the governing principle that guides the test effort during a given time period. Testing resources are typically limited, so the challenge is to balance given testing resource constraints with the quality validation needs of the software development effort. Gain an initial understanding at a strategic level of the expectations of the software development team. You should mainly be concerned with the expectations of the project manager, software architect, and lead system analysts.
Present Options to Stakeholders
it is not a terribly useful practice to consider objectives and scope in isolation from the rest of the project team. Better is team ownership of product quality, and as such you should include relevant stakeholders from the rest of the project team when deciding what testing is important. You should consider team members that fill the following roles as important stakeholders: project manager, architect, system analyst, and integrator. In some cases, the presentation format will suit being formal, with the stakeholders convening as a review board and requiring significant preparation in advance. In other cases, "brown-bag lunches" may be appropriate, or individual interviews with each stakeholder. There are good and bad points for each approach: choose the format that best suits your needs in the context of the current project environment.
Formulate Mission Statement
Mission statements are helpful in providing focus to a team, especially in situations where the team is faced with many possible choices. Test teams without an evaluation mission often consider that they simply test: this provides little guidance when difficult choices must be made regarding the best focus for testing within time or resource constraints. A mission statement distills the essence of the current work objective, and provides a mantra to keep the team focused on the right things. Formulate a mission statement that can be used by the test team. Do not make it too complex or incorporate too many conflicting ideas: The best mission statements are simple, short and sweet; and, in most situations where a decision needs to be made between possible options, the mission will make it obvious what choice the team should make. Here are some ideas for mission statements that you might adopt for a given iteration: Find as many bugs as possible Find important problems fast Assess perceived quality risks Advise about perceived project risks Advise about perceived quality Certify a standard Verify a specification (requirements, design, or product claims) Satisfy stakeholders Fulfill process mandates Looking through this list, it should occur to you that many missions are mutually exclusive. For example, if my mission is to "find important problems fast", I likely will not be able to "verify a specification": To successfully achieve one mission often negates other possible missions, and requires a different supporting test approach. Test teams that try to satisfy too many evaluation missions often get into trouble, encountering ongoing conflict in their work. Note also that you can choose or reconsider your evaluation mission in each iteration: it is natural for the mission to alter over time, based on the context of the current work effort.
Identify Test Deliverables
Certain work products are deliverables that are important to one or more stakeholders. Other work products are necessary parts of the test effort and, while important to the test team, they are of little interest to those same stakeholders. Give some thought to the minimal set of useful deliverables for the test effort. Do not list all of the work products; only list those that give direct, tangible benefit to a stakeholder, and those by which you want the success of the test effort to be measured. You might need to adjust your initial list to accommodate the needs of the stakeholders, but you will need to take a proactive role in encouraging the deliverables to be kept useful and manageable.
Gain Stakeholder Agreement
In a similar manner to the earlier steps, you should obtain agreement from those same stakeholders that the evaluation mission and its associated supporting aspects are appropriate for this iteration. Again, give thought to the appropriate format for presenting the mission and gaining required approvals. Choose the format that best suits your needs in the context of the current project environment.
Properties
Predecessor | Identify Test Motivators
Multiple Occurrences |
Event Driven |
Ongoing |
Optional |
Planned |
Repeatable |