. '''To Software [[Software|Software]]''' - '''To Software-Assessment [[Software/Assessment|Software/Assessment]]''' - '''To [[https://bugs.cacert.org]]'''
 . '''To [[Software/Assessment/Documentation|Software Assessment Update Cycle documentation]]'''
 . '''To [[Software/CurrentTest]]''' - '''To Testserver [[http://cacert1.it-sls.de]]''' - '''To [[Software/Assessment/FAQ|Testers and Developers FAQ]]'''

----

= BUGS.CACERT.ORG Handbook =

 * [[#CreateAccount|How to add an account?]]
 * [[#AddNewBug|How to add a new bug report?]]
 * [[#AddNewReport|How to add a test report?]]
 * [[#States|How and who to change the state of a bug report?]]

<<Anchor(CreateAccount)>>
== How to add an account? ==

<<Anchor(AddNewBug)>>
== How to add a new bug report? ==

<<Anchor(AddNewReport)>>
== How to add a test report? ==
Change a bug reports state includes adding a comment, so changing to state "Solved?" requests from the Critical Admin to enter a description for the purpose of changing the state. Please continue reading [[#States|How and who to change the state of a bug report?]]


<<Anchor(States)>>
== How and who to change the state of a bug report? ==
Open the bug report in view mode. Select under "Change State" the new state and click "Change State". You will be redirected to a new page and prompted to enter a comment for changing the state, this will add a note to the bug at the same time as changing the state but you can also leave that text field empty, which only changes the state without adding a note


=== States ===

 || '''State'''      || '''Description''' || '''Who usually changes into this state?''' ||
 || new              || state to set on adding new bug || Reporter ||
 || needs feedback   || developer reviews a bug and has some questions to the reporter (reproduce bug process) || Developer ||
 || confirmed        || bug is confirmed to be a bug and waits for a developer to pick it up || Developer ||
 || needs work       || bug needs work to be fixed and maybe is already assigned to a developer (corresponds to the assigned state available in some bug trackers) || Developer ||
 || fix available    || the developer published a fix for the bug, and waits for a software assessor to transfer it to the test server || Developer ||
 || needs review & testing || the fix has been transferred to the test server and needs review (first or second) by a software assessor and testing by a software tester || Software-Assessor ||
 || needs testing    || the fix was transferred to the test server and has been reviewed (first and second review) but still needs testing by a software tester before it can go into production || Software-Assessor ||
 || needs review     || the fix has been transferred to the test server and has been tested by the test team but still needs a review (first or second) by a software assessor before it can go into production || Testteam t/l, Software-Assessor ||
 || ready to deploy  || the fix was reviewed and tested and is now ready to be deployed in the production environment by the critical admins || Software-Assessor ||
 || solved?          || the fix was deployed on the production environment, now the reporter is asked whether that solved his initial problem. Bugs might also go to this state if they are solved in other ways, e.g. duplicate of existing bug, unable to fix (corresponds to the resolved state available in some bug trackers) || Critical Admin, Developer ||
 || closed           || reporter confirms bug is fixed, case closed (also closed by developers if reporter doesn't react after some time) || Reporter ||

Possible workflow paths

 ||                        || new  || feedback || confirmed || work || fix || r & t || review || testing || deploy || solved? || closed ||
 || new                    || (./) || (./)     || (./)      || (./) || (./) || (./) || {X}    || {X}     || {X}    || (./)   || (./)   ||
 || needs feedback         || (./) || (./)     || (./)      || (./) || (./) || (./) || {X}    || {X}     || {X}    || (./)   || (./)   ||
 || confirmed              || (./) || (./)     || (./)      || (./) || (./) || (./) || {X}    || {X}     || {X}    || (./)   || (./)   ||
 || needs work             || (./) || (./)     || (./)      || (./) || (./) || (./) || {X}    || {X}     || {X}    || (./)   || (./)   ||
 || fix available          || (./) || (./)     || (./)      || (./) || (./) || (./) || {X}    || {X}     || {X}    || (./)   || (./)   ||
 || needs review & testing || (./) || (./)     || (./)      || (./) || (./) || (./) || (./)   || (./)    || (./)   || (./)   || (./)   ||
 || needs review           || (./) || (./)     || (./)      || (./) || (./) || (./) || (./)   || (./)    || (./)   || (./)   || (./)   ||
 || needs testing          || (./) || (./)     || (./)      || (./) || (./) || (./) || (./)   || (./)    || (./)   || (./)   || (./)   ||
 || ready to deploy        || (./) || (./)     || (./)      || (./) || (./) || (./) || (./)   || (./)    || (./)   || (./)   || (./)   ||
 || solved?                || (./) || (./)     || (./)      || (./) || (./) || (./) || {X}    || {X}     || {X}    || (./)   || (./)   ||
 || closed                 || (./) || (./)     || (./)      || (./) || (./) || (./) || {X}    || {X}     || {X}    || (./)   || (./)   ||


== Bug Life Cycle ==

This shows the life cycle of a bug once it's in the Software Assessment process:{{attachment:bug_life_cycle.svg|Life cycle of bugs|width="630",height="1240",align="right"}}<<BR>>'''Picture 1'''


And that's how this process is mapped to the bug states:
{{attachment:bug_states.svg|mapping process to bug states|width="1280",height="510",align="right"}}<<BR>>'''Picture 2'''

Yep, looks pretty damn complicated but it looks worse than it is in practise. I promise ;)

----
 . CategorySoftwareAssessment