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 on QA:

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

Nethserver Dev Manual:

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

or more in general to better understand the development process:

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

useful link on Github:

• open issues in testing: https://github.com/NethServer/dev/labels/testing4
• open issues (sort by recently updated): https://github.com/NethServer/dev/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

Who can join Requirements for new members: - Verified at least an issue or one verified bug report - A GitHub account 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. send your GitHub accont name to QA Team Coordinator and @davidep to be enabled
1. devs put issue on QA (blue "testing" label)
2. https://github.com/NethServer/dev/issues
3. select the issue you want to test and assign it to you (select "assign yourself")
4. compile template (follow after) with the status of the box, and the package/groups currently installed
5. first, if possible (if it's a bug) try to replicate the bug
6. then try to install the new packages (during installation check /var/log/messages or with journalctl for strange error/fail messages)
7. follow test cases (if no tests cases are present feel free to ask more info writing a comment to the issue)
8. if you have some ideas for other tests cases, add them to list in template and test them
9. repeat testing steps used when replicating the bug
10. at every step control /var/log/messages or use journalctl
11. write results on GitHub
12. if all is ok put the issue in verified state: select the "verified label" and deselect the "testing" label. Then write a comment with results of your test possibly using the template
13. otherwise comment the issue with the results of your tests and deselect the "testing" label
14. if in doubt use write a comment

VERIFICATION TEMPLATE for GitHub

*System and  Package Version installed*
  
  Package Installed: ...
  Other Package installed: ...
  
  *Test Original Problem*
  
  *Install Updated Package*
  `yum --enablerepo=nethserver-testing update ... `
  
  *Test Results after update*
  ...
  
  *Verified Or Reopen*
  ...
  
  *Note*
  ...

EXAMPLE of compiled verification Template

  *System and Package Version installed*
  [description of the 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]
  ` yum --enablerepo=nethserver-testing update ...`
  
  *Test Results after update*
  [Repeat steps carried out under TESTING above.]
  
  *Verified Or Reopen*
  [Problem fixed, then VERIFIED - not fixed, then leave a new Comment]
  
  *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