Просмотр исходного текста страницы Регламент тестирования

[[Category:Регламенты ROSA]]

=== Политика ===
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.

До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.

Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.

==== Классификация обновлений по степени опасности ====
<blockquote>
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк
</blockquote>

Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.

;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. 
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. 
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.

==== Задача ====
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.

==== Общие положения ====
* Запрос на обновление пишется в багзилле 
* Все сообщения пишутся на английском языке.
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774

==== Срок тестирования ====
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.

=== Процедура тестирования ===

==== Требования к запросу на обновление ====
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).
# Описание обновления должно содержать все изменения, которые нужно протестировать.
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.

==== Тестирование установки пакетов ====
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt>
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.
## Репозиторий подключается как репозиторий с обновлениями.
## Запускается стандартная процедура обновления.
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.

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

==== Тестирование на функционирование и устойчивость системы после обновления ====
При тестировании системы проверяется:
# Стабильность и внешний вид обновленной системы после перезагрузки.
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста  Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)
# Работа URPMI — дальнейшее обновление пакетов.
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима
# Работа системы поиска по содержимому офисных файлов

==== Тестирование запуска и работы связанных с обновлением приложений ====
Проверяются:
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt>
# Регрессии в локализации графического интерфейса и страниц справки.
# Для тестирования браузеров в дополнение к  https://webglsamples.org/aquarium/aquarium.html применяются.
## Тест html5 https://html5test.com/  (сравнить результат до и после обновления, не должно быть регресса)
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0  https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ 
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html
## Тестирование печати
## Тестирование установки браузера по-умолчанию из настроек

В случае:
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление 
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.

==== Тестирование изменений ====
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.

Включает себя
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.
# Воспроизведение измененных обновлений особенностей по их описанию.

Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.

В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.

==== Расширенное тестирование ====
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. 
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing
# В пятницу, руководитель QA:
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию
## Проверяет, дошли ли обновления до зеркал
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами 
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)

=== Завершение тестирования ===

==== Положительный результат тестирования ====
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:
## Название пакета с исходниками (src.rpm).
## Версию пакета.
## Отчет о тестировании (advisory).
## Надпись «QA verified».
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.

==== Отрицательный результат тестирования ====
# При отклонении пакета ставится индикатор отклонения QA «-»,
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».