Examine the software architecture and its target environments
Purpose:
|
To gain an understanding of the software architecture and its relationship to the target
deployment environments.
|
To perform this task within the appropriate context, it is important to have a good understanding of
the software being developed, its architecture and the key mechanisms and features that it will support.
Examine the available documentation for the software architecture to gain an initial understanding and
supplement this with interviews or discussions with the software architect as required. Consider the impact
that each target deployment environment might have on this information and note any important findings you
think may be relevant to the test effort.
|
Identify candidate mechanisms for test
Purpose:
|
To identify the potential test mechanisms that the testing approach will require.
|
Using your knowledge of the software architecture and its target environments, examine the information
provided in the test approach. Consider the key technical aspects of the approach and assemble a list of
candidate mechanisms that will be needed to support it. Here is a partial list of common mechanisms you
should consider as candidates; persistence, concurrency, distribution, communication, security, transaction
management, recovery, error detection handling & reporting, and process control & synchronization.
Note that these mechanisms often apply to both manual and automated test efforts, although a specific
mechanism may have more or less relevance to manual or automated testing. Also note that even where the
same mechanism is required for both manual and automated test efforts, the characteristics of the
implemented solution will usually differ.
|
Inventory the existing test mechanisms
Purpose:
|
To identify opportunities to reuse existing implementations for the candidate mechanisms and
identify which additional implementations will need to be developed.
|
Examine the available test tools and existing test implementations and create an inventory of mechanisms
that have one or more existing solutions. While this step is more obviously relevant in terms of the
automated test effort, there are some equivalent considerations for the manual test effort.
Sub-topics:
Start by compiling a list of the tools available to you or that you plan to purchase. Remember that
automation tools take many forms and your list will usually include more than the automated test
implementation and execution tools. For each tool, examine the mechanisms provided by the tool. For
example, does the scripting tool you plan to use provide its own data persistency mechanism, and if so, is
it appropriate for your needs or will you need to supplement it? Other questions might include; Does the
execution tool allow concurrent execution of test scripts on multiple host client machines? Does the
execution tool allow distribution of scripts from a central master machine to multiple host client
machines?
Where existing test automation implementations are available, there will be additional mechanisms to
inventory. Some aspects of these implementations will extend or supplement the basic mechanisms provided by
the tools to make them more useful. Other aspects will offer implementations for additional mechanisms not
provided in the base tool.
At a basic level, this will involve reviewing the test guidelines that exist for test implementation and
execution. You should look for existing process solutions for issues such as concurrency-how testers can
share data sets, especially existing data beds without adversely affecting each other; distribution-if the
test team is distributed, what solutions are available to coordinate the separate test efforts.
|
Define the test mechanisms you will use
Purpose:
|
To communicate the decisions made about the required test mechanisms.
|
Now that you've decided on the test mechanisms required, you need to communicate your choices to the test
team and other stakeholders in the test effort. We recommend you document the decisions about the test
mechanisms required for automation as part of the the Test Automation Architecture documentation, and those
that relate to manual testing as part of the Test Guidelines.
As an alternative to formal documentation, you might choose to simply record this information as a set of
informal architecture and process notes accompanied by some explanatory diagrams, possibly retained on a
white-board. During test implementation and execution individual testers will make use of this information
to make tactical decisions.
Where you have identified the potential requirement for special test interfaces that will need to be built
into the software being developed, you should consider recording this requirement by creating one or more
outlined Test Interface Specifications; this outline should provide a name, brief description and enumerate
the main test interface requirements or features. Avoid spending a lot of time on these outlines; the list
of requirements and features will be subsequently detailed in Task: Define Testability Elements.
|
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.
|
|