From Fedora Project Wiki
Comparing discrete features
- jlaska 21:27, 16 December 2010 (UTC) - Workflows - I like that you are identifying and comparing the different workflows in each solution. Let's continue capturing how we are using the wiki now (e.g. creating a test, posting a test result, Adding a bug to a result, initiating a new test run, finding remaining untested cases, Submitting a test summary, etc...). I'm not sure of the best way to compare workflows ... I'd have to play around with different options. The important thing for now seems to be capturing them.
- jlaska 21:27, 16 December 2010 (UTC) - Features - Once we've identified as many workflows as we can, let's drill down and inspect the features of each tool that we'd use/need. I think this needs to be a different table/section from the workflows. However, your table example seems to work well for comparison purposes. Try to keep each feature short and simple. If it's too long, we might need to break it down into smaller parts. Maybe something like the following? Feel free to adjust as needed of course! adamw: for me, the FAS integration and anon read/write access are key features: anon read/write is not interesting for creating test cases and test plans but it's vital for reporting results. It must be possible for people to report results without any kind of account.
|Integration with FAS|
|Supports anonymous user read-only access|
|Supports anonymous user read-write access|
|Data entry format||mediawiki markup||tinyMCE?|
|Test case re-use (write once, link anywhere)|
Tests that impact multiple packages
- jlaska 23:03, 21 December 2010 (UTC) - During discussion of critical path test case creation, Adamw noted that it would be nice to be able to write tests that can be used for testing multiple packages. For example, some yum tests might be used to test both
PackageKit. I think nitrate allows linking tests to the packages they are designed to test, and therefor would allow this type of query when creating a new test run. That might be something to list in the features. Theoretically, Categories could be used on the wiki to organize this data, but that's starting to get messy!