Understand iteration objectives
To gain an initial understanding of the scope of and objectives for the iteration plan.
Examine the iteration plan, and identify the scope and objectives of the plan.
It's 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
To understanding the expectations of stakeholders for the scope of the evaluation effort.
The mission is the governing principal 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
To gain input and feedback from stakeholders for the objectives and scope of the test effort.
It's not a terribly useful practice to consider objectives and scope in isolation from the rest of the project team.
RUP advocates 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, 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
interview with each stakeholder. There are good and bad points for each approach: choose the format that best suits you
needs in the context of the current project environment.
Formulate mission statement
To clearly identify the essence of the testing focus for the current Iteration.
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 "do testing": 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. Don't 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 some ideas for mission statements 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)
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 won't 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 we recommend choosing or reconsidering your Evaluation Mission in each iteration: it's
natural for the mission to alter over time based on the context of the current work effort.
Identify test deliverables
To call out the value that will be received from the testing work effort.
Certain work products are deliverables 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. Don't list all 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 an proactive role in encouraging the deliverables to be kept useful and manageable.
Gain stakeholder agreement
To negotiate with all stakeholders to gain mutual agreement on the most appropriate mission for the
In a similar manner to the earlier step Present options to stakeholders
, you should
obtain agreement from those same stakeholders that the Evaluation Mission and its associated supporting aspects are
appropriate for the Iteration.
Again, give thought to the appropriate format for presenting the mission and gaining required approvals. Choose the
format that best suits you needs in the context of the current project environment..
Evaluate and verify your results
To verify that the task has been completed appropriately and that the resulting work products are
Now that you have completed the work, it is beneficial to verify that the work was of sufficient value, and that you
did not simply consume vast quantities of paper. You should evaluate whether your work is of appropriate quality, and
that it is complete enough to be useful to those team members who will make subsequent use of it as input to their
work. Where possible, use the checklists provided in RUP to verify that quality and completeness are "good enough".
Have the people performing the downstream tasks that rely on your work as input take part in reviewing your interim
work. Do this while you still have time available to take action to address their concerns. You should also evaluate
your work against the key input work products to make sure you have represented them accurately and sufficiently. It
may be useful to have the author of the input work product review your work on this basis.
Try to remember that that RUP is an iterative delivery process and that in many cases work products evolve over time.
As such, it is not usually necessary-and is often counterproductive-to fully-form a work product that will only be
partially used or will not be used at all in immediately subsequent work. This is because there is a high probability
that the situation surrounding the work product will change-and the assumptions made when the work product was created
proven incorrect-before the work product is used, resulting in wasted effort and costly rework. Also avoid the trap of
spending too many cycles on presentation to the detriment of content value. In project environments where presentation
has importance and economic value as a project deliverable, you might want to consider using an administrative resource
to perform presentation tasks.