The attached workbook contain two sheets a) document Version b) Test case template
In the document version sheet, specify actual Project Name. The Version Number and date, reason for change, Author, reviewed by and approved by columns should be specified by test engineer. If he makes any changes in the test case template, version history helps to know what changes made in the document and who has reviewed and approved.
In the test case template, On the Top-Left Corner template has Project Name, release no, Module name, testing cyle/round number/iteration number, OS/Platform. Header information to be filled only once during test case design.
Template contain the fields Sr. No, Requirement Number, Test Case ID, Test Case Description, Pre-condition, test case steps, test data, expected result, test case created by, Type of Test Case/Keyword, Priority, test case creation planned duration, test case creation actual duration, test case create date, test case execution planned duration, test case execution actual duration, Cycle#1, Cycle #2 for each Test Case. Again this Cycle is divided into actual result, Status, comments, test case executed by, execution date, defect ID, defect status, logged date, closed date.
Couple of sections are detailed here for your reference
Test Case ID: To Design the Test Case ID also we are following a standard: If a test case belongs to application not specifically related to a particular Module then we will start them as TC001, if we are expecting more than one expected result for the same test case then we will name it as TC001.1. If a test case is related to Module then we will name it as <Module name or module ID>_TC001, and if a module is having a sub-module then we name that as <Module name or module ID>_<SubModule name or Submodule ID>_TC001. So that we can easily identify to which Module and which sub-module it belongs to. And one more advantage of this convention is we can easily add new test cases without changing all Test Case Number so it is limited to that module only
Requirement Number: It gives the reference of Requirement Number in SRS/FRD for Test Case. For Test Case we will specify to which Requirement it belongs to. The advantage of maintaining this one here in Test Case Document is in future if a requirement will get change then we can easily estimate how many test cases will affect if we change the corresponding Requirement.
Type of Test Case: It provides the List of different type of Test Cases like GUI, Functional, Integration, end to end, smoke and Regression etc., which are included in the Test Plan. So while designing Test Cases we can select one of this option. The main objective of this column is we can predict totally how many GUI or Functionality test cases are there in each Module. Based on this we can estimate the resources.
Test Case description: Here we provide one line description about the test case.
Test case steps: This is very important part in Test Case because it gives the clear picture what you are doing on the specific functionality. We can say the navigation for this Test Case. Based the steps we have written here we will perform the operations on the actual application.
Expected Result: This is the result of the above test case steps. It specifies what the specification or user expects from that particular action. It should be clear and for each expectation we will sub-divide that Test Case. So that we can specify pass or fail criteria for each expectation. Up to the above steps we will prepare the Test Case Document before seeing the actual application and based on System Requirement Specification/Functional Requirement Document and Use Cases. After that we will send this document to the concerned Test Lead for approval. He will review this document for coverage of all user Requirements in the Test Cases. After that he approved the Document. Now we are ready for testing with this Document and we will wait for the Actual Application. Now we will use the Cycle #1 parts. Under each Cycle#1 we are having actual result, Status, comments, test case executed by, execution date, defect ID, defect status, logged date, and closed date. Number of Cycles is based on the requirement size, complexity, schedules made by lead. Some projects propose three Cycles some projects propose the information for Four Cycles. But at least two cycles must be proposed. But here I provided only two Cycles in this Template but you have to add more cycles based on your requirement.
Actual: We will test the actual application against each Test Case and if it matches the Expected result then we will say it as "As Expected" else we will write the actually what happened after doing those action.
Status: It simply indicates Pass or Fail status of that particular Test Case. If Actual and Expected both mismatch then the Status is Fail else it is Pass. For Passed Test Cases Bug ID should be null and for failed Test Cases Bug ID should be Bug ID in the Bug Report corresponding to that Test Case.
Note: Bug ID gives the reference of Bug Number in Bug Report. So that Developer/Tester can easily identify the Bug associated with that Test Case.