Методология тестирования в СД
ЗАЧЕМ НУЖНО ТЕСТИРОВАНИЕ
Говоря простым языком, для улучшения качества и надёжности наших продуктов. Веб-разработка активно ведётся в нашей компании больше 4ёх лет, но процесса тестирования как такового не было. Разработчики пытаются сами протестировать свой функционал, написать юнит-тесты, но на обзоре всплывают какие-то недочёты. И хорошо, если на обзоре мы их заметим и поправим. Многие ошибки остаются для разработчиков незаметными и вызывают проблемы у клиентов.
ПРО МЕТОДОЛОГИЮ ТЕСТИРОВАНИЯ
Она описывает, как тестирование внедряется в каждый этап разработки.
Невозможно выявить стопроцентно все ошибки, но большую часть найти и поправить мы можем. И здесь важно участие тестирования во всех этапах, начиная с проектирования и заканчивая эксплуатацией программы.
Я называю тестировщиков — адвокатами пользователей. Им удаётся посмотреть на задачу с их точки зрения, и ещё на этапе проектирования задать много вопросов заказчикам: как должен работать новый функционал. Когда тестировщики знают все нюансы, как изначально планировалось реализовать задачу, то и тестируют они её качественнее.
Процессы разработки, в которых участвует команда тестирования:
1. Реализация нового функционала
- Формализация пользовательского сценария
- Ручное тестирование
2. Релиз
- Автоматизированное регрессионное тестирование
- Нагрузочное тестирование
3. Пост-релиз
- Ручное тестирование на выявление ошибок
- Приоритизация сценариев
- Написание регрессионных тестов
4. Нагрузочное тестирование
Текущая версия будет уточняться и дополняться — это начальная база.
КАКИЕ ТЕСТИРУЕМ ПРОЕКТЫ
Sdvor.com
1. Ручное тестирование
В команду сдвора внедрён ручной тестировщик — Александр Баклушин. Саша:
- тестирует релиз перед выкатом в прод и пост-релиз;
- находит баги и заводит по ним задачи, описывая фактическое и ожидаемое поведение системы;
- прикладывает видео и скрины ошибок в консоле;
- просматривает работу функционала в разных браузерах, используя BrowserStack, что также помогает выявлять проблемы сайта.
Большую часть пользовательских сценариев для сдвора написал он. Также помогает с приоритетами покрытия сценариев автотестами (помогает распределить очерёдность).
Так как Саша каждый день тестирует сайт, он знает, какая логика ломается чаще всего, и что в первую очередь нужно покрыть автотестом. Пользовательские сценарии сохраняются в Test Managment For Jira:
Вот пример одного сценария:
2. Автоматизированное тестирование
Реализован новый проект автотестов. В данный момент 100 пользовательских сценариев покрыто автотестами. Прогон происходит при деплое стейджа и мастера сайта, и когда тесты заваливаются, то в канал отправляются сообщения, описывающие какие сценарии и на каком шаге что-то пошло не так. Так же прикладывается скриншот браузера в тот момент, когда тест не прошёл. Это помогает разобраться в причинах завала теста.
Автотесты помогают находить поломку сценариев, которую можно даже не заметить вручную. Они зафиксированы на корректном поведении системы и любые отклонения сразу видны. Конечно, бывает, что они заваливаются из-за изменений логики на сайте или хрупкости теста, поэтому необходима поддержка проекта автотестов.
3. Нагрузочное тестирование
На стейдже ежедневно проходит нагрузочное тестирование, основанное на сценарии добавления и удаления позиции из корзины. Время прогона — час, количество потоков — 200. Поначалу этот тест заваливался на ошибках. Он настроен так: если пользователь наткнулся на ошибку, он уходит: примерно как в жизни.)
И тест вместо часа мог завалиться за 10 минут. Об ошибках сообщали команде, и ребята исправляли работу сервисов, на которых заваливался тест. На графиках можно увидеть разницу в производительности в феврале и в мае:
Жёлтая линия на графике — это пользователи. На первом видно, что постепенно её уровень снижается, так как пользователи уходят с сайта из-за ошибок. На втором графике пользователи за 15 минут увеличиваются до 200, и в течение 45 минут сайт выдерживает нагрузку. Тестирование проходит без ошибок. Всем пользователям удаётся выполнить все свои запросы. Максимальное время ответа снизилось с 19 секунд до 1,5 секунды.
На сдворе меняли карточку товара и проводили сравнительный нагрузочный тест старой и новой карточки. Так же удалось найти проблемные места и исправить их на ранней стадии.
4. Пользовательские сценарии
В данный момент внедряем формализацию пользовательского сценария нового функционала на этапе проектирования задач сайта. Здесь у нас возникают трудности: задачи поступают тестировщику поздно: в тот же момент, что и команде разработки. Разработчики реализуют функционал без согласованного пользовательского сценария, и в итоге сценарии тестировщики пишут только для тестирования. Также на согласование сценариев уходит много времени.
Ennergiia.com
С марта тестировщик Алёна Петрова внедрена в команду Ennergiia: пишет пользовательские сценарии и тестирует вручную новый функционал на стейдже. Это значительно снизило количество ошибок на проде.
На сайте Ennergiia пользовательские сценарии удаётся подготавливать заранее, и уже видны результаты. Разработка проходит быстрее, и на обзоре возникает меньше вопросов, так как все тонкие места реализации обсудили и спроектировали заранее.
В конце апреля команда автоматизаторов переключилась на покрытие сайта автотестами, так как на проекте всего 22 сценария покрыто автотестами.
TMS
В конце марта ручной тестировщик Татьяна Березенцева внедрена в команду TMS. Так как на проекте часто меняются бизнес-правила, покрывать автотестами пока нет смысла. Когда проект перейдёт в стабильную стадию, то по подготовленным Таней сценариям покроем его, ориентировочно стартуем в июне.
Зелёная Миля
В конце апреля Анастасия Зырянова подключилась к ручному тестированию новых фич проекта Зелёная Миля. Хотим автоматизировать часть сценариев по этому проекту.
В планах на этот год внедрять тестирование в проекты: Хайбрис, EWM, Айронмэн, Скоринг, EDI, Поиск. Проекты разные и требуются разные виды тестирования: например, «Поиск» предполагает только нагрузочное, «EDI» — контрактное тестирование.
КТО ВХОДИТ В КОМАНДУ ТЕСТИРОВАНИЯ?
По методологии ручные тестировщики внедряются в команду разработки. Это те люди, которые в курсе всех особенностей проекта, а также хранители документации.
Команда тестирования — тестировщики-автоматизаторы, которые по готовым сценариям покрывают функционал проекта автотестами, и в будущем также будут подготавливать и проводить нагрузочное тестирование.
Команда тестирования: Ксения Кузнецова, Анастасия Зырянова, Анна Соколова. Команда полностью обновила состав в феврале, и все силы были брошены на автоматизацию сценариев сайта sdvor.com. Все участники учились практически с нуля писать автотесты и хорошо прокачались за это время. Команда сплотилась, мы научились работать вместе, и скорость написания автотестов заметно увеличивается.
Мы идём к тому, чтобы тестировщики были универсалами и могли сами поддерживать автотесты на проекте. Алёна Петрова — ручной тестировщик Ennergiia, может сама разобраться и починить завалившийся тест. И начинает писать новые, например, тесты на фильтры уже на MR. Думаю в будущем удастся ручных тестировщиков Сашу Баклушина и Таню Березенцеву также научить поддерживать и разрабатывать автотесты.
Таким образом, мы не просто команда тестирования: у нас школа автоматизаторов и нагрузочников.
КАК ПРОХОДИТ ТЕСТИРОВАНИЕ?
На этот вопрос как раз отвечает методология тестирования:
1. Реализация нового функционала
1.1. Зачастую на обзоре выясняется, что программист и заказчик неправильно друг друга поняли. Причина: постановка задач не проработана, и разработчик вынужден сам продумывать логику работы своей программы:
- разработчик не продумывает весь вариатив ветвлений логики;
- реализует не так, как хотел бы заказчик.
А если мы будет покрывать такой код автотестами, то будет двойная работа: при переписывании кода придётся переписывать ещё и тесты. Когда задача описана скупо, то совершенно непонятно, как её тестировать. Чтобы устранить эту проблему, решили внедрять тестирование на этапе проектирования функционала.
Перед тем, как задача поступает разработчику, тестировщик подготавливает пользовательские сценарии и согласовывает их с заказчиком. Возможно это не быстрый этап, но это позволяет:
- лучше продумать новый функционал;
- посмотреть на него с разных сторон;
- в дальнейшем избежать переписывание кодовой базы.
Далее по готовым сценариям подготавливается дизайн или задача берётся в разработку.
Готовые сценарии позволяют дать более точную оценку по объёму реализации задач, которые берут в спринт. По пользовательским сценариям удобнее писать юнит-тесты. По ним проверяется функционал на стейдже и разрабатываются автотесты.
1.2. Когда задача реализована разработчиком, она попадет в колонку «Тестирование». Тестировщик проверяет корректность работы функционала. Если находит ошибки, то возвращает задачу в работу, прикладывая список ошибок. Функционал не релизится до тех пор, пока ошибки не исправлены.
2. Релиз
2.1. Автоматизируется тестирование по наиболее критичным сценариям. При деплое изменений проекта в стейдж и прод производится прогон всех регрессионных тестов, что позволяет выявить ошибки.
2.2. При реализации функционала, который может влиять на производительность системы, проводят нагрузочное тестирование. Для него необходимо подготовить сценарии нагрузки. Нагрузка по сценариям производится на нагрузке как у прода: необходимо отследить, что система не стала отвечать медленнее. Также нагрузочное тестирование позволяет выявлять узкие места, которые можно оптимизировать.
3. Пост-релиз
3.1. На проде проводится регрессионное тестирование по чек-листу.
3.2. Ручной тестировщик составляет чек-лист регрессионного ручного тестирования. Выделяет наиболее критичные моменты в функционале, согласует критичность и приоритет сценариев, формирует список сценариев для дальнейшего покрытия автотестами.
3.2. Написание автоматизированных регрессионных тестов не является блокирующим, и вручную протестированный проект по подготовленным сценариям покрывается автотестами.
На новом проекте, где часто меняются бизнес-правила, нет смысла автоматизировать тестирование. Достаточно ручного тестирования, ведения чек-листа и поддержания в актуальном состоянии сценариев. Когда проект переходит в стабильную стадию, тогда появляется необходимость зафиксировать корректную работу функционала автотестами.
Ручной тестировщик внедряется в команду, присутствует на собраниях и пребывает в курсе всех изменений сайта. Команда разработчиков автотестов и нагрузочного тестирования может подключаться к задачам разработки, если нужно. Для них нет необходимости всегда быть в курсе событий, так как достаточно сценариев проекта.
4. Нагрузочное тестирование, как отдельный процесс
Производится для достижения нескольких целей:
- измерение времени выполнения выбранных операций при определённых интенсивностях выполнения этих операций;
- определение максимального количества пользователей, которые могут работать с системой;
- определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций);
- исследование производительности и поведения системы на высоких, предельных, стрессовых нагрузках;
- выявление узких мест инфраструктуры, либо не оптимальной её настройки.
В планах у нашей команды: проработать контрактное тестирование для проверки межсервисного взаимодействия. Но мы решили не распыляться, и весь упор в данный момент сделать на автотесты.