Test Specification v.s. Test Cases

3 Comments

1. kevin
   Posted September 5, 2008 at 3:32 am | Permalink

   Generally you needn’t to include the detailed steps in a test specification, which is mostly like a plan, just to indicate the points to be tested for a product. e.g. Test the bolder values for the login area, regression a feature when testing the integration of a new feature. It means that test specification is more like a test plan.

   Test case is the approach for test specification and it should be detailed and executable.

   However these principles may be a little bit different among the custom of countries. You may check the template which are available for them to get the idea in your company.

   [Reply]

2. linuxcity
   Posted September 5, 2008 at 9:33 am | Permalink

   Thanks, Kevin. You should come here and be the Team Leader.

   [Reply]

3. delphi1000
   Posted September 10, 2008 at 5:37 am | Permalink

   give you a example for test specification:
   Test Specification

   Case No. 7.6.3
   Title: Invalid Sequence Number (TC)
   ProgName: UTEP221
   Author: B.C.G.
   Date: 08/06/2020
   Background:
   (Objectives, Assumptions, References, Success Criteria)
   Validate that the IUT will reject a normal flow PIU with a transmissionheader that has an invalid sequence number.

   Expected Sense Code: $2001, Sequence Number Error

   Reference - SNA Format and Protocols Appendix G/p. 380

   Data: (Tx Data, Predicted Rx Data)
   IUT
   <——– DATA FIS, OIC, DR1 SNF=20
   -RSP $2001

   Script: (Pseudo Code for Coding Tests)
   SEND_PIU FIS, OIC, DR1, DRI SNF=20
   SEND_PIU LIS, SNF=20
   R_RSP $2001

   If you have a testcase document,such as cases list,you just listed you case name and number,well enough.
   In other words,test specifications is a document show how to implement test cases.This is a example for white box.
   I think the example should be parsed as follows:
   Case No.: The test case number should be a three digit identifer of the following form: c.s.t, where: c- is the chapter number, s- is the section number, and t- is the test case number.

   Title: is the title of the test.

   ProgName: is the program name containing the test.

   Author: is the person who wrote the test specification.

   Date: is the date of the last revision to the test case.

   Background: (Objectives, Assumptions, References, Success Criteria): Describes in words how to conduct the test.

   Expected Error(s): Describes any errors expected

   Reference(s): Lists reference documententation used to design the specification.

   Data: (Tx Data, Predicted Rx Data): Describes the data flows between the Implementation Under Test (IUT) and the test engine.

   Script: (Pseudo Code for Coding Tests): Pseudo code (or real code) used to conduct the test.

   If you are performancing the job for black box,
   I think script can be changed into steps or removed on the condition that you have a test case document.In my opinion,the background can be scheduled according to the guy who reviewed the document.If the guy without any tech background,you can show many things to make him understand it.If the guy with tech background,it is enought that you just show the tech verb and objective. I think for expect error you should shows the accept exception in your product.If not, you can remove it.

   [Reply]