Извините, регистрация закрыта. Возможно, на событие уже зарегистрировалось слишком много человек, либо истек срок регистрации. Подробности Вы можете узнать у организаторов события.
Каждый отдел тестирования стремится к скорости и к качеству на скорости. Мы в Wrike пишем большое количество автотестов, запускаем их максимально быстро и стремимся при этом тратить минимальное время на их поддержку и документирование. Мы давно сотрудничаем с qameta.io в части фреймворков автоматизации и инструментов. Так мы уже больше года обкатываем новую систему TMS Allure.Server, которая хорошо ложится на наши представления о ведении тестовой документации и управлении автотестами. На Allure.Server митапе мы подробнее поговорим об этой системе, схемах использования и технических реализациях поверх этой системы.
Allure server - TMS система нового поколения, ориентированная на работу со всеми видами тестовой документации, автоматически встраивающая автотесты в документацию и оптимизирующая ведение тестовой документации и управление тестами.
Программа:
Я расскажу о том, как мы в Wrike с помощью Allure Server организовали процесс создания тестовой документации по принципу “документация от автотестов“.
Обычный процесс документирования может выглядеть так: QA Manual пишет чек лист -> расписывает тест кейсы -> отдаёт их на автоматизацию -> поддерживает документацию по мере изменения автотестов. Мы придумали, как можно упростить и удешевить эту цепочку, благодаря встраиванию QA и QAA в общий командный флоу работы, перейдя к единой системе документации.
Мы учимся использовать все артефакты тестирования в качестве документации о нашем продукте, активно используем аннотации кода автотестов, связывая их с соответствующими признаками в базе аллюр сервера, что позволяет нам работать с тест кейсами, чек листами, автотестами и даже интеграционными юнит тестами в единой упорядоченной экосистеме.
В автоматизации тестирования, к сожалению, не редки ситуции, когда часть автотестов временно перестает корректно работать. Возможно, это флаки тесты или на их работоспособность повлияла инфраструктурная проблема или баг – так или иначе нам приходится “выключать” такие тесты из запусков или их игнорировать.
Когда в проекте небольшое количество тестов и они гоняются не часто особых проблем нет, но с увеличением количества тестов и ежедневных запусков становится крайне необходимо выключать сломанные тесты как можно быстрее и уметь контролировать “выключенные” тесты.
Мы поговорим о том, как быстро “выключать” тесты, что такое тестовый карантин, зачем он нужен, расскажем, как он устроен в компании Wrike и причем тут Allure Server.
Подробнее о том, как добраться на митап: https://learn.wrike.com/spb-way/