«Это должно быть сделано еще вчера», «Протестируйте как-нибудь быстренько», «Время от начала разработки до выкладки на продакшн должно быть минимальным, а если возможно — еще меньше» — наверное, многим знакомы подобные цитаты. И покуда мы (тестировщики) — одно из последних звеньев в цепочке разработки, именно нам чаще всего приходится балансировать между скоростью выхода фич и их качеством.

В данной статье хочу поделиться тем, как мы в нашей компании применяем успешные практики из Lean Startup (несмотря на то, что многие наши проекты вполне сформировались и устоялись), с какими проблемами сталкиваются тестировщики при использовании данной методологии и как мы с этими трудностями справляемся.

Пара слов о себе: я тестировщик, имела опыт работы в проектах разного масштаба, была единственным тестировщиком на проекте и работала в командах, в которых использовались разные подходы и методологии. По моему опыту, работать по Lean Startup — это круто, но тут есть и подводные камни для тестирования, о которых неплохо знать заранее.

Для начала стоит немного рассказать о том, чем занимается наша компания. Туту.ру — сервис по онлайн-покупке ж/д, авиа- и автобусных билетов, туров и других вещей, связанных с путешествиями. Один из наших проектов — "Туры" — еще в стадии активного развития, он очень динамичен, функциональность быстро меняется. Наши PO (продукт-оунеры) практикуют Lean Startup, и в частности мы проводим очень много экспериментов.

Lean Startup, желания менеджеров и реальность простого тестировщика

Мы, конечно, не совсем стартап, но в концепции Lean Startup есть немало интересных вещей в том числе и для нас. Что же собой подразумевает Lean Startup?

1. Минимизацию ненужных расходов и экономию всех возможных средств.
2. Вовлеченность в процесс создания продукта каждого сотрудника. Иными словами, о том, сколько стоит данное решение; когда можно сделать быстрее, а когда — добавить больше функций, тщательно проверить результат — должны думать не только менеджеры, РО или еще какие-то мифические люди, но и мы сами. Каждый из нас. Перед тестированием стоит спросить себя: а какая цель у фичи/проекта? Не тестировать ради процесса тестирования, а тестировать в соответствии с какими-то целями, особенностями.
3. Ориентацию на пользователя и получение максимального количества информации о клиенте в единицу времени. Да, мы думаем о наших пользователях и заботимся о них. Стараемся делать не только так, как удобно нам, инженерам, с технической стороны, а именно им — тем людям, которые будут пользоваться нашим конечным продуктом.

И чтобы понять, кто наши пользователи, чего они хотят, что им нравится, а что нет — мы используем эксперименты с быстрыми итерациями.

Смысл всего этого в том, чтобы сделать минимально-жизнеспособную функциональность, для проверки какой-либо гипотезы, а потом уже по результатам аналитики выяснить, нужно ли развивать эту гипотезу (фичу) дальше. Экспериментируя, мы снижаем риск разработки фичи, которая никому не нужна. При этом нам нужны максимально короткие итерации: получить нужную информацию как можно быстрее, доработать все в соответствии с полученными данными — тоже максимально быстро.

С точки зрения менеджмента — все это, конечно, очень весело и здорово: быстренько пилим нужную функциональность, быстренько проверяем гипотезы и варианты, быстренько изменяем функциональность по итогам. Но что со всем этим делать нам — тестировщикам? Когда мы постоянно слышим: «Быстрее, еще быстрее! Эта фича должна была выйти на продакшн еще вчера!».

Мы можем применять много разных техник, бесконечно увеличивать покрытие — тогда мы будем обеспечивать максимальный уровень качества. И конечно, нам бы хотелось, чтобы наш проект и наши новые фичи были самыми качественными и прекрасными. Но нужно понимать, что все это стоит определенных ресурсов: усилий, денег и времени.

В условиях частых экспериментов мы обычно этих ресурсов не имеем: ведь надо выпустить и проанализировать результаты сделанного побыстрее. Кроме того, на данном этапе проекту может быть не нужен максимальный уровень качества, который мы хотели бы обеспечить в своих мечтах и тайных желаниях. В то же время, мы не можем полностью выкинуть или сильно уменьшить объем тестирования, потому что наша новая фича таки должна быть качественной, до определенного уровня. Но где эта граница? Как удержать этот баланс? Как масштабировать тестирование под нужды проекта?

