Difference between revisions of "Testcase"

From Apache OpenOffice Wiki
Jump to: navigation, search
(typo)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Testcase is the term used when describing a set of actions that is performed in order to ensure a specific functionality is working correctly.
+
Test case is the term used when describing a set of actions that is performed in order to ensure a specific functionality is working correctly.
The term is not to be confused with [http://wiki.services.openoffice.org/wiki/Testplan testplan]
+
  
Note that the correct term is "testcase specification" which is not used here because it could be confused with the "feature specification".
+
The term is not to be confused with [[Testplan|testplan]] and also note that the correct term is "[[Test case specification template|testcase specification]]" which is not used here because it could - again - be confused with the [[specification|(functional) software specification]].
  
  
== Requirements for a good testcase ==
+
== Requirements for a good test case ==
  
A testcase should be explicit.  
+
A test case should be explicit.  
  
 
Explicit means  
 
Explicit means  
Line 13: Line 12:
 
* That every step also lists the exact result e.g. "Click on the File Open button on the Standard toolbar -> The File Open dialog should pop up"
 
* That every step also lists the exact result e.g. "Click on the File Open button on the Standard toolbar -> The File Open dialog should pop up"
  
If you follow these rules it becomes very likely that the manual testcase can be transformed into an automated testcase and thus does no longer have to be checked manually by a QA volunteer.
+
If you follow these rules it becomes very likely that the manual test case can be transformed into an automated test case and thus does no longer have to be checked manually by a QA volunteer.
  
== Specifications and testcases ==
+
== Specifications and test cases ==
  
Ideally a specification should be written in a way that all suitable testcases can be extracted directly from the specification text.  
+
Ideally a feature specification should be written in a way that all suitable test cases can be extracted directly from the specification text.  
 
   
 
   
  
== Writing a testcase - a sample ==
+
== Writing a test case - a sample ==
  
The best way of writing a testcase is using a bulletlist as a step-by-step description wich lists the action and the the and the expected result of the action. Start with the prerequisites, then describe the single steps. Sample:
+
The best way of writing a test case is using a bulletlist as a step-by-step description wich lists the action and the expected result of the action. Start with the prerequisites, then describe the single steps. Sample:
  
Ensure that you start with a fresh profile.
+
Ensure that you start with a fresh profile.
* Open exactly one empty Writer document
+
* Open exactly one empty Writer document
* Enter the text "This is a testcase"
+
* Enter the text "This is a test case"
* Select the text using the mouse from left to right -> The entire string should be selected
+
* Select the text using the mouse from left to right -> The entire string should be selected
* Apply the attribute "Bold" to the selection by clicking on the icon in the Format toolbar -> The selected text should turn bold instantly
+
* Apply the attribute "Bold" to the selection by clicking on the icon in the Format toolbar -> The selected text should turn bold instantly
* Save the file by clicking on the FileSave button on the Standard toolbar
+
* Save the file by clicking on the FileSave button on the Standard toolbar
* Navigate to the user's workdirectory (/home/testuser/.openoffice.org/user/work)
+
* Navigate to the user's workdirectory (/home/testuser/.openoffice.org/user/work)
* Name the file "MyTestFile"
+
* Name the file "MyTestFile"
* Ensure that the automatic file extension is enabled (This is the default)
+
* Ensure that the automatic file extension is enabled (This is the default)
* Click "Save"
+
* Click "Save"
* Close the file via window closer -> All instances of the application should be closed
+
* Close the file via window closer -> All instances of the application should be closed
* Open the file via you favorite filemanager -> The office should start and load the requested document
+
* Open the file via you favorite filemanager -> The office should start and load the requested document
...
+
...
  
 
You probably got the point by now. Write it for dummies. Braindead dummies. And don't take anything as given.
 
You probably got the point by now. Write it for dummies. Braindead dummies. And don't take anything as given.
  
 
--Skotti 10:56, 21 March 2007 (CET)
 
--Skotti 10:56, 21 March 2007 (CET)
 +
[[Category:Quality_Assurance]]

Latest revision as of 05:44, 6 July 2007

Test case is the term used when describing a set of actions that is performed in order to ensure a specific functionality is working correctly.

The term is not to be confused with testplan and also note that the correct term is "testcase specification" which is not used here because it could - again - be confused with the (functional) software specification.


Requirements for a good test case

A test case should be explicit.

Explicit means

  • That the prerequisites are defined as exact as possible, e.g. "Define valid proxy settings so acces to the internet in Tools/Options>OpenOffice.org/Internet"
  • That every step also lists the exact result e.g. "Click on the File Open button on the Standard toolbar -> The File Open dialog should pop up"

If you follow these rules it becomes very likely that the manual test case can be transformed into an automated test case and thus does no longer have to be checked manually by a QA volunteer.

Specifications and test cases

Ideally a feature specification should be written in a way that all suitable test cases can be extracted directly from the specification text.


Writing a test case - a sample

The best way of writing a test case is using a bulletlist as a step-by-step description wich lists the action and the expected result of the action. Start with the prerequisites, then describe the single steps. Sample:

Ensure that you start with a fresh profile.
* Open exactly one empty Writer document
* Enter the text "This is a test case"
* Select the text using the mouse from left to right -> The entire string should be selected
* Apply the attribute "Bold" to the selection by clicking on the icon in the Format toolbar -> The selected text should turn bold instantly
* Save the file by clicking on the FileSave button on the Standard toolbar
* Navigate to the user's workdirectory (/home/testuser/.openoffice.org/user/work)
* Name the file "MyTestFile"
* Ensure that the automatic file extension is enabled (This is the default)
* Click "Save"
* Close the file via window closer -> All instances of the application should be closed
* Open the file via you favorite filemanager -> The office should start and load the requested document
...

You probably got the point by now. Write it for dummies. Braindead dummies. And don't take anything as given.

--Skotti 10:56, 21 March 2007 (CET)

Personal tools