Home

Автор: Роман Шейко. Оригинальная публикация в блоге автора

Первая статья

Сегодня я хотел бы рассказать о создании стратегии для тестирования одного крупного сайта (http://lingualeo.com). Коротко: это онлайн-платформа для желающих изучить английский язык.

Цель у меня такая: не показать результат, а в первую очередь рассказать о самом процессе составления стратегии. Мне было интересно проследить, как и что я делаю. Это напоминает работу над ошибками и самопроверку. Кроме того, это попытка объяснить свою работу. Не всегда это просто сделать, потому что часто мы работаем интуитивно. Для меня умение объяснить свою работу означает способность понять свои ошибки (что я делаю неправильно) и свои достижения (что я делаю правильно).   
Итак, я расскажу о процессе составления стратегии и постараюсь сделать это в структурированной форме, по порядку. Как вы понимаете, не каждый процесс структурирован сам по себе. Поэтому не факт, что у меня получится разложить все по полочкам.

1. Хождение по сайту (блиц-экскурсия)

Начал я с обычного исследования сайта http://lingualeo.com. Можно назвать это упражнение туром по сайту (про туры совсем недавно было хорошее сообщение в блоге Ольги Киселевой, а еще раньше я читал про них в статье Майкла Келли). Можно назвать это позитивным тестированием, цель которого - не найти баги, а изучить продукт. В целом, я потратил на него всего 20-30 минут. Поэтому предлагаю назвать это упражнение коротким погружением или блиц-экскурсией. Могу сказать, что упражнение было полезным - благодаря ему у меня в голове сложились основы будущей тестовой стратегии.

Что я заметил:

• Сразу же на главной странице сайта http://lingualeo.com - ссылки на расширения для браузеров и мобильные приложения. *** Ага, значит это многообразие платформ потенциально нужно проверять в рамках тестирования.
• Множество контента (курсы в текстовом формате, видео, подготовка к сдаче экзаменов, звукозаписи). *** Это тоже нужно тестировать. 
• Gamification движок сайта (поинты, медальки, забавный помощник по обучению - львенок Лео). *** Это тоже нужно тестировать, насколько это возможно.
• Монетизация и связь с платежными системами (внутренняя валюта сайта - так называемые фрикадельки). *** Тоже важная часть, от которой зависит доход компании.
• Локализации сайта (как минимум, бразильский и турецкий языки). *** Еще один параметр конфигурации системы, влияющий на объем тестирования.

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

Кроме того, я заметил интересную вещь: увидев, что сайт имеет подобие игры (в нем очень активно используются механизмы gamification), я довольно много времени уделил исследованию элементов игры. У меня есть к этому склонность: я интересуюсь использованием элементов игры в работе, в жизни; пару лет назад я прошел курс по Gamification на coursera.org. Поэтому я пробовал оценить, насколько реализация игры на сайте http://lingualeo.com может заинтересовать пользователей и мотивировать их к изучению английского. Ведь привлечение новых пользователей - это одно, а поддержание постоянного интереса, стимулирование внутренней мотивации внешними средствами, внедрение эффективных механизмов социализации - это другое. От продукта, построенного на gamification, ожидаешь чего-то особенного, какой-то харизмы. И большой вопрос - как эту харизму в будущем тестировать?

Сделаю заметку: я уделил механизму gamification много времени потому, что в принципе интересуюсь игровыми элементами. Другой человек при исследовании сайта уделил бы внимание другим вещам. Поэтому нужно быть внимательным: нужно контролировать свои склонности. Они не всегда приводят к важным открытиям и правильным решениям. О склонностях в тестировании написано много - например, Bias and the Human Side of Software Testing и Reduce Biases.

2. Серфинг
Что было потом? Я стал искать информацию о проекте в интернете: википедии и на официальной хабра-страничке. Назовем этот процесс серфингом по открытым источникам информации. В рамках этого упражнения я пытался собрать разнообразные заявления и утверждения, которые делаются о компании и которые делаются самой компанией. Кроме того, можно сказать, что я изучал контекст продукта - окружение, в котором происходит его разработка и в котором он существует. Здесь я могу сослаться на часть модели HTSM - Project Environment - ее исследованием я в основном и занимался на этом этапе.

У меня получилось собрать следующие факты:

• У проекта около 10 млн пользователей. *** Необходимо нагрузочное тестирование? Сложность поддержки большого числа пользователей посильна для компании?
• Проект расширяется ‎и захватывает новые страны. *** Локализации нужно будет тестировать, опять же.
• При разработке используется вывоз команды в другие страны - на короткий промежуток времени. *** Тут от тестировщиков нужно будет умение подключаться на ранних этапах разработки и выдавать необходимую информацию о качестве продукта как можно раньше. Этот метод требует определенной гибкости от тестировщиков: умения жертвовать документацией, умения проводить исследовательское тестирование без тест кейсов, умения автоматизировать регрессионные проверки для сокращения итераций тестирования. Я немного забегаю вперед :)
• В команде около 60 человек. *** Значит, на вскидку, тестировщиков человек 5-8.
• У компании были трудные времена, не получалось найти инвесторов. В данный момент необходимые для развития ресурсы найдены и компания растет. *** С молодостью компании можно связать молодость процесса разработки. Это очень даже не плохо, но это может означать, что процессы еще не совсем налажены. Это предположение, которое еще нужно подтвердить.

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

