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....')
 
 
(One intermediate revision by one other user not shown)
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! 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.


{| class="wikitable sortable"  
{| class="wikitable sortable"  
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!

Latest revision as of 16:58, 22 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! 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.
Feature fedoraproject.org/wiki nitrate
License
Integration with FAS
Pass pass
Fail fail
Supports anonymous user read-only access
Pass pass
Pass pass
Supports anonymous user read-write access
Pass pass
Fail fail
Data entry format mediawiki markup tinyMCE?
Test case re-use (write once, link anywhere)
Pass pass
using Category
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 Package-x-generic-16.pngyum and Package-x-generic-16.pngPackageKit. 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!