This project is read-only.

Specify tests and starting points

Specification Phase.

During the Specification phase, the required tests and starting points are specified. The aim is to have as much as possible prepared, in order to be able to run the test as quickly as possible when the developers deliver the test object.

This phase begins when the testability review has been carried out on the test basis and the defects in it have been processed as far as possible. The test specification runs in parallel with the completion of the software (or parameterization, in the case of packages).


The following preconditions should be met before the Specification phase can be started:
  • The test basis is available and placed under configuration management.
  • Defects from the testability review have been processed.


specification phase.png
  • 1_1.png Creating test specification. The creation of the test specifications per test unit.
  • 2_1.png Defining central starting point(s). The defining of one or more central starting points from which the testers can obtain data for their test specifications.
  • 3_1.png Specifying the test object intake. The preparation of the intake of the test object so that testing can start as soon as possible after delivery of the test object.

Exit Criteria

check-TMap.gif Approved test plan

Method of operation

  • During the Specification phase, the testers specify the required tests per test unit. This is done by creating checklists or specifying test cases on the basis of the allocated test design techniques.

msdnplanning an iteration.png
image from the documentation about VSTS 2010 on MSDN,

During the planning phase of the project, also called iteration 0 first blue piece, user stories are collected / brainstormed / defined /… in VSTS this information is collected in the new work item type ‘user story’ image below.
TMap userstory.png

During the planning of the iteration <strike>developers</strike> the team start to breakdown the user stories which are selected for that iteration in implementation tasks. Within VSTS this is done in the implementation tab. The new 2010 functionality of hierarchies between work items is used for this.

TMap link userstory.png

Another task also executed during this phase is the creation of test cases. Within the TMap methodology this is described in the planning phase. Where you create the test plan for that iteration, based on the risk class see user story work item and discussion with the customer the necessary test techniques are allocated for the user story and functional area.&#160; See the initial work items for iteration 1 in the image below, added during the unfolding of the TMap process template.

TMaP testcoordidator querie.png

So, not only the implementation tasks needs to be determined also the test tasks needs to be allocated during the planning phase of an iteration. These test tasks are specific to testers like ‘create test cases for area …. based on the test technique &lt;… decide based on risk and customer contact&gt;
List of different test techniques…
  • Data combination test (DCoT)
  • Data cycle test (DCyT)
  • Decision table test (DTT)
  • Elementary comparison test (ECT)
  • Error guessing (EG)
  • Error testing (ET)
  • Process cycle test (PCT)
  • Real life test (RLT)
  • Semantic test (SEM)
  • Syntactic test (SYN)
  • Use case test (UCT)

So, just like the implementation tasks also the test tasks are a link type, have hierarchy with, the user story. this is TMap process template specific

Tmap testworkitem linking.png

We end up with a list of tasks for a user story, implementation tasks and test tasks… testers and developers are going to execute these tasks together in parallel, during the iteration we have: implemented sources for the user story and test cases which are ready for execution. This user story is finished when: every implementation task is fulfilled, all test cases are successful executed and … the tester hasn’t got any open tasks, so all test cases are created.

When giving the tester/ the team a place where they can record their testing tasks, testing is really going to be a first class citizen of the lifecycle. beside this benefit the connection between test activities, risk, user story and test cases gives a great opportunity for reports based on test effort, risks and implementation, later on more on this…

With this this lightweight addition to the user story work item we got a closer to several Agile Testing key characteristics, for example:
  • Customer involvement in writing tests. –&gt; just like the developers, testers breakdown there work discussing it with the customer
  • An iteration is ready when the tests succeed. –&gt; and all tests are created..!

Last edited Nov 7, 2009 at 6:45 AM by ClemensReijnen, version 4


No comments yet.