Прошел второй открытый митап 24 ноября, который посвятили интеграционному тестированию. Были отличные доклады, и вот о чем поговорили: зачем и как использовать Cypress для интеграционного тестирования, и возможно ли добиться нуля ошибок по таким тестам?
ПРЕЗЕНТАЦИЯ
О спикере: Старший тестировщик в Райффайзенбанке, команда Cash Management. Опыт в автоматизации тестирования больше 3-х лет в крупных банках. За карьерный путь успела поработать как с BDD фреймворками, в том числе Akita, и поучаствовать в ее развитии, так и перейти полностью на сторону тестирования на стеке разработчиков — JavaScript/TypeScript, Java + Spring.
Считаю, что тестирование — это не просто генерация кейсов и поиск узких мест, но еще и огромный скоуп работ по проработке, разработке, доставке и поддержке.
О докладе: В нашей команде писали тесты в BDD стиле на русском языке (Selenium/Selenide + Cucumber + Java). Казалось бы, куда еще проще и прозрачнее для команды? Однако, как только мы лишились нескольких QA, и разработчикам пришлось писать и дорабатывать тесты, — наш инструмент стал стоппером в тестировании, и BDD тут ничем не помог. В докладе расскажу, как мы опустили тестирование на дно и начали его восстанавливать.
ПРЕЗЕНТАЦИЯ
О спикере: Работаю в компании Bercut с 2002. Начинал карьеру в телекоме: прошёл путь от сменного инженера до руководителя направления интеграционного тестирования. Был разработчиком, тестировщиком, менеджером продукта. Люблю заниматься тем, что приносит проблемы (и решать их), поэтому и пришёл в тестирование.
О докладе: Я работаю в компании Bercut, занимаюсь интеграционным тестированием биллинговых сервисов для телекома. В сентябре мы с командой прошли важную веху: получили ноль ошибок по результатам интеграционного тестирования для релиза новой версии биллинга для мобильного оператора. Ноль ошибок — значит, что бизнес-приёмка на стороне заказчика не нашла ошибок.
У нас ушло на это 2 года, и это получилось за счёт улучшений по нескольким направлениям: инструменты, экспертиза, документация, работа с заказчиком, команда. Улучшения различались по значимости: знать специфику и процессы заказчика – важно, перейти к новой шкале оценки сложности задач – опционально, а работать с мотивацией команды – критически важно.
Обо всём этом, а также, какой опыт из этого вынес я как руководитель тестирования, — расскажу в докладе.
О чем поговорили
Cypress для интеграционного тестирования. Зачем? Как?
Светлана Голдобина, РайффайзенбанкПРЕЗЕНТАЦИЯ
О спикере: Старший тестировщик в Райффайзенбанке, команда Cash Management. Опыт в автоматизации тестирования больше 3-х лет в крупных банках. За карьерный путь успела поработать как с BDD фреймворками, в том числе Akita, и поучаствовать в ее развитии, так и перейти полностью на сторону тестирования на стеке разработчиков — JavaScript/TypeScript, Java + Spring.Считаю, что тестирование — это не просто генерация кейсов и поиск узких мест, но еще и огромный скоуп работ по проработке, разработке, доставке и поддержке.
О докладе: В нашей команде писали тесты в BDD стиле на русском языке (Selenium/Selenide + Cucumber + Java). Казалось бы, куда еще проще и прозрачнее для команды? Однако, как только мы лишились нескольких QA, и разработчикам пришлось писать и дорабатывать тесты, — наш инструмент стал стоппером в тестировании, и BDD тут ничем не помог. В докладе расскажу, как мы опустили тестирование на дно и начали его восстанавливать.
Как мы добились нуля ошибок по итогам интеграционных тестов
Максим Плавченок, BercutПРЕЗЕНТАЦИЯ
О спикере: Работаю в компании Bercut с 2002. Начинал карьеру в телекоме: прошёл путь от сменного инженера до руководителя направления интеграционного тестирования. Был разработчиком, тестировщиком, менеджером продукта. Люблю заниматься тем, что приносит проблемы (и решать их), поэтому и пришёл в тестирование.О докладе: Я работаю в компании Bercut, занимаюсь интеграционным тестированием биллинговых сервисов для телекома. В сентябре мы с командой прошли важную веху: получили ноль ошибок по результатам интеграционного тестирования для релиза новой версии биллинга для мобильного оператора. Ноль ошибок — значит, что бизнес-приёмка на стороне заказчика не нашла ошибок.
У нас ушло на это 2 года, и это получилось за счёт улучшений по нескольким направлениям: инструменты, экспертиза, документация, работа с заказчиком, команда. Улучшения различались по значимости: знать специфику и процессы заказчика – важно, перейти к новой шкале оценки сложности задач – опционально, а работать с мотивацией команды – критически важно.
Обо всём этом, а также, какой опыт из этого вынес я как руководитель тестирования, — расскажу в докладе.
