Quality Assurance ================= This page explains how to help the UBports QA team, both as an official member or a new contributor. Please also read the :doc:`issue tracking ` and :doc:`bugreporting ` guides to better understand the workflow. For real-time communication, you can join our `telegram group `_. Smoke testing ------------- To test the core functionality of the operating system, we have compiled `a set of standardized tests `_. Run these tests on your device to :doc:`find and report bugs and regressions `. It's usually run on all devices before a new release to make sure no new issues were introduced. Confirming bug reports ---------------------- Unconfirmed bugreports are labeled **needs confirmation** to enable `global filtering `__. Browse through the list, read the bugreports and try to reproduce the issues that are described. If necessary, add :doc:`missing information or logs, or improve the quality of the report by other means `. Leave a comment stating your device, channel, build number and whether or not you were able to reproduce the issue. If you have write-access to the repository, you can replace the **needs confirmation** label with **bug** (to mark it confirmed) or **invalid** (if the issue is definitely not reproducible). In that case it should be closed. If you find two issues describing the same problem, leave a comment and try to find their differences. If they are in fact identical, close the newer one and label it **duplicate**. Testing patches --------------- Pull-requests can be tested using the `QA scripts `_. Run ``ubports-qa -h`` for usage information. Once the pull-request has been merged, the issue it fixes is moved to the completed column of the `Gitlab Milestone `__. Please check if the issues in this column are still present in the latest update on the devel channel, then see if anything else has broken in the update. Check if the developer mentioned specific things to look out for when testing and leave a comment detailing your experience. If you have write-access to the repository, you can move the issue back to **In Development** (and reopen it) or forward to **Release Candidate** as specified by the :doc:`issue tracking guidelines `. Initial triaging of issues -------------------------- Initial triaging of new issues is done by QA-team members with write-access to the repository. If a new issue is filed, read the report and add the correct labels as specified by the :doc:`issue tracking guidelines `. You can also immediately start confirming the bugreport. If the new issue has already been reported elsewhere, label it **duplicate** and close it.