http://www.coleyconsulting.co.uk/IEEE829.htm

or 

http://www.webopedia.com/TERM/I/IEEE_829.html

or 

http://www.nao.org.uk/intosai/edp/intoit_articles/19_12_SPAC
EDIRT.pdf  ( Good one )

check these sites, u get answer, ok ....

 bye

IEEE 829 - For Software Test Documentation..

IEEE 829: Institute of Electronics And Electrical 
Engineering.
when we write test cases or write test plan document we 
follow ieee format.

The ‘Standard for Software Test Documentation’ (IEEE
829) describes the content of test design specifications 
(containing test conditions) and test case
specifications.

IEEE stands for inistitute of electronics and electrical 
engineering and 829 is the number given by IEEE 
organization for TESTING

IEEE stands for inistitute of electrical and electronics
engineering
829 stands for Software Test Documentaton

IEEE 829-1998, also known as the 829 Standard for Software 
Test Documentation, is an IEEE standard that specifies the 
form of a set of documents for use in eight defined stages 
of software testing, each stage potentially producing its 
own separate type of document. The standard specifies the 
format of these documents but does not stipulate whether 
they all must be produced, nor does it include any criteria 
regarding adequate content for these documents. 

Test Plan: a management planning document that shows: 
How the testing will be done (including SUT 
configurations). 
Who will do it 
What will be tested 
How long it will take (although this may vary, depending 
upon resource availability). 
What the test coverage will be, i.e. what quality level is 
required 
Test Design Specification: detailing test conditions and 
the expected results as well as test pass criteria. 
Test Case Specification: specifying the test data for use 
in running the test conditions identified in the Test 
Design Specification 
Test Procedure Specification: detailing how to run each 
test, including any set-up preconditions and the steps that 
need to be followed 
Test Item Transmittal Report: reporting on when tested 
software components have progressed from one stage of 
testing to the next 
Test Log: recording which tests cases were run, who ran 
them, in what order, and whether each test passed or failed 
Test Incident Report: detailing, for any test that failed, 
the actual versus expected result, and other information 
intended to throw light on why a test has failed. This 
document is deliberately named as an incident report, and 
not a fault report. The reason is that a discrepancy 
between expected and actual results can occur for a number 
of reasons other than a fault in the system. These include 
the expected results being wrong, the test being run 
wrongly, or inconsistency in the requirements meaning that 
more than one interpretation could be made. The report 
consists of all details of the incident such as actual and 
expected results, when it failed, and any supporting 
evidence that will help in its resolution. The report will 
also include, if possible, an assessment of the impact of 
an incident upon testing. 
Test Summary Report: A management report providing any 
important information uncovered by the tests accomplished, 
and including assessments of the quality of the testing 
effort, the quality of the software system under test, and 
statistics derived from Incident Reports. The report also 
records what testing was done and how long it took, in 
order to improve any future test planning. This final 
document is used to indicate whether the software system 
under test is fit for purpose according to whether or not 
it has met acceptance criteria defined by project 
stakeholders.