Using Testlink as a test case repository?

[carlwaite]

Hi,
Not sure whether this question belongs to a 1.7 discussion. I\\\'m looking for some comments/ideas of the proposal below.

We have had excellent experiences with testlink and would like to change some small things as we adapt our test process to get even more from testlink.

My situation today is that we have the following flow for testlink:

1. Start with a legacy test specification written in MS word
2. Save as txt file
3. Extract the testcase headings using small perl script to generate csv file
4. Import csv into testlink.
5. Start testing
6. Let some weeks go by
7. Finish testing
8. Update origingal MS word test specifications with any discoveries from testing. Bad designed testcases etc.
9. Repeat

Step 8 is a big admin nightmare for our testers. We would like to add some more dynamicness into the process by updating the testcases as we are testing.

Something like this:
1. Testcases (including descriptions, Action/Result etc) are in testlink
2. Start testing
3. Testers update testcases
4. Stop testing
5. Generate test documents for posterity from testlink

Step 3 will cut down on the admin hopefully

To support this (and some other things) we have decided to put our testspecs into XML format. Something like this as a skeleton for a testcase:

(I couldn\\\'t get less than sign to work, so it\\\'s a _ instead.....)

Code: Select all

        _TestCase>
          _Title>Test Some things with an XML testcase_/Title>
          _Tag>XYZ-081_/Tag>
          _Priority>2_/Priority>
          _Requirement>X123>
          _Requirement>Y123_/Requirement>
          _Keyword>Function test_/Keyword>
          _Keyword>Load Test_/Keyword>
          _Configuration>Some specific config_/Configuration>
          _Precondition>Some precondition_/Precondition>
          _Preparation> _/Preparation>
      _TestStep>
          _Actions>Some action_/Actions_
          _Result>Some result_/Result_
      _/TestStep>
          _Postcondition>Some post condition_/Postcondition>
        _/TestCase>

So this leads me to what I really want to do.
There are some fields available when editing testcases in testlink:
Test Case Title
Summary
Steps
Expected Results
Keywords

I plan on making some changes to our local testlink so that it\\\'s possible to have the same text fields as input similar to the XML skeleton above. This will mean it\'s easier for us to import/export an xml file after testers have updates the testcases.

Does this sound like a reasonable idea? ie have more control over the structure of a testcase in testlink? Or is there some other way that I haven\\\'t thought of?

Thanks in advance for comments/ideas.

//Carl

[havlatm]

Hi Carl,
XML import/export is planned feature in 1.7. Look at http://www.testlink.org/mantis/login_page.php. I\'m not sure if there is request for this new feature. If there isn\'t, could you make it? It could be configurable to apply your specific needs.

However, your XML example includes some parameters that are not implemented yet. E.g. priority. I also have not idea how to solve requirements consistency.

Interesting thing is that your process has basic source MS Word. This is something which is not expected in architecture of TL. But it could work as I see

We plan deep changes in 1.7, so if you design some patch for 1.6. It will not be easily transferable to 1.7. I find you would like to have configurable content of exported document. Am I right? I think that inthis area we could easily coordinate your effort with our one.

I\'m sorry if something is unclear, I should be at least two hours in my bed

Martin

[Guest]

Hi Martin,
I have added feature request: 0000282 to Mantis.
This includes an xml schema example that our test docs are being converted to.
I maybe wasn\\\'t so clear about the word doc input. These docs are legacy, ie they exist in word today. We want them out of word and into xml. I have parsers that have performed these changes, so we now have a bunch of xml documents to imported into testlink.

For now what will happen is the xml will be parsed into csv. Any fields that don\\\'t exist, ie priority, will be added into the summary field. Of course the problem with this is that we can\\\'t update the test specs in Testlink and re-export them as the context of the xml elements has been lost.

Yep, you should get to bed in time I need to get some sleep myself, I\\\'m sure I found a web page where I can download some, but I seem to have lost it for now zzzzzzz.......

[carlwaite]

Just forgot one of the points you mentioned.
Priority, at the moment we\'ll just use this as a string in the document, ie no selection based on priority.
Requirement, similar here, in the first case we\'re just looking to have a reference to a requirement in our external Req database, nothing more complicated than that.
Hope that clarifies what I meant
//Carl

[havlatm]

Hi,

Thank you to added issue to BTS. I\'m too half sleeping now. So I\'m not able to respond something clever

Regards,
Martin