Difference between revisions of "BugSquad/Test Cases"

From Sugar Labs
Jump to: navigation, search
m (TestCases moved to BugSquad/ContentToEdit/TestCases: move to the bugsquad hierarchy)
 
(14 intermediate revisions by 6 users not shown)
Line 1: Line 1:
To land new versions of glucose and new activities in the OLPC builds we need to:
+
<noinclude>
 +
[[Category:Testing]]
 +
[[Category:BugSquad]]
 +
</noinclude>
  
* Provide test cases for each new feature or bug fix.
+
To land new versions of glucose and new activities in the Sugar builds we need to:
* Find testers to execute the test cases.
+
 
 +
* Provide test cases for each new feature or bug fix. See the [[Features/Feature Template]] and [[Features/Feature Template/Testing]].
 +
* Find testers to execute the test cases. Post an announcement on mailto:sugar-devel@sugarlabs.org providing a link to the Feature and Feature testing page.
  
 
A way to handle it in a distributed way and ensure it's done consistently is:
 
A way to handle it in a distributed way and ensure it's done consistently is:
  
* Ensure that every fix or new feature is associate to a trac ticket and that the git log for each of the related commits contain a reference to the bug.
+
* Ensure that every fix or new [[Features|feature]] is associated with a trac ticket and that the git log for each of the related commits contain a reference to the bug.
 
* Before closing the ticket make sure that it contains a comment with the test case (mark it by inserting a keyword in the text so that it can be extracted automatically.
 
* Before closing the ticket make sure that it contains a comment with the test case (mark it by inserting a keyword in the text so that it can be extracted automatically.
 
* When releasing a module, use a script to automatically generate the NEWS from the ticket references in the git log and the test cases (git log -> ticket -> test case). Put both in the release announcement.
 
* When releasing a module, use a script to automatically generate the NEWS from the ticket references in the git log and the test cases (git log -> ticket -> test case). Put both in the release announcement.
 
* Decide which modules to land together. Get the test cases from the release announcement and create a page in the wiki. Ask volunteers to execute them and report the problems they find.
 
* Decide which modules to land together. Get the test cases from the release announcement and create a page in the wiki. Ask volunteers to execute them and report the problems they find.
 
* Negotiate with the release manager on the base of the testing data
 
* Negotiate with the release manager on the base of the testing data

Latest revision as of 16:56, 13 June 2010


To land new versions of glucose and new activities in the Sugar builds we need to:

A way to handle it in a distributed way and ensure it's done consistently is:

  • Ensure that every fix or new feature is associated with a trac ticket and that the git log for each of the related commits contain a reference to the bug.
  • Before closing the ticket make sure that it contains a comment with the test case (mark it by inserting a keyword in the text so that it can be extracted automatically.
  • When releasing a module, use a script to automatically generate the NEWS from the ticket references in the git log and the test cases (git log -> ticket -> test case). Put both in the release announcement.
  • Decide which modules to land together. Get the test cases from the release announcement and create a page in the wiki. Ask volunteers to execute them and report the problems they find.
  • Negotiate with the release manager on the base of the testing data