test run

what happens if the user makes a mistake?
- how do you deal with that?
- tchung and ludo expand all do the tests and then at the end submit all. Because they are usually grouped similarly so it makes more sense. There could be an end user/admin user thing. Conclusion: have button to expand all and remember the user's choice.
- having them all open at once and having them able to be re-ordered might be nice. The ability to easily organize and reorder the tests and (assuming) save that order - admin function.
what about the cloning process for these test runs?

unclear

it's almost like the voting function - anyone can add an idea about a test and it would be sent to a admin or it would go up to the review queue.
would you want to keep the test comments around?
could get way too much stuff in it but you might want a way to clear a comment.
majority of the comments are usually useful. Note: this was about comments on test result not testcase.
would you want to see the comments on the test run page? Conclusion: maybe a 'x comments' link that expands
could also use it as a running discussion of the test case and give an idea of quality of a test case.

submit all at once or per click
sending discreet pass/fails as they hapen
perhaps keep them on the local side and show something at the end of the run to say "submit all at once"
if you see alternateing pass/fail stuff then that might be a warning that a test case is unclear. Note: this was an upside of submitting discretely.
last result in wins. submitting discretely.

have a panel show up with the bug ids that are related to the test case.
shows bug IDs filed previously for this test case and allows someone to choose a bug then it is a bug
or allow them to file a bug straight through the litmus API. Shouldn't have to deal with bugzilla.
and tag the results as saying "bug filed" or "not filed".

forcing steps to be discrete so that we control formatting/splitting etc
have a way to show expected results between steps as well that way (tie the expected results to steps)
testcases should be discrete - they should test one thing but you may be grouping a lot of different actions. Have an easy way to order the tests that comes up again If the ordering is proper, then you can do dependencies and say if test 1 fails then the rest might be grayed out because they cannot run any other ones.
use screen shots for expected results as well ( but you'd have to update the test case each time that the UI changes.)
notification for the collection or test is added and then the admin can put them in someplace where it needs to go.
might not have the tag and collections on the general test edit
How do we control the tag creation - you don't want people chanigng the grouping tags willy-nilly don't want to lose what is in a smoketest etc. Conclusion: Allow any tag technically, but control which collections can be used - only product owner/admins are allowed to add collections.
voting process for writing new test cases

The way ludo looks at coverage looks at columns and what is green in the columns and i sub1 is run then he'll run subset 2, in the end he wants to see that all subsets have been run.
personal coverage might not be that useful - maybe have it in the database but you want to look at overall coverage.
commuity coverage is nice because you can easily identify the stars of the community.

buildID is useful to ensure that people are trunning the asme version - but we should have ti be flexible to be different things - make it configurable or change what it is on a per product basis (and also make the notes on how to get said build ID differ on a per product basis.