3. Глубокое погружение (полноценная экскурсия)

Я зарегился и решил пройти несколько упражнений на сайте. Обнаружил интересные для тестирования фичи, такие как:

• Социальная интеграция. Можно найти людей, так же изучающих английский на сайте, и добавить их в свой прайд - то есть, создать своеобразную книгу контактов. Кроме того, можно собрать группу и обучать ее английскому - выступить в роли преподавателя. 
• Платные возможности. Чтобы пройти курс по изучению времени Future perfect, предлагалось заплатить N-ное количество фрикаделек. Это валюта, используемая на сайте. Фрикадельки можно получить, например, если пригласить друзей на сайт. Они расходуются на новые слова, курсы. *** Нужно тестировать монетизацию, доступность различных курсов.
• Звукозаписи хранятся в Sound cloud. При прохождении урока была запись, проигрываемая из этого сервиса. *** А значит, интеграцию с этими сервисом тоже нужно проверять.

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

4. Остановка исследования продукта

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

5. Составление стратегии

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

Уже имея очертания тестовой стратегии в голове, я стал думать о том, как сделать эту стратегию логичной для себя и для потенциальных стейкхолдеров. Я мысленно начал готовить презентацию стратегии. Возвращаясь назад, я понимаю, что у меня еще не было достаточно четкой формулировки стратегии, когда я начал думать о ее презентации. Если бы меня в тот момент спросили о стратегии, я бы долго рассказывал о том, как на мой взгляд надо тестировать продукт. Но не уверен, что я смог бы обосновать все это. Мне не хватало логической цепочки, где каждая идея тестирования из чего-то вытекает. Но одно я знал точно: собранная информация - о продукте, о бизнес целях, о проблемах и трудностях компании - должна подкреплять и подтверждать мою стратегию тестирования. Мне нужно было связать интересы компании со стратегией.

5.0. Цели продукта и компании.

Я решил начать с потребностей компании. Перечислил их для себя как:

• ‎Экспансия в новые страны
• Монетизация и увеличение прибыли
• Привлечение новых пользователей
• Расширение контента

Для упрощения я решил оставить две обобщенные потребности:

• Привлечение новых пользователей
• Поддержка старых пользователей

5.1. Логическая цепочка стратегии тестирования.

Дальше я решил действовать в такой последовательности:

Бизнес цели (потребности компании) -> Критерии качества (какие критерии качества продукта для компании важны) -> Техники тестирования (как мы будем тестировать) -> Cтратегия тестирования.

Потом я решил добавить ‎challenges (или трудности, с которыми компания сталкивается в процессе достижении своих целей), но убрать явное упоминание техник тестирования (можно коротко упомянуть их в самой стратегии). То есть, логическая цепочка стала такой:

Цели > Challenges > Критерии качества > Стратегия

‎5.2. Challenges

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

• Огромное число требований, запросов на новые фичи, которыми нужно грамотно управлять
• Огромное количество конфигураций приложения, которые нужно поддерживать
• Огромный объем контента, который нужно хранить и постоянно пополнять
• Сложная инфраструктура продукта, которая должна быть быстрой и производительной - для поддержки комфортной работы старых и новых пользователей

5.3. Критерии качества

Дальше в логической цепочке идут критерии качества, важные для данного продукта.

Я выделил следующие критерии: 

• Расширяемость. Способность продукта приобретать новые фичи, новые модули, новые части - с малым риском влияния на старые части. Я ‎считаю это важным для данного продукта, потому что одна из его основных фишек - это новый и интересный контент, новые фичи, способные вдохнуть в процесс gamification что-то новое. 
• Функциональная полнота. Все фичи должны работать, потому что кто-то их использует. Огромное число пользователей означает, что мы не можем просто забить на некоторые фичи. Из 10 млн юзеров кто-то точно использует самую забытую и маленькую фичу. 
• Локализованность. Способность продукта поддерживать разные языки, легкость добавления новых языков. Этот критерий ‎вытекает из потребностей компании расширяться в новые страны. 
• Нагрузоустойчивость и производительность.  Большое число пользователей -  серьезные требования к стабильности, быстродействию и безотказности системы.
• Харизма. В модели HTSM не зря упоминается этот критерий качества. В данном случае он применим. Почему? Продукт игровой и добровольный, он должен привлекать, заинтересовывать, затягивать. Это не офисный продукт, с которым так или иначе людям приходится работать. 
• Юзабилити. Этот пункт можно включить как в харизму, так и в производительность.

