26 января в 09:43

Все лучшее из методологии Lean Startup, и как с этим жить тестировщикам

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

В данной статье хочу поделиться тем, как мы в нашей компании применяем успешные практики из 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

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

Автор: @Railven
Туту.ру
рейтинг 121,11
Tutu.ru — российский туристический онлайн-сервис.

Комментарии (8)

  • +2
    Сверх-исчерпывающий пост, спасибо! А что у вас насчёт ПО, если не секрет — для чек-листов и багтрекинга используете что-то своё или Jira/Redmine. И насколько комфортно ПО позволяет использовать вот эти чек-листы?
    • +3
      вообще у нас JIRA, да. задачи на доске представляют собой стори, внутри которых поставлены подзадачи на каждую роль, например, «Аналитика», «Бекенд», «Фронтенд», «Тестирование».
      Обычно на планировании мы решаем, нужен ли чеклист задаче или нет, и если да, то в стори добавляется 2 подзадачи «Написать чек-лист» и «Пройти чек-лист». По опыту, подзадачи «Нпписать чек-лист» должны иметь бОльший приоритет, чем задачи типа «Протестировать» (я говорю в принципе о всех задачах в спринте), потому что после окончания разработки и переключения разработчика на другую задачу, чек-лист уже не имеет особого смысла.
      Ну и, собственно, сначала тестировщик таскает свою задачу про написание чек-листа (сам чек-лист кладем в комментарии к общей стори — ну, нам так удобнее), потом разработчик, после того, как закончил, тащит задачу «пройти чек-лист» и по итогам пишет коммент к чек-листу. Как-то так :)
  • +2
    А в чем чеклисты создаете и насколько удобно там работать с ними?
    С ходу на ум приходят trello и google spreadsheets, но хочется узнать конкретно.
    • +3
      Ну тут нет какого-то централизованного инструмента на самом деле :) прелесть этих чек-листов для разработчиков именно в их краткости, это не те километровые чек-листы, про которые мы привыкли говорить в тестировании. Я писала просто в джировских комментах к задаче, для списка из ≈ 10-15 пунктов этого было достаточно
  • +2
    насколько я понимаю, это не совсем чек-лист из примера в статье:

    Перейти на /hotel/3442/ (страница без параметров поиска) — это test step
    Там нет плашки «отправить ссылку на туры» — actual result
    Перейти на ХХХ (пример ссылки на страницу отеля с параметрами) — test step
    Плашка присутствует — actual/expected result

    чеклист, это что-то типа такого
    1. Проверить, что: на странице /hotel/3442/ (страница без параметров поиска) плашка «отправить ссылку на туры» отсутствует
    2. Проверить, что: на странице ХХХ (пример ссылки на страницу отеля с параметрами) плашка присутствует
    и т.д.

    насчет
    Можно перейти на следующий шаг при клике на цену предложения


    Вы пишете детерминированную документацию или пожелания для тестировщиков? как гарантировать покрытие в таком случае?

    Из моего опыта в тяжелом динамическом аджайле:
    — тест кейсы лучше писать для критической функциональности, которая редко меняется
    — юзкейсы — это обычно почти стори
    — чек-листы — только краткие и нормальные — очень хороший заменитель тест-кейсов для команды, которая давно работает с проектом. Но они, к сожалению, не могут заменить хороших тест-кейсов в момент, когда добавляюся новые тестировщики в команду.
    У нас было в отдельно взятом проекте хорошая практика тратить время начала спринта для написания/обновления регрессионнных тейс-кейсов на основе стори, чеклистов и тест-кейсов из фич прошлого спринта
    • +2
      вообще, как я писала в статье, да и в предыдущем комментарии, это правильно называется acceptance criteria, то есть это не чек-лист как тестовая документация — это нечто иное, нам просто удобно называть это «чек-листом» для разработчиков. Хотите, можно назвать это набором проверок, чем-то еще, это неважно. Смысл в том, чтобы дать разработчику небольшой, но максимально полезный список необходимых проверок, обозначить области риска с нашей стороны, ну и того, что должно быть точно сделано в задаче. Этакое «проверь себя»
      Вы пишете детерминированную документацию или пожелания для тестировщиков? как гарантировать покрытие в таком случае?

      Еще раз: чек-листы для разработчика — это не тестовая документация, вообще никакого отношения к ней они не имеют :)
      Про документацию — это отдельная тема, у нас есть регрессионные тест-кейсы, которые мы сейчас активно переносим вообще в php-doc к автотестам, кейсы на новый функционал сразу не пишем — только когда понимаем, что уже пора… чек-листы — я бы сказала, что массово и централизованно мы их не используем, разве что отдельные тестировщики при работе с новыми задачами
      • 0

        тогда чуть яснее, спасибо, тогда это чек-лист для acceptance testing на стороне девелопмента перед отдачей билда тестировщикам. На самом деле очень хорошая практика, не всегда применяемая.


        но держать отдельный чеклист для девелоперов, а отдельный для тестировщиков — излишество, ведь надо поддерживать два отдельных артефакта документации. А кто пишет и обновляет эти дев-чек-листы?


        Если вы сумеете покрыть автотестами регрессию хотя бы на 70% — это огромное достижение, главное потом не забывать выделять всегда время и саппортить их. К сожалению, это накладнее, обычно, чем просто написать 1 раз

        • 0
          но держать отдельный чеклист для девелоперов, а отдельный для тестировщиков — излишество, ведь надо поддерживать два отдельных артефакта документации. А кто пишет и обновляет эти дев-чек-листы?

          да нет двух отдельных чек-листов :) смотрите:
          1. у нас есть задача. задача-эксперимент.
          2. разработчик делает задачу
          3. в это время тестировщик пишет для него чек-лист, это занимает минимум времени, около получаса, чек-лист небольшой. это в посте все написано, кстати
          5. разработчик закончил свой, так сказать, девелопмент и затем проходит чек-лист, написанный тестировщиком. Если есть что — правит по итогам.
          6. задача попадает в тестирование, а после этого в мастер (ну тут +- итерации на правки)
          Как тестировщик тестирует конкретно эту новую задачу — его личное дело.
          Все, по данной задаче мы НЕ пишем больше никакой документации. Потому что кто знает — вдруг мы по результатам аналитики через 2 недели эту фичу выпилим? А вот когда мы понимаем, что да, фичу эту стоит развивать и мы будем это делать — тогда она уже заносится в регрессионные кейсы, на нее пишутся автотесты и так далее. Потом в определенные дни из мастера собирается RC — релиз-кандидат, и основная, глобальная регрессия, в которую как раз включены критичные вещи, проверки имеющегося функционала и вот это все — происходит именно здесь. Автотесты у нас есть, да, ну и покрытие в районе 70% и более тоже имеем почти во всех проектах. Согласна, на саппорт тестов уходит время, но мы это вписали в процесс и посему забыть или пренебречь этим — невозможно

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка