Determine what software will be implemented
Purpose:
|
To understand the main deliverables of the development team in the forthcoming schedule.
|
Using the Iteration Plan and other available sources, identify the individual software items that the
development team plan to produce for the forthcoming Iteration. Where the development effort is distributed
to teams in various locations, you may need to discuss the development plans with each team directly. Check
to see whether any development is subcontracted and use whatever channels are available to you to gather
details of the subcontractors development effort.
As well as new software, also note changes to infrastructure and shared components. These changes may
effect other dependent or associated software elements produced in previous development cycles, making it
necessary to test the effect of these changes on those elements. For similar reasons, you should identify
any changes and additions to third-party components that the development effort intends to make use of.
This includes shared components, base or common code libraries, GUI widgets, persistence utilities etc.
Review the the software architecture to determine what mechanism are in use that may be effected by
third-party component changes.
|
Identify candidate system elements to be tested
Purpose:
|
To identify target items that the testing effort should exercise.
|
For each identified test motivator, examine the list of software items to delivered as part this
development cycle. Make an initial list that excludes any items that cannot be justified as useful in terms
of satisfying the test motivators. Remember to include commercially-available software as well as that to be developed
directly by the project development team.
You will also need to consider what impact the various target deployment environments will have on the
elements to be tested. Your list of candidate system elements should be expanded to include both the
software being developed and the candidate elements of the target environment. These elements will include
hardware devices, device-driver software, operating systems, network and communications software,
third-party base software components (e.g. eMail client software, Internet Browsers, etc.). They also include various
configurations and settings related to the possible combinations of all these elements.
Where you have identified important target deployment environments, you should consider recording this
information by creating or updating one or more outlined Test Environment Configurations; this outline
should provide a name, brief description and enumerate the main requirements or features of the
configuration. Avoid spending a lot of time on these outlines; the list of requirements and features will
be subsequently detailed in Task: Define Test Environment Configurations.
|
Refine the candidate list of target items
Purpose:
|
To eliminate unnecessary targets from-and add missing elements to-the test effort work
plan.
|
Using the evaluation mission and scope of the test effort agreed with the evaluation stakeholders, examine
the list of target items and identify items that do not satisfy the evaluation mission and are obviously
out of the test effort scope.
As an opposing check, critically examine the items again and challenge whether the evaluation mission and
test effort scope will really be satisfied by the refined list of target items. It may be necessary to add
additional elements to the list of target items to ensure appropriate scope and the ability to achieve the
evaluation mission.
|
Define the list of target items
Purpose:
|
To communicate the decisions made about the target test items for the forthcoming work.
|
Now that you've decided on the target test items, you need to communicate your choices to the test team and
other stakeholders in the test effort. Arguably the most common method is to document the decisions about
the target items in the Iteration Test Plan.
An alternative is to simply record this information in some form of table or spreadsheet and make use of it
to govern work and responsibility assignment. During test implementation and execution individual testers
will make use of this information to make tactical decisions regarding the specific tests to implement, and
what test results to capture in relation to these target items.
|
Evaluate and verify your results
Purpose:
|
To verify that the task has been completed appropriately and that the resulting work products
are acceptable.
|
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.
|
|