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

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

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

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

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

Неподтверждённые баг-репорты получают метку needs confirmation, чтобы их можно было найти через фильтр. Посмотрите этот список и попробуйте воспроизвести ошибки, которые в нём перечислены. Если нужно, то дополните баг-репорт новой информацией, прикрепите лог-файлы или чем-то иным, что может помочь разработчикам. Можно указать в комментариях модель Вашего устройства, версию сборки, канал разработки и удалось ли воспроизвести ошибку.

Если у Вас есть права на запись в репозиторий, можно поменять ярлык 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 и закройте.