Для этого мы используем следующие методологии и инструменты:

1. Бизнес-анализ задачи
2. Работа с рисками
3. Градации качества
4. Чек-листы для разработчиков
5. «Отложенное» написание документации

А теперь рассмотрим каждый из этих пунктов поподробнее:

Бизнес-анализ задачи

Конечно, нельзя сказать, что мы (тестировщики) проводим полноценный бизнес-анализ: в конце концов, для этого существуют специальные люди, да и задача довольно обширная. Но мы стараемся применить это к нашим реалиям и нашей ситуации. Мы концентрируемся на целях проекта.

К примеру, если мы знаем, что количество пользователей, которые покупают туры на двоих взрослых и двух инфантов (детей младше 2 лет) стремится к нулю — мы скорее всего не будем проверять, какой тип номера предлагает нам туроператор в данном случае — потому что легче от этого никому не станет. Но при этом обязательно проверим поиск и предлагаемый тип номера для 2 взрослых и одного ребенка — потому что такая история случается гораздо чаще, и потому что при поисках с детьми вообще частенько наблюдаются ошибки — можно сказать, что этот кейс является граничным.

Или, например, тестируя API подключения нового провайдера, мы не будем обращать особое внимание на цены туров с перелетом бизнес-классом (главное, чтобы они не подставлялись по умолчанию, вместо экономического!), поскольку знаем, что полететь бизнес-классом, покупая тур, пожелал только один турист за все время работы нашего раздела.

Соблазн проверить хитровыдуманные кейсы для тестировщика всегда велик, но главное — не забывать о реальности.

Работа с рисками

Цель обеспечения качества — снижение рисков. Даже если бы мы владели неограниченными ресурсами, полностью исключить все риски мы бы не смогли.
Если мы ограничены временем, средствами или какими-то другими вещами, то мы делим риски на 2 группы:

1. Допустимые
2. Недопустимые

К первой категории относятся вещи, которые могут не работать, работать неправильно, мы можем даже не знать о том, что с ними что-то не так (это самое страшное!) — и для нас это нормально. Мы можем принять эти риски ради скорости выхода задач или другой цели.

Что можно сюда отнести? Некоторые дополнительные сценарии, места, куда по статистике «почти никто не тыкает» (0,1 % пользователей, например), работа в непопулярных браузерах и т.д.

Ко второй категории — недопустимым рискам — можно отнести то, что должно работать наверняка и в чем мы должны быть уверены. Мы должны предоставить пользователю минимальную, но работающую функциональность. Если мы делаем фичу, которая должна помочь пользователю перейти через овраг и в итоге выпускаем половину моста — это не годится, потому что не решает проблему пользователя. Такой эксперимент всегда покажет отрицательный результат, это относится к нашим недопустимым рискам. А если мы натянем через овраг канат с веревками по бокам — то перейти на другую сторону будет уже возможно, а значит, проблема пользователя может быть решена.

Мы управляем допустимыми рисками и снижаем недопустимые.

Градации качества

Градации в целом вытекают из предыдущего пункта и были сделаны для удобства как тестировщиков, так и РО. Они согласовывают правила игры между нами. У нас есть 5 градаций качества, каждой из которых соответствует определенное количество вещей, на которые мы смотрим.



Например, во 2 градации мы должны убедиться в том, что функциональность ведет себя адекватно в одном, самом популярном у наших пользователей браузере, выполняются основные пользовательские сценарии, работоспособна основная бизнес-функция.

На уровне качества 5, в добавок ко всему вышеперечисленному, мы обращаем внимание на:

• дополнительные пользовательские сценарии и бизнес-функции;
• UI;
• отображение во всех поддерживаемых браузерах и на мобильных устройствах;
• максимальный уровень автоматизации основных и дополнительных пользовательских сценариев;
• тестабилити.

Это удобно еще и тем, что можно устанавливать разный и вполне определенный уровень качества для разных проектов и даже разных задач.

