Книга рассказывает, как выстроить тестирование, чтобы не просто вылавливать баги, а избежать их появления. Она нам очень понравилась, так что мы решили на правах старожилов поддержать традицию конспектов на Хабре и выложить самые интересные тезисы.
Waterfall
Все начиналось с тестирования при методологии Waterfall. Этот этап характерен тем, что тестирование является активностью только одного участника команды (угадайте, кого). Никто кроме тестировщика ничего не знает о тестовой стратегии и не имеет доступа к тест-кейсам и чек-листам. Задачи летают по команде как шарик в пинг-понге. Этот период характерен долгими релизами.
Agile
В работе по методологии Agile тестирование становится ответственностью всей команды. Это значит, что не только тестировщики, но и разработчики находят и решают проблемы. Этот этап отличается частыми релизами и быстрой обратной связью.
DevOps
Теперь на тестирование влияют саппорт, аналитика, инфраструктура, мониторинг. Меняются границы и характер тестирования. Информация теперь поступает к команде из разных каналов: мониторинга, заявок от службы поддержки, аналитических отчетов. При этом тестирование должно быть надежным, но не препятствовать быстрым релизам.
Автор утверждает, что DevOps намного масштабнее, чем CI. CI фокусируется на технических практиках, которые ускоряют написание кода (например, система контроля версий, unit-tests, частые коммиты) а DevOps – на организационных изменениях (в частности, поддержка более тесного сотрудничества между типами работников, занимающихся поставкой ПО: аналитиками, support, командой разработки).
Без Agile не возникло бы культуры DevOps. Люди должны мыслить гибко, чтобы прийти к DevOps, основной целью которого является надежность и частота релизов. При этом в докладах о DevOps часто упускается тема тестирования.
Основной тезис Катрины состоит в том, что тестировать нужно всегда и на каждом этапе – от начала работы над задачей до последнего релизного коммита.
Объём работы получается очень большим. Возникает вопрос, как организовать все тестирование и не сойти с ума.
DevOps – больше, чем просто гибкое тестирование. Идеология DevOps предполагает отлично отлаженный процесс не только быстрого развертывания новой версии в продакшене или отката на предыдщую, но и столь же отлаженную коммуникацию между командами dev и operation.
Проверить себя можно по ссылке – здесь автор объясняет, почему выделены именно эти пункты и чем они важны.
Чем чаще люди общаются, тем больше понимают, чем занимаются коллеги и как им можно помочь. Поэтому Катрина предлагает им чаще обсуждать тестирование. Это можно сделать несколькими способами:
Облегчить тестирование в продакшне помогут следующие инструменты:
В этот конспект не вошло много интересного. Книга хорошо написана, рекомендуем ее тестировщикам, которые задумались о тестировании на DevOps-проектах.
Напоследок пара полезных ссылок:
Как менялись подходы к организации тестирования:
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-проектах.
Напоследок пара полезных ссылок: