The main feature of Nethserver is the modular design, this means that there are many different setups as people has different interests. As member of Testing Team you could act as a contact person for a specific area to help developers fix the bugs you care about, and is the best way of making sure it does what you need it to!

some useful links:

• http://blog.smartbear.com/programming/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/
  

Nethserver Dev Manual:

• http://docs.nethserver.org/projects/nethserver-devel/en/latest/development_process.html#qa-team-member
  

or more in general:

• http://docs.nethserver.org/projects/nethserver-devel/en/latest/development_process.html
  

Who can join Requirements for new members: Verified at least an issue or one verified bug report.
Anyone who is interested in improving the quality on his/her setup and is willing to communicate with developers and other testers.

How do you join Simply send a PM to me (@dz00te) or to @alefattorini

How do you test:

GENERAL WORKFLOW

0. register on redmine: http://dev.nethserver.org/projects/nethserver
  1. devs put issue on QA in redmine, check:
     http://dev.nethserver.org/projects/nethserver/issues?query_id=27 
     or in redmine you can set preferences to send notfication via mail, or subscribe to rss
  2. in redmine modify the qa to: assign it to "<<me>>"
  3. compile template (follow after) with the status of the box, and the package/groups currently installed
  4. first, if possible (if it's a bug) try to replicate the bug
  5. then try to install the new packages (during installation check /var/log/messages for strange error/fail messages) 
  6. follow test cases (if no tests cases are present feel free to ask info with NEEDINFO flags on redmine)
  7. if you have some ideas for other tests cases, add them to list in template and test them
  8. repeat testing steps used when replicating the bug
  9. at every step  control /var/log/messages
  10. if all is ok put the issue in verified state, otherwise set the bug as triaged, or if in doubt use NEEDINFO and a comment
  11. in note, write if documentation should be updated

VERIFICATION TEMPLATE for Redmine

  +System and  Package Version installed+
  ...
  Package Installed: ...
  Other Package installed: ...
  
  +Test Original Problem+
  ...
  
  +Install Updated Package+
  <pre>
  yum --enablerepo=nethserver-testing update ... 
  </pre>
  
  +Test Results after update+
  ...
  
  +Verified Or Reopen+
  ...
  
  +Note+
  ...

EXAMPLE with compiled verification Template

  +System and  Package Version installed+
  [description of test system (version, installation methods, upgrade history. etc).
  Package Installed: [rpm -qa <package name>]
  Other Package installed: [yum grouplist | sed  '1,/Installed/d;/Available/,$d']
  
  +Test Original Problem+
  [Reproduce bug if you can, showing steps taken]
  
  +Install Updated Package+
  [Update to new package, show steps taken]
  <pre>
  yum --enablerepo=nethserver-testing update ... 
  </pre>
  
  +Test Results after update+
  [Repeat steps carried out under TESTING above.]
  
  +Verified Or Reopen+
  [Problem fixed, then VERIFIED - not fixed, then TRIAGE]
  
  +Note+
  [Documentation Impact]
  [Other]
  note: maybe to comply the point 4 of the workflow, it would be nice that when a new bug is opened it contains 
  1. status of test box and list of packages/groups currently installed
  2. howto replicate problem in detail