Как устроено тестирование фронтенда в Яндекс.Маркете и почему мы отказываемся от еженедельных релизов

[monochromer]

Контура

Может, все-таки "Контуры"?

[martin_wanderer]

Бесполезно. Хоть норма и договорЫ и контурЫ, но процесс изменения языка не остановить. Рано или поздно очередные Даль с Розенталем пометят форму с Ы как архаичную

[namikiri]

И не роспись, а подпись. Роспись — это хохлома.

[Wolonter]

Проверку релиза мы начинаем с проверки автотестов и скринтестов.

То есть задача в релиз может попасть с красными тестами? Зачем допускать такие задачи к релизу?

Кстати, а какой процент стабильности тестов? Сколько упадут случайно на прогон?
Сколько времени занимает полный ручной регресс? Как часто он используется?

Ручной тестировщик разбирает упавшие тесты? Почему этого не делает программист? Как вы пришли к этому решению?

Наша цель выкатить не менее 5 релизов

Правильно ли я понял, что 5 в неделю?

[serzh52]

Да не менее 5 релизов в неделю.
Не все тесты замоканы, по возможности отлавливаем и мокаем, из за разных обстоятельств попадают в релиз(нестабильность бэков/учения итд). Падения тестов разбирает, да, тестировщик и далее уже отдаёт програмисту конкретные задачи на починку.
Раз в неделю примерно гоняем полный регресс, занимает около 4 часов.
Спасибо за ваш комментарий.

[Wolonter]

А какой процент стабильных тестов?

И ещё. Если тестировщик дежурит и занимается релизами — на сколько он выпадает из тестирования текущих задач? Это не проблема?

[theasmoth]

вероятно раз в день если речь идет про 8 часов на релиз

[knstqq]

> То есть задача в релиз может попасть с красными тестами? Зачем допускать такие задачи к релизу?
Нельзя сделать продукт без багов. Если стало в среднем лучше — это хороший релиз.

[tundrawolf_kiba]

То есть задача в релиз может попасть с красными тестами? Зачем допускать такие задачи к релизу?

Как уже верно сказали — все отловить и починить невозможно в разумные сроки. Вполне нормальный критерий для релиза — когда по сравнению с предыдущей неделей количество новых багов не растет и все новый не выше медиума по severity/priority.

Ручной тестировщик разбирает упавшие тесты? Почему этого не делает программист? Как вы пришли к этому решению?

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

[Wolonter]

Постойте, я же не говорю про отсутствие багов. Я говорю про красные тесты. Разве перед выпуском фичи нельзя исправить ошибки, уже найденные тестами и поднять тесты? Или с таким темпом это проблематично?

[tundrawolf_kiba]

С пятью релизами в неделю это выглядит даже не проблематично, а за гранью возможного, но вариант — исправить все дефекты/ошибки найденные тестами — может быть просто не доступен по ресурсам. У нас же ограниченное число разработчиков. Пока мы будем ждать пока разработчики пофиксят вообще все что найдено — может пройти достаточно много времени во время которого пользователям придется мириться с более критичными дефектами, чем те, которые осталось пофиксить.

[serzh52]

Конечно, если падения вызваны багом их правят до релиза. Но иногда падения вызваны нестабильностью бэков/учениями итд. и в таком случае, просмотрев глазами падения, задерживать релиз нецелесообразно

[Wolonter]

Кажется, я понял, где у нас возникло недопонимание. Есть этапы: тест задачи и тест релиза. Мой вопрос был — почему красными тестами не занимаются на этапе теста задачи?

В том, что нестабильные тесты не должны держать релиз, я с вами соглашусь. Кстати, вы так и не сказали, сколько их.

[serzh52]

Ими занимаются если они падают по причине изменений в задаче, обычно они зелёные, но бывают что падают по не зависящим от тестируемого функционала причинам и в таком случае мы их оставляем.

[serzh52]

По не стабильным около 30% не замоканых

[Entropius]

Что такое «стрельба на разладку»? И расскажите, пожалуйста, какие ошибки трекаете во время релиза.

[serzh52]

Они нужны чтобы определить пределы производительности, подробнее можно посмотреть в докладе Алексея Лавренюка о нагрузочном тестировании.

[CyberLight]

А бывает так, что какая либо задача, тесты на которую не стабильны, являлась связной с несколькими другими задачами и релиз приходилось откладывать? Или вы избегаете релизить такой пирог и в один релиз уходит базовая задача, которая подготавливает плацдарм (и не обязательно визуальный) для следующих N задач, а зависимые уходят в другой релиз?

[serzh52]

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

[CyberLight]

Спасибо за ответ )

[aklepikov]

Интересно, что нет практики TDD — это осознанное решение или просто ещё до этого этапа процесс разработки не дошёл? И если осознанное решение, то что по каким причинам?

[serzh52]

Да, это осознанный шаг из за экспериментов.

[Vorchun]

serzh52 а расскажите, пожалуйста, подробнее как технически устроены скрин тесты. Особенно интересуют мобилки разные.

[serzh52]

Спасибо, за интерес, но тут в 2 словах не расскажешь, тут в пору отдельную статью делать. Если прям кратко, используем фреймворк gemini, который является надстройкой над селениумом и юзает те же методы, тесты пишутся на js. Сравниваются 2 скриншота элемента продакшн среды и релиз кандидата. Если есть отличие при наложении они подсвечиваются. Очень удобно для тестирования юая. На счёт мобилок, мы используем только для мобильной версии маркета, в разных разрешениях, которые настраиваются в канфиге. В приложении не используется скринтестинг, пока что.

[Vorchun]

Статья с реальным опытом, а особенно интересует проверка на мобильных устройствах (смартфон, планшет) на разных ОС (android, ios), была бы очень и очень интересной.

Мы смотрим сейчас BackstopJS. Но он не позволяет сделать проверки по всему зоопарку устройств.