суббота, 20 января 2018 г.

Как поднимали тестирование с нуля в Dodo плюс Feature toogle Яндекса


Ссылка на youtube

Сложно дать название блог-посту, когда понравилось несколько докладов Smile :)
Мне кажется, название «Dodo Pizza QA Meetup» не раскрывает сути, так что получилось длинновато.

Не уверена, где именно был этот митап, вроде в Москве. Жаль, что не попала вживую, довольно интересно получилось! Ребята молодцы, что всех собрали и поделились своим опытом. Мне видео порекомендовал нам PM посмотреть, сказал, что интересно. Подтверждаю, интересно!

Основных доклада два:


Алиса в стране QA. Как мы меняли регресс, чтобы сделать его быстрым и качественным
Юлия Ковалева, DoDo

Прикольный рассказ! Юлия не стесняется говорить о тех проблемах, о которых предпочитают молчать. Когда отдельно есть команда разработчиков и аналитиков, и отдельно — команда QA, которая не ходит на митинги, планирования, и вообще не в теме того, что нынче важно для Заказчика. Кажется таким очевидным, что так быть не должно, но ведь так и есть. До сих пор, во многих компаниях. И вот им как раз этот доклад очень поможет.


Юлия сама пришла в компанию не так давно, около 4 месяцев назад (до проведения митапа, а он был в ноябре прошлого года). И вот пришла, увидела весь этот раздрай, начала внедрять изменения.

Кстати, я считаю, в таких случаях бывает очень полезен взгляд со стороны. Потому что обычно команды очень загружены. Так, мы выпустили релиз, его тестировать 3 дня, а вот мы изменение добавили, срочно ретест! В итоге тестировщики всегда нагружены, разработчики нагружены, все нагружены, всем надо срочно делать текучку и просто некогда подумать о том, как лучше. А если и подумать, «как могло бы быть», то все равно: а кто будет делать то?

Вот у ребят раньше могло проползти изменение в мастер-ветку из серии «ну я тут чуть-чуть покоммитил, что такого то?». В итоге у тестировщиков все разваливается к чертям и они тратят кучу времени, сидя с аналитиком и думая, что тут вообще происходит.

Теперь команды, которые хотят регресс, встают в очередь, как в супермаркете. И честно ждут. А ребята прикидывают, сколько времени уйдет на регресс. В среднем это 2-3 дня до сих пор. Но они также активно внедряют автоматизацию. И тут, кстати, помогла эта очередь. Тестировщики пришли и сказали: «Смотрите, мы сможем протестировать ваши изменения только через неделю. У нас и автоматизаторы сейчас тестя вручную. Помогите нам с автотестами? Быстрее тестировать будем!». Команда подключилась и все теперь ребятам помогают.

По автоматизации тоже свои грабли, проблемы, решения. Например, хотелось заавтоматизировать сразу кассу, как самый главный функционал, но ее автоматизировать сложно. И посему начали с отчетов. Это проще (нет десяти разных GUI), но сильно помогает, потому что вручную это все делать — тлен и серость.

В общем, очень живой и интересный доклад получился, посмотрите обязательно! Примерно в 15 минут начинается, но на самом деле первые 15 минут тоже интересные, так что смотрите сначала ツ


Тестирование в продакшене. Владислав Долбилов, auto.ru (yandex)

Если Юлия — тимлид команды QA, то Владислав — тимлид команды разработки. Он рассказывал про четыре разные штуки, но мне больше всего понравились две:

1. Goreplay

https://github.com/buger/goreplay

Эта утилита помогает забирать реальный трафик с PROD и направлять на TEST. Это помогает иметь актуальную БД, проверять сразу запросы, не просто близкие к проду, а вполне реальные. Ну и бесплатное нагрузочное тестирование. А то, когда тестировщики что-то тестят, они обычно так, пару-тройку запросов пошлют и все. А на карточке товара отображается в том числе количество просмотров. И оно на тесте вообще не похоже на реальные картинки.

У нас немного другая система, так как не мы контролируем продакшен. Мы делаем коробочное решение и отдаем сами билды. Конечно, трафик с прода мы не получим. Но! Его могут получить тестировщики заказчика. И настроить тестирование на PREDPROD. Вообще очень интересная тема, стоит поизучать и придумать, как внедрить такую штуку к нам в том или ином виде.


2. Feature toogle

Feature toogle — возможность включать и выключать фичу. Это удобно, так как не приходится во время разработки поддерживать отдельный фича-бранч. Все же понимают, что это значит: постоянно мерджить с транком, тратить на это кучу времени.

А так красота: сделал фичу, влил в мастер выключенной и сидишь, колбасишь мясо. Как доделал, включил и пусть тестируют. Удобно то, что в проде сбойную фичу можно отключать без отката всего релиза.

Минусы — в тестировании надо проверять все возможные комбинации включения и выключения разных фич. Но штука все равно интересная.

******

Последним был доклад от Альфа-лаборатории, в целом тоже интересный, но тут подкачал звук, по крайней мере у меня он постоянно прерывался и слушать было тяжело. Ну и сам доклад немного не про меня, поэтому отдельно его расписывать не буду. Но в целом  живенький и посмотреть для общего развития тоже полезно.

Вот! Если кратко: видео классное, рекомендую к просмотру ツ

Комментариев нет:

Отправить комментарий