Конспект книги Practical Guide to Testing in DevOps, Katrina Clokie
Книга рассказывает, как выстроить тестирование, чтобы не просто вылавливать баги, а избежать их появления. Она нам очень понравилась, так что мы решили на правах старожилов поддержать традицию конспектов на Хабре и выложить самые интересные тезисы.
Как менялись подходы к организации тестирования:
Waterfall
Все начиналось с тестирования при методологии Waterfall. Этот этап характерен тем, что тестирование является активностью только одного участника команды (угадайте, кого). Никто кроме тестировщика ничего не знает о тестовой стратегии и не имеет доступа к тест-кейсам и чек-листам. Задачи летают по команде как шарик в пинг-понге. Этот период характерен долгими релизами.
Agile
В работе по методологии Agile тестирование становится ответственностью всей команды. Это значит, что не только тестировщики, но и разработчики находят и решают проблемы. Этот этап отличается частыми релизами и быстрой обратной связью.
DevOps
Теперь на тестирование влияют саппорт, аналитика, инфраструктура, мониторинг. Меняются границы и характер тестирования. Информация теперь поступает к команде из разных каналов: мониторинга, заявок от службы поддержки, аналитических отчетов. При этом тестирование должно быть надежным, но не препятствовать быстрым релизам.
Тестирование в эпоху DevOps и CI
Автор утверждает, что DevOps намного масштабнее, чем CI. CI фокусируется на технических практиках, которые ускоряют написание кода (например, система контроля версий, unit-tests, частые коммиты) а DevOps – на организационных изменениях (в частности, поддержка более тесного сотрудничества между типами работников, занимающихся поставкой ПО: аналитиками, support, командой разработки).
Без Agile не возникло бы культуры DevOps. Люди должны мыслить гибко, чтобы прийти к DevOps, основной целью которого является надежность и частота релизов. При этом в докладах о DevOps часто упускается тема тестирования.
Основной тезис Катрины состоит в том, что тестировать нужно всегда и на каждом этапе – от начала работы над задачей до последнего релизного коммита.
Объём работы получается очень большим. Возникает вопрос, как организовать все тестирование и не сойти с ума.
С чего начать тестировать
- Понять, как сейчас устроен процесс тестирования на проекте.
- Организовать ретроспективу стратегий тестирования всей командой и ответить на вопрос, что мы сейчас тестируем и почему. Может оказаться, что участники одной команды по-разному ответят на вопросы о процессе, а это неправильно.
DevOps – больше, чем просто гибкое тестирование. Идеология DevOps предполагает отлично отлаженный процесс не только быстрого развертывания новой версии в продакшене или отката на предыдщую, но и столь же отлаженную коммуникацию между командами dev и operation.
10 критериев, которые помогут проверить, есть ли Agile в вашем тестировании:
- Вся команда четко знает, что нужно тестировать, работая над той или иной user story.
- У всех единое понимание бизнес-требований.
- Когда вы обсуждаете user story, у вас есть ответ на вопрос «Как мы будем это тестировать?»
- Каждый в команде знает, как запускать автотесты и где смотреть результат.
- Вы заранее обсуждаете, что будете автоматизировать и на каком уровне, чтобы не дублировать тесты на разных уровнях. (Этот пункт показался нам самым важным).
- Ваши тестовые скрипты версионированы и хранятся вместе с исходным кодом, так как тесты являются частью ПО.
- У вас нет багов в беклоге, потому что вы исправляете ошибки, как только вы их найдете, а не просто регистрируете.
- Нет простоев в работе CI сервера.
- Во время митинга непонятно, кто является разработчиком, а кто – тестером.
- Ваша команда может оценить качество продукта. Всем понятно, как устроен процесс тестирования на проекте.
Проверить себя можно по ссылке – здесь автор объясняет, почему выделены именно эти пункты и чем они важны.
Практики сотрудничества в DevOps
Чем чаще люди общаются, тем больше понимают, чем занимаются коллеги и как им можно помочь. Поэтому Катрина предлагает им чаще обсуждать тестирование. Это можно сделать несколькими способами:
- Ревью чек-листов аналитиками и саппортом. Вовлечение в тестирование на ранних стадиях могут повысить качество релизов.
- Тестирование в парах: тестировщик и аналитик, саппорт и разработчик.
- Ротация сотрудников между командами dev и саппортом.
- Додзё (в рамках разработки ПО) – среда, где люди могут учиться и практиковать свои навыки развития вместе: мастер-классы, обмен знаниями.
Тестирование в продакшне
Облегчить тестирование в продакшне помогут следующие инструменты:
- Мониторинг, настроенный так, чтобы там можно было легко найти и опознать проблему,
- Оповещения при помощи различных каналов связи: например, сообщение в мессенджер, если сервер упал, или email, когда память закончилась,
- Аналитика (например, Google Analytics), говорящая о том, сколько пользователей используют функционал,
- Логирование, сделанное читаемым.
- Обратная связь от клиентов – отзывы в сторах, формы для обратной связи в веб-приложениях.
P.S.
В этот конспект не вошло много интересного. Книга хорошо написана, рекомендуем ее тестировщикам, которые задумались о тестировании на DevOps-проектах.
Напоследок пара полезных ссылок: