Книга рассказывает, как выстроить тестирование, чтобы не просто вылавливать баги, а избежать их появления. Она нам очень понравилась, так что мы решили на правах старожилов поддержать традицию конспектов на Хабре и выложить самые интересные тезисы.

Как менялись подходы к организации тестирования:

Waterfall
Все начиналось с тестирования при методологии Waterfall. Этот этап характерен тем, что тестирование является активностью только одного участника команды (угадайте, кого). Никто кроме тестировщика ничего не знает о тестовой стратегии и не имеет доступа к тест-кейсам и чек-листам. Задачи летают по команде как шарик в пинг-понге. Этот период характерен долгими релизами.

Agile
В работе по методологии Agile тестирование становится ответственностью всей команды. Это значит, что не только тестировщики, но и разработчики находят и решают проблемы. Этот этап отличается частыми релизами и быстрой обратной связью.

DevOps
Теперь на тестирование влияют саппорт, аналитика, инфраструктура, мониторинг. Меняются границы и характер тестирования. Информация теперь поступает к команде из разных каналов: мониторинга, заявок от службы поддержки, аналитических отчетов. При этом тестирование должно быть надежным, но не препятствовать быстрым релизам.

Тестирование в эпоху DevOps и CI

Автор утверждает, что DevOps намного масштабнее, чем CI. CI фокусируется на технических практиках, которые ускоряют написание кода (например, система контроля версий, unit-tests, частые коммиты) а DevOps – на организационных изменениях (в частности, поддержка более тесного сотрудничества между типами работников, занимающихся поставкой ПО: аналитиками, support, командой разработки).

Без Agile не возникло бы культуры DevOps. Люди должны мыслить гибко, чтобы прийти к DevOps, основной целью которого является надежность и частота релизов. При этом в докладах о DevOps часто упускается тема тестирования.

Основной тезис Катрины состоит в том, что тестировать нужно всегда и на каждом этапе – от начала работы над задачей до последнего релизного коммита.

Объём работы получается очень большим. Возникает вопрос, как организовать все тестирование и не сойти с ума.

С чего начать тестировать

• Понять, как сейчас устроен процесс тестирования на проекте.
• Организовать ретроспективу стратегий тестирования всей командой и ответить на вопрос, что мы сейчас тестируем и почему. Может оказаться, что участники одной команды по-разному ответят на вопросы о процессе, а это неправильно.

DevOps – больше, чем просто гибкое тестирование. Идеология DevOps предполагает отлично отлаженный процесс не только быстрого развертывания новой версии в продакшене или отката на предыдщую, но и столь же отлаженную коммуникацию между командами dev и operation.

10 критериев, которые помогут проверить, есть ли Agile в вашем тестировании:

1. Вся команда четко знает, что нужно тестировать, работая над той или иной user story.
2. У всех единое понимание бизнес-требований.
3. Когда вы обсуждаете user story, у вас есть ответ на вопрос «Как мы будем это тестировать?»
4. Каждый в команде знает, как запускать автотесты и где смотреть результат.
5. Вы заранее обсуждаете, что будете автоматизировать и на каком уровне, чтобы не дублировать тесты на разных уровнях. (Этот пункт показался нам самым важным).
6. Ваши тестовые скрипты версионированы и хранятся вместе с исходным кодом, так как тесты являются частью ПО.
7. У вас нет багов в беклоге, потому что вы исправляете ошибки, как только вы их найдете, а не просто регистрируете.
8. Нет простоев в работе CI сервера.
9. Во время митинга непонятно, кто является разработчиком, а кто – тестером.
10. Ваша команда может оценить качество продукта. Всем понятно, как устроен процесс тестирования на проекте.

Проверить себя можно по ссылке – здесь автор объясняет, почему выделены именно эти пункты и чем они важны.

Практики сотрудничества в DevOps

Чем чаще люди общаются, тем больше понимают, чем занимаются коллеги и как им можно помочь. Поэтому Катрина предлагает им чаще обсуждать тестирование. Это можно сделать несколькими способами:

• Ревью чек-листов аналитиками и саппортом. Вовлечение в тестирование на ранних стадиях могут повысить качество релизов.
• Тестирование в парах: тестировщик и аналитик, саппорт и разработчик.
• Ротация сотрудников между командами dev и саппортом.
• Додзё (в рамках разработки ПО) – среда, где люди могут учиться и практиковать свои навыки развития вместе: мастер-классы, обмен знаниями.

Тестирование в продакшне

Облегчить тестирование в продакшне помогут следующие инструменты:

• Мониторинг, настроенный так, чтобы там можно было легко найти и опознать проблему,
• Оповещения при помощи различных каналов связи: например, сообщение в мессенджер, если сервер упал, или email, когда память закончилась,
• Аналитика (например, Google Analytics), говорящая о том, сколько пользователей используют функционал,
• Логирование, сделанное читаемым.
• Обратная связь от клиентов – отзывы в сторах, формы для обратной связи в веб-приложениях.

P.S.

В этот конспект не вошло много интересного. Книга хорошо написана, рекомендуем ее тестировщикам, которые задумались о тестировании на DevOps-проектах.

Напоследок пара полезных ссылок:

• Книгу можно купить здесь.
• Ссылка на видео выступления Катрины с Agile Testing Days 2017.
• Ссылка на блог Катрины Клоки.