Делимся видео и слайдами с прошедшего митапа, посвящённого автотестированию на Go.
О нашем стеке и контексте рассказывал в анонсе.
Go, Allure и HTTP, или Как мило тестировать HTTP-сервисы на Go
Спикер: Сергей Макаров, старший Go-разработчик, Ozon.
Слайды
Как подружить QA и разработку через применение практики хранения тестов в коде
Спикер: Василий Юдин, инженер в команде Авито.
Слайды
Круглый стол «Профессия QA»
Сергей Макаров (Ozon), Василий Юдин (Авито), Сергей Никифоров (Skyeng), Евгения Завражная (Mirantis) обсудили, как войти в профессию, как построить карьерный путь, какие сложности встречаются при смене профессии в процессе входа в QA. Модерировал встречу Игорь Любин @ilyubin(Ozon).
Спасибо всем, кто пришёл и смотрел трансляцию, увидимся ещё!
Если интересно больше:
Отчёт с первого Ozon Tech QA Meetup.
Следите за анонсами следующих митапов здесь и в нашем канале.
ShevaQA
Спасибо организаторам, было круто! Но остался вопрос: было обсуждение о том, что проблема многих команд в том, что в начале релиза QA несколько дней сидит без задач, а в конце спринта загибается от нагрузки и выгорает. Насколько я понял, в ваших обсуждениях решения данной проблемы были так или иначе связаны с автоматизацией. А что делать командам, которые имеют только мануального тестировщика? Спасибо!
ilyubin
Спасибо за вопрос.
Ситуация с одним мануальным тестировщиком нормальная и вполне рабочая. Могут быть разные варианты:
Поговорить с командой — рассказать о проблеме, о нагрузке, о выгорании. Придумать вместе решение.
Проговаривать на планировании спринта, чтобы что-то катить как можно раньше. Катить и тестировать фичи — сразу как готово. Постараться размазать выкатки и тестирование фич по всему спринту.
Можно даже что-то неважное оставлять без тестирования (если ресурса не хватает) и принимать риск этого.
Размазать часть проверок по другим членам команды. Сделать BVT (build verification test) сценарий и попросить всех членов команды проходить его при выкладке.