Handling SRU testcases in launchpad

[Vic]

Steve et al

I have used the latter approach (having a formalised header in the 
descriptive text) in handling Improvement Proposals in a large 
multinational and found it to be, in practice, the most effective method 
in that it is so simple and doesn't have to modify existing data 
structures. I could add the system to the existing form of the 
documentation without a further Lloyds audit. I eventually hit on the 
format of a number based on the date followed by a number derived from 
the root problem. However in my case, I found I needed an extra number 
supplied automatically by the QA team - the date was based on a day and 
several proposals could be received. But using a computer in your case, 
hours minutes and seconds would be more than sufficient to unambiguously 
stamp a case. The rest of the description was as normal. In my case the 
title of the work. Lloyds were delighted with the system at the next ISO 
audit. Of course in this case, the structure of that number would have 
to be defined with testing in mind. The resultant initial composite 
numerical header is very amenable to computer manipulation.

Vici



Steve Beattie wrote:
> [Bjorn, I've cc:ed you on this, because we'd like to get the launchpad
>  team's perspective on the cleanest way to handle these.]
>
> In yesterday's QA team meeting, a discussion arose around how we handle
> test cases in launchpad. On of the things the QA team would like to do
> is to be able to pull out test cases from launchpad, present them to
> testers, and record results in a way similar to the iso testing tracker
> on qa.ubuntu.com.
>
> However, the current way test cases are annotated in launchpad are
> suboptimal for tools to pull them out automatically, as some are in the
> comments, some are in the descriptions, and there's no clear ending to
> the testcase (are there other issues?). We'd like to fix this with the
> constraint that it be both easy to pull them out programmatically *and*
> see them visually when examining the bug via the web interface.
>
> One proposal by Brian Murray was to make the test case(s) an attachment
> with standardized naming. The downside is that attachments aren't
> displayed inline and so viewers of the bug won't see them without
> effort. Proposed solutions to this include making python-launchpad-bugs
> modify the description to include the test case or extending the QA
> greasemonkey scripts to display test case attachments inline (downside
> is that not many people use the greasemonkey scripts).
>
> Another approach (advocated for by Jordan Mantha) would be to just ensure
> that the test cases are always included in the description and have an
> improved format that includes both a beginning and ending marker.
>
> Opinions? Alternate approaches? Flames?
>
> (In the longer term, would it be useful for launchpad to treat test
> cases as first class objects?)
>
> Thanks.
>
>