Для задач-экспериментов устанавливается уровень качества пониже, а если такие задачи решают развивать дальше, то и градация качества растет вместе с ними. Например, мы предполагаем, что пользователям будет интересно и полезно, если мы предложим им цены на соседние дни и месяцы, а также в похожие страны (по сравнению с текущим поиском). Но технически эта задача довольно сложная, поэтому выполняем и запускаем ее, так сказать, в демо-режиме, чтобы посмотреть, будет ли интерес со стороны наших пользователей. Допустим, в таком виде задача попадает к нам в тестирование. И мы вдруг выясняем, что если поиск выполняется на двух человек (наш дефолтный вариант, самый популярный), то цены на соседние месяцы/в похожие страны адекватны и не врут. Но вот если поискать не на двоих, а на троих или одного — то тут «ой» — не все так радужно. И на данном этапе мы, как тестировщики, посоветовавшись с разработчиками и узнав, что правка достаточно трудоемкая, принимаем решение выпустить задачу как есть.

Далее мы собираем аналитику и понимаем, что этим нашим новым блоком пользуется около 40% посетителей. Тогда мы запускаем следующую итерацию задачи, и вот тут уже градация качества будет выше — мы поняли, что функциональность надо развивать и не можем себе позволить «неправильные цены» при поиске на отличное от двоих количество человек.

Здесь еще может возникнуть вопрос о том, что является в данном случае основным сценарием, а что — дополнительным.



Если вернуться к Lean, то все очень сильно зависит от стадии проекта, на которой мы находимся.

На этом рисунке слева изображены стадии проекта по Lean Analytics, и так называемые «гейты» (справа), через которые необходимо пройти, чтобы перейти на следующую стадию. Вот краткое описание этих стадий:

• Empathy. Цель этой стадии — проинформировать потенциальных покупателей о разработке продукта и ваших экспериментах. Гейт в данном случае — четкое определение реальной, актуальной и не решенной до этого момента проблемы. Теперь, когда вы с этим определились, можно идти дальше.
• Stickiness. Теперь сделать что-то такое, такую фичу, которая заставит пользователей возвращаться. Гейт — сформулированная методика решения проблемы, за которую готовы платить.
• Virality. Максимизируем количество пользователей (желательно без использования или с минимальным использованием платных методов). Гейт — количество пользователей, а также качество и востребованность фич растет.
• Revenue. Проект должен приносить деньги, причем больше, чем вы тратите на него. Гейт — вы нашли и заняли свою нишу на рынке.

Таким образом, чтобы понять, какие сценарии сейчас считать дополнительными и основными, стоит подумать на какой стадии сейчас находится проект.

Например, на стадии Stickiness для нас будут важны разные «фишечки» и отличительные черты, на стадии Virality не обойтись без SEO — и если мы знаем какие приоритеты у проекта на данный момент — мы можем более эффективно подходить к процессу обеспечения качества и «наносить особую пользу» только там, где это действительно нужно.

Чек-листы для разработчиков (acceptance criteria).

Здесь речь пойдет про повышение скорости выполнения всего цикла работы над задачей.

В идеальном мире каждый член команды несет ответственность за качество. В тестирование не поступают сырые задачи. Тестировщики не находят критичных багов, т.к. разработчики уже все учли. Наш мир — не идеален. Мы сталкивались с тем, что задача попадала к нам с очевидными багами. Но не бывает очевидных вещей. Такие ситуации были прозрачны только для нас – тестировщиков.

Разработчики думают иначе – это нормально и естественно. И именно поэтому мы хотели бы вносить частичку «своего видения» проекта как можно раньше, желательно еще до начала непосредственно тестирования.

Мы нашли такой способ: мы используем так называемые «чек-листы для разработчиков»(acceptance criteria).

Этот чек-лист представляет собой список проверок с конкретными параметрами, данными и ссылками, а также с описанием ожидаемого поведения объектов. При этом мы стараемся минимизировать количество проходов и поместить в них максимальное количество проверок, чтобы чек-листом было легче, быстрее и веселее пользоваться. Чек-лист должен быть достаточно прост и лаконичен, чтобы разработчики не пропускали пункты из него. Он почти никогда не содержит негативных проверок. Писать чек-лист имеет смысл только тогда, когда разработчик еще не закончил делать задачу, потому что наша цель: минимальное количество переключений от задачи к задаче. Если мы не успели к этому времени написать чек-лист, то мы просто не пишем его вообще.

К тому же, если разработчик прошел чек-лист, то это не значит, что при тестировании нам не нужно смотреть на те вещи, которые были описаны в чек-листе. Всегда стоит быстро пробежаться по ним на всякий случай. Тут играет роль разница в нашем восприятии продукта.

Пример отрывка нашего чек-листа:

