Task: Agree on the Testing Mission
This task focuses on finding the right balance between the available testing resources and the objectives for the iteration.
Purpose
The purpose of this task is to:
  • Negotiate the most effective use of testing resources for each iteration
  • Agree on an appropriate and achievable set of objectives and deliverables for the iteration
Relationships
RolesMain: Additional: Assisting:
InputsMandatory: Optional: External:
  • None
Outputs
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
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable