Difference between revisions of "QUASTEe TCS Tool Tutorial"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
m (Define the Properties of the TCS)
Line 40: Line 40:
  
 
* '''Component (5)''': choose which application or areas your TCS will apply to.
 
* '''Component (5)''': choose which application or areas your TCS will apply to.
* '''Test run frequency (6)''': corresponds [http://wiki.services.openoffice.org/wiki/QUASTe#Category_model Automation Categories] and means "how often should this TCS be run when it has been automated?"<br>''Tip: If you don't known what to choose... Choose everything you want but <code>To run on every builds an releases</code>...''
+
* '''Test run frequency (6)''': corresponds [http://wiki.services.openoffice.org/wiki/QUASTe#Category_model Automation Categories] and means "how often should this TCS be run when it has been automated?"<br>''Tip: If you don't known what to choose... Choose everything you want but <code>To run on all builds an releases</code>...''
 
* '''Motivation (7)''': A kind of justification of the TCS... We need references to know that the TCS really covers what it should.
 
* '''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...
 
** '''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...

Revision as of 23:38, 28 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.

How to create and edit a new TCS

Login and Create

00 Login.JPG


01 Start.JPG

  • In the Left navigation panel, click on 'Create Test case specification (2)


Define the Properties of the TCS

02 Properties.JPG

  • 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:



03 Properties Details 01.JPG

  • 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 but To 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.



05 Properties Details 03.JPG

  • 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.



06 Properties after save.JPG

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

07 TC empty.JPG

Click on [N]ew as mentioned...

08 TC first.JPG

  • 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):

09 TC saved.JPG

10 TC preview.JPG

Upload Test Documents

11 TC testdoc upload.JPG

12 TC testdoc uploaded.JPG

13 TC preview testdoc.JPG

Delete TCs

14 TC delete01.JPG

15 TC delete02.JPG

Find TCSs

16 TC Find Start.JPG

17 TC Find List.JPG

18 TC Find Preview.JPG


Personal tools