Контроль качества (Quality Assurance)

На этой странице рассказывается, как могут помочь опытные разработчики или новые участники отделу QA. Пожалуйста, также ознакомьтесь с документами issue tracking и bugreporting, чтобы лучше понимать как организован рабочий процесс. Задать вопросы или пообщаться можно в нашем чате в Telegram.

Smoke testing - тестирование на начальном этапе

Для тестирования ключевых функций системы мы подготовили набор стандартизованных тестов. Запустите эти тесты на своём мобильном устройстве для поиска багов и регрессии. Обычно эти тесты проходят на всех устройствах перед выпуском нового релиза операционной системы.

Подтверждение сообщений об ошибках (баг-репортов)

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 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.

Если у Вас есть права на запись в репозиторий, можно поменять ярлык needs confirmation на bug (если ошибка подтверждается) или invalid (если баг не воспроизводится). В последнем случае запрос нужно закрыть.

Если Вы найдете два открытых тикета, описывающих одну и ту же проблему, напишите комментарий и попробуйте найти различия.Если эти две заявки на самом деле одинаковые, закройте последнюю по дате и обозначьте ее маркером duplicate.

Тестирование патчей

Pull-requests можно протестировать с помощью скриптов QA. Запустите команду ubports-qa -h для более подробной информации.

После объединения pull-request и исправления ошибки, он перемещается в столбец группы обеспечения качества на страничке проекта в GitHub.Пожалуйста, проверьте, есть ли эта заявка в последнем обновлении на канале devel, а затем посмотрите, не сломалось ли что-нибудь еще в этом обновлении. Проверьте, упомянул ли разработчик конкретные вещи, на которые нужно обратить внимание при тестировании, и оставьте комментарий с подробным описанием ваших действий по воспроизведению бага. Если у вас есть права на запись в репозиторий, Вы можете перенести баг обратно в статус In Development (и открыть его заново) или перенести в Release Candidate как это описывается в документе issue tracking guidelines.

Первичная обработка баг-репортов

Первичное рассмотрение новых заявок проводится участником группы обеспечения качества (QA) с правами записи в папки репозитория. Если новая запись уже создана, внимательно изучите её и установите корректные маркеры, как это указано в руководстве issue tracking guidelines. Сразу же можно заняться подтверждением баг-репорта.

Если новый баг-репорт уже когда-то поступал, отметьте его маркером duplicate и закройте.