Difference between revisions of "QUASTEe TCS Tool Tutorial"
m (→Define the Properties of the TCS) |
m ((checkpoint save)) |
||
Line 82: | Line 82: | ||
** '''Obsolete''': meaning "Well, the function does not exist anymore, but I'd like to keep this TC for my records..." | ** '''Obsolete''': meaning "Well, the function does not exist anymore, but I'd like to keep this TC for my records..." | ||
* '''Published (15)''': check this when you want your TC to appear in the '''Preview [C]''' tab page. | * '''Published (15)''': check this when you want your TC to appear in the '''Preview [C]''' tab page. | ||
− | * '''Description (16)''': | + | * '''Description (16)''': |
+ | <div style="font-size: 100%; background-color: LightGoldenRodYellow; align:block; border:thin solid orange; padding: 4px; width: 500px;height: auto; margin-left: 20px;">'''How to write a TC?''': | ||
+ | * Use as far as possible short sentences | ||
+ | * Write in form of an enumeration using hyphens. | ||
+ | * Follow the model: "do this, do that -> check that you get that" | ||
+ | * Note: this field does not allow any HTML (or whatever) formatting. This is done is Purpose! The TCS tool needs to keep a certain export flexibility (to Wiki, HTML...) and a certain level of standardization.</div> | ||
[[Image:09_TC_saved.JPG]] | [[Image:09_TC_saved.JPG]] |
Revision as of 12:55, 29 June 2010
Introduction
Every new feature or enhancement needs a specification and this specification, to be final, must refer to a Test Case Specification (TCS)
which describes a number of manipulations, actions to execute in the application to test its functionality.
For commodity reasons (readability, ease of analysis), a TCS is segmented into smaller units: the Test Cases (TC).
TCS are stored in a database and can be edited, deleted or queried over a web front-end in QUASTe.
This web front-end is called TCS Tool.
The current tutorial explains how to use it.
Contents
How to create and edit a new TCS
Login and Create
- Go to http://quaste.services.openoffice.org/
- In the right navigation panel, enter your credentials in order to login (1)
- In the Left navigation panel, click on 'Create Test case specification (2)
Define the Properties of the TCS
- First define the Properties [A] of the TCS using two fields:
- (3) Product: This is the release in which the enhancement has been introduced.
- (4) Title: a short and "meaningful" summary for your TCS
Tip: avoid using the word "test" here! Every TCS are "tests" or are written in order to "test" something... - Click the [N]ext button to move to the next step.
Tip: Letters between [] are shortcuts which in most browser are reachable over Alt+letter:
- Component (5): choose which application or areas your TCS will apply to.
- Test run frequency (6): corresponds Automation Categories and means "how often should this TCS be run when it has been automated?"
Tip: If you don't known what to choose... Choose everything you want butTo run on all builds an releases
... - Motivation (7): A kind of justification of the TCS... We need references to know that the TCS really covers what it should.
- Own initiative: it's ok not to have a reference, for instance when you decide to write a TCS which covers existing fetures... But if you have a reference please choose...
- Specification: If your TCS is based on a specification, choose this entry.
You will be prompted for the URL to this specification in the next step. - Issue: typically when you want to create a TCS which should avoid an already occurred defect to happen again (regression).
You will be prompted for the URL to this issue in the next step.
- URL (8): depending on your choice at last step, the URL to the specification or the issue.
- Summary (9): a more detailed description than the TCS title.
- CWS (10): the name of the CWS the feature has been implemented in.
- Preconditions (11): There you can explain about the context of the TCS, what should others know before testing?
Examples: "should something special (extension?) be installed to test the feature?", "OS specific?", "Locale specific?"... - Comment on changes (12): feel free to document what you are changing and why.
As soon as you you have saved the properties form and created a TCS, more Tabs appear which will help you editing the TCS:
- Testcases [B]: there you will start writing TCs.
- Preview [C]: how the whole TCS will look like (i.e. when printed)
- History [D]: a changes tracking which can be useful when others edit your TCS.
Now click on the Testcases [B] for the next step...
Add TCs
Click on [N]ew as mentioned...
- Title (13): enter here a title for the test case.
Tip: it's just a usage of the Automation folk but it's good practice to write a title...
... with a small "t" at the beginning (meaning "tEstCase")
...to WriteAllWordsTogether
...to WriteInCamelCase...
...Else feel free to write whatever you want! But PLEASE, be very SHORT! Without full sentences! - Status (14):
- Preliminary: meaning "Please, don't use it yet! I'm not finished with writing!"
- Standard: meaning "I am finished! Can be tested!"
- Obsolete: meaning "Well, the function does not exist anymore, but I'd like to keep this TC for my records..."
- Published (15): check this when you want your TC to appear in the Preview [C] tab page.
- Description (16):
- Use as far as possible short sentences
- Write in form of an enumeration using hyphens.
- Follow the model: "do this, do that -> check that you get that"
- Note: this field does not allow any HTML (or whatever) formatting. This is done is Purpose! The TCS tool needs to keep a certain export flexibility (to Wiki, HTML...) and a certain level of standardization.
Upload Test Documents
Delete TCs
Find TCSs