5.4. Как будем тестировать?

Дальше - нужно было решить, как проверять критерии качества (см. выше 5.3), учитывая известные трудности и цели компании (см. выше 5.2 и 5.0).

В этом сообщении я просто хотел написать то, что у меня в получилось. Но это нечестно, потому что тем самым я ставлю перед фактом, а не объясняю, как к этому пришел.

‎Доминирующая проблема, которая засела у меня в голове - как можно справиться с множеством платформ для тестирования. Как можно ее решить?

• Первое, что пришло в голову - автоматизация. Если организовать грамотную автоматизацию, она способна покрыть смоук проверки для основных частей продукта на множестве платформ. Тут есть связанная проблема: чем больше платформ, на которых ранятся автоматические проверки, тем сложнее поддержка автоматизации. Поэтом нужно быть осторожным - не увлекаться проверкой интерфейса, стараться большую часть тестов держать на более низком уровне. Тем более, продукт часто меняется, поэтому автоматизацию через интерфейс продукта придется часто переделывать (хотя это зависит от характера и качества автоматизации). 
• Второе, что может помочь в тестировании множества девайсов, браузеров и локализаций - бета тестирование и краудсорс тестирование. Таким образом мы можем получить большее покрытие, чем мы способны обеспечить в рамках внутреннего тестирования.
• Еще одна важная вещь для сокращения числа тестируемых платформ - разбиение на классы эквивалентности. С одной стороны,это очевидно. Но это нетривиальная задача. Из всего многообразия платформ (браузеров, мобильных устройств, плагинов) нам нужно выбрать эквивалентные классы, а затем выбрать по 1-2 представителя от каждого класса. Их мы и будем покрывать в рамках регулярного функционального и регрессионного тестирования (здесь ‎я не имею в виду краудсорс и бета тестирование - оно будет использоваться для покрытия специфичных платформ). Note: под функциональным тестированием я имею в виду тестирование конкретных изменений - новых фич. Это понятие используется для разделения тестирования новых фич и тестирования старого функционала (регрессионного тестирования). 

Другая проблема - нужно справиться с частыми релизами и тестированием большого числа новых фич. Как поступить?

• Чтобы оптимизировать скоуп тестирования - я предлагаю проводить импакт анализ. То есть, анализ тех изменений, которые были сделаны, и выдвижение предположений о том, какие части продукта могли отвалиться. Этот пункт подразумевает, что тестирование каждого релиза будет интеллектуальным, что разработчики будут участвовать в импакт анализе как основные носители знаний о новых фичах и их взаимосвязях со старыми фичами. Простого копирования скоупа тестирования из релиза в релиз не будет. Это дополнительный расход по времени - на анализ изменений. Но я рассчитываю, что он окупится за счет тестирования самых рисковых частей продукта в первую очередь. 

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

Тоже самое можно сказать про другие виды тестирования - безопасности, юзабилити. Их можно либо включать, либо не включать в релизный цикл. Опять же, тут должен работать импакт анализ, чтобы мы могли понять, в каких случаях нужны эти виды тестирования, а в каких - не нужны.

Итак, когда я собрал все идеи вместе, у меня получился такой список:

1) Scope тестирования зависит от конкретного релиза

2) Для определения скоупа используется анализ изменений

3) Каждый релиз обычно включает функциональное тестирование (проверка новых изменений) и регрессионное тестирование (проверка старого функционала)

4) Опционально проводится нагрузочное и другие виды тестирования (usability, безопасности, локализации)

5) Регрессионное тестирование по максимуму автоматизировано

6) Платформы разбиты на классы эквивалентности, тестируется минимум один представитель каждого класса

7) Для покрытия большего числа платформ используется crowdsource тестирование и бета тестирование

5.5. Недостатки стратегии

Такая вот получилась стратегия. Какие недостатки я вижу?

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

Эти вещи - уже проработка следующего уровня, для формулировки стратегии я решил оставить их за рамками.

5.6. Выгоды при использовании стратегии

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

• ‎Наиболее рисковые области тестируются в первую очередь (благодаря импакт анализу) - это позволяет ограничить скоуп и оптимизировать тестирование.
• Релизный цикл уменьшается за счет большого числа автоматизированных проверок.
• Обеспечивается большее покрытие платформ - за счет разбиения на классы эквивалентности и использования краудсорс тестирования.

Выводы

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

В завершение - вот, что у меня получилось.