From Fedora Project Wiki
(Created page with '* ~~~~ - ''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....') |
(tests affecting multiple packages) |
||
| Line 1: | Line 1: | ||
== Comparing discrete features == | |||
* [[User:Jlaska|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. | * [[User:Jlaska|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. | ||
* [[User:Jlaska|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! | * [[User:Jlaska|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! | ||
| Line 31: | Line 32: | ||
|- | |- | ||
|} | |} | ||
== Tests that impact multiple packages == | |||
* [[User:Jlaska|jlaska]] 23:03, 21 December 2010 (UTC) - During discussion of critical path test case creation, [[User:Adamw|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 {{package|yum}} and {{package|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! | |||
Revision as of 23:03, 21 December 2010
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!
| Feature | fedoraproject.org/wiki | nitrate |
|---|---|---|
| License | ||
| 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) | |
Using test plans |
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
yum
