On 2014-08-14 09:42, Amita Sharma wrote:
you missed one last question :: If this decision is made, have we
thought about the migration/porting of existing wiki test case/plans
to tcms?
Oops, indeed, sorry (missed it in the nesting).
That's one of the slightly trickier areas. Moztrap is bound to its 'one
step, one expected response' model, where we have the %prep stage and we
have separate stages for 'steps' and 'results' so they can have any kind
of mapping, it doesn't have to be 1:1.
My initial thought was that we dump the steps from %prep into the test
description wholesale (this is what upstream basically recommends - they
say any preliminary details about test setup and so on should be in the
descripton). For the step/result thing, what I figured was that we
should just put in whatever we have and leave the 'corresponding' step
or result empty for any imbalance (so if there are 5 steps and 3
expected results, you'd have 2 empty expected result sections, if there
are 2 steps and 6 expected results, you'd have 4 empty step sections),
then fix it up by hand - I don't think we can get any cleverer with the
conversion. Even where the quantity of steps and results matches they
won't necessarily correspond perfectly 1-to-1 in the way moztrap
expects.
So basically I think this issue means we can't achieve a fully automated
conversion, we'd need a degree of manual intervention / review for every
test case. I don't think that's completely unmanageable, though, I
believe our current test case corpus is in the hundreds not the
thousands and a lot of them could do with review anyway (and we can
always do a staged conversion - for instance only move validation
testing to moztrap at first, then we'd only need to convert the
validation test cases). It's something we could blow through as a
hackfest (remote) type thing, if we chose.
So far as the tech goes, it's fairly trivial - moztrap supports a very
lightly structured text format for imports, so you just have to write
something which yoinks test case pages from mediawiki and does a fairly
straightforward bit of text munging on them. Well, if we try to retain
formatting in some way we can make the text munging more complex, it
depends how much we care.
http://moztrap.readthedocs.org/en/latest/userguide/ui/import.html#bulk-test-case-entry-formats
is the documentation for bulk entry; it gives the basic idea, there are
some details that aren't covered (like if we use markdown syntax in the
Gherkin-style import format, will it show up in the resulting test case?
- that kinda thing).
We could of course contribute code to make moztrap not assume that all
test cases have one result per step, but that's probably more work than
just adjusting our test cases to that format.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