1. Перейти на /hotel/3442/ (страница без параметров поиска)
2. Там нет плашки «отправить ссылку на туры»
3. Перейти на ХХХ (пример ссылки на страницу отеля с параметрами)
4. Плашка присутствует
5. Можно перейти на следующий шаг при клике на цену предложения
6. Присутствуют надписи о возможности частичной оплаты и о том, что входит в тур
7. Напротив них, под кнопками о ценах, расположена плашка с псевдоссылкой «Узнать, если цена снизится», в ней процент активен и краснеет при наведении
8. Кликнуть на ссылку «Показать еще N предложений»
9. Ниже подписки, уже вне локала в правой колонке находится плашка с надписью «Отправить ссылку на туры в этот отель по эл.почте»

Мы используем чек-листы больше года и уже смогли сделать кое-какие выводы. И тестировщики, и разработчики говорят, что чек-листы однозначно полезны и пользоваться ими удобно. Так в чем же, собственно, плюсы?

Почему это нравится тестировщикам?

• меньше сырых задач;
• тестировщики раньше включаются в процесс работы над задачей.

Когда методология разработки гибкая, то на проекте, как правило, очень мало документации и спецификаций. Если проект динамичен и РО постоянно экспериментируют (как это происходит у нас), то «предварительная» документация не имеет особого смысла — обычно, у нас есть только юзер-стори и примерные варианты решения. Поэтому в данной ситуации этап «тестирование требований» как отдельная единица попросту отсутствует. Но тестировщикам важно принимать участие в формировании требований и мы делаем это как раз на этапе создания чек-листов для разработчиков. Конечно, существуют еще и отдельные встречи для обсуждения задач, обсуждения макетов, но и этого бывает недостаточно.

• На тестирование задач с чек-листами уходит меньше времени, чем на тестирование аналогичных без чек-листов.
• Мы учимся формулировать конкретно и четко, выделяем проблемные места в продукте.
• У нас есть возможность посмотреть на задачу с разных точек зрения.

Часто бывает так, что тестирует задачу один человек, а чек-лист к ней писал другой. У всех нас немного разные стили, взгляды, методика тестирования. Когда удается посмотреть на задачу «свежим» взглядом — это очень здорово и полезно.

Почему это нравится разработчикам?

• четкий список сценариев с конкретными данными, которые надо проверить;
• предварительный анализ задачи;
• разработчики получают статистику и обратную связь.

Мы учитываем характер багов, найденных по чек-листам и можем сказать, что, например, кто-то допускает ошибки определенного характера: логика, код и т.п. Когда люди знают где они ошибаются, им есть к чему стремиться и легче исправлять свои ошибки.

Что нравится всем нам: мы не кидаем задачу от разработки в тестирование по сто тысяч раз. Многие вещи исправляются еще на этапе чек-листов. А еще мы становимся все ближе к тому идеальному миру, где все всё учли и сделали с первого раза как надо. Может быть, когда-нибудь.

Из минусов можно отметить то, что на написание чек-листов и их прохождение все же тратится время. Но, судя по нашей статистике, времени на это уходит меньше, чем на перекидывание задач между тестированием и разработкой при их отсутствии. Тестировщики пишут один чек-лист в среднем полчаса, разработчики проходят его за 10-30 минут (в зависимости от сложности задачи).

К тому же далеко не все задачи в наших спринтах «заслуживают» чек-листов. На планировании мы прикидываем, нужен чек-лист в задаче или нет. В итоге имеем 6-7 чек-листов за спринт (в среднем мы делаем около 30 задач за спринт). Около 67% чек-листов были пройдены успешно (разработчики не нашли багов по ним). В 35% задач с чек-листами не было найдено багов при тестировании.

«Отложенная» документация

Мы не ставим себе цель писать подробные тест-кейсы на все новые фичи. И причина все та же: задачи-эксперименты. Мы не хотим писать документацию, которая никому не пригодится. Лучше описать функциональность, когда будет точно известно, что ее ждет дальнейшее развитие. Мы пишем кейсы без излишней детализации, чтобы их было проще поддерживать. Кроме того, стараемся несколько раз подумать перед тем, как написать кейс, чтобы избежать опять же ненужных потерь времени.

Все вышеперечисленные инструменты в наших реалиях правда работают – мы проверяли.

Они помогают нам поддерживать баланс между качеством и скоростью.

> По мотивам моего выступления на SQA Days-19

Видео выступления можно посмотреть тут: