Когда фича «протестировать табуретку» вызывает нервный смех у тестировщиков и недоумение у менеджеров, пора разобраться, как на самом деле работает тестирование. Меня зовут Елизавета Лященко, я работаю тестировщиком уже 5 лет, из которых 1.5 года в Самолете, и сегодня разложу по полочкам весь цикл проверки — от странных требований до стресс-тестов и финального релиза. Мы узнаем, почему тестировщик задает миллион вопросов, чем его работа отличается от «я все проверил, все ок» и как тестирование спасает команду от хаоса. Готовьтесь увидеть табуретку так, как вы ещё никогда её не видели!

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

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

Кому подойдёт это руководство?

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

• Нетерпеливому менеджеру, который хочет побольше, побыстрее, да на высшем уровне;

• Неопытному аналитику или продакт-менеджеру, которые стремятся описывать задачи на макро-уровне «сделать красную кнопку»;

• Джуниору-тестировщику, которому нужно понять, с какой стороны подступиться к продуктовому тестированию и попутно отстоять свои процессы перед командой.

Итак, предположим, что к нам пришёл разработчик и сказал: «Вот тут задачка прилетела — сделать табуретку. Я всё сделал, посидел на ней — всё ок. Можешь, в общем-то, закрывать». Мы открываем задачу, а всё техническое задание состоит из единственной фразы «Сделать табурет». С чего мы начнём?

Тестирование требований

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

• От нас точно ждут табурет? Не стул, не кресло, не скамью? Табурет?

• Сколько у табурета должно быть ножек? Бывают одноногие, трёхногие, четырёхногие. А может быть, это пуфик совсем без ножек? Бывает что-то и более замысловатое, такого от нас не ждали?

• Какой высоты должен быть табурет? Это стандартная кухонная табуретка, или, может быть, барный стул или банкетка? А возможно, этот табурет нужно мочь регулировать по высоте?

• А какой формы должно быть сидение? Что-нибудь стандартное — квадрат или круг, или тут тоже допустим разгул фантазии? И вообще, позовите дизайнера, пусть покажет картинку! И полные габариты было бы здорово получить.

• Должен ли этот табурет быть разборным? А можно ли его разобрать и собрать хотя бы один раз, или это должен быть сплошной монолит?

• Из каких материалов должен быть сделан табурет? Дерево, металл, пластик? Должен ли быть использован только один материал, или, например, это должен быть деревянный табурет с тканевой обивкой сидения? И, раз уж мы об этом заговорили, то как должно быть отделано сидение — никак, обшито тканью или искусственной кожей?

• Должен ли табурет быть покрыт ещё чем-то (лак, краска, масло или олифа)? Возможно, на нём должны быть нарисованы или наклеены какие-то орнаменты? Ой, а почему дизайнер расплакался?

• А не должно ли у табурета быть подлокотников и спинки? Давайте ещё раз у бизнеса спросим, они точно не хотели стул?

• Для предельной ясности ещё уточним, каков должен быть предел прочности табурета — может он выдержать вес взрослого человека? массивного взрослого человека? группы массивных взрослых акробатов?

Получение ответов на все эти вопросы — это не просто блажь или занудство, а тестирование требований. Уточняя все мелочи (если у табурета есть тканевая обивка, то чем она закреплена — мебельными гвоздями или скобами?), мы дополняем техническое задание и приходим к максимальному фиксированию договорённостей между командой разработки и бизнесом. Таким образом мы, в первую очередь, спасаем команду от бесконечного цикла доработок, если вдруг выяснится, что заказчик хотел не пластмассовую табуретку, а резной деревянный табурет с бархатной подушечкой.

Разумеется, бывают ситуации, когда на многие вопросы мы не сможем получить ответы, потому что заказчик сам не знает точно, что он хочет, а команда дружно пилит MVP (minimum viable product, минимально жизнеспособный продукт). В таком случае задавать вопросы всё равно можно и нужно — даже если у нас не будет ответов на старте разработки, они могут появиться позднее, а сами по себе вопросы помогут команде предусмотреть возможное расширение функциональности и подготовиться к возможным доработкам.

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

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

Мы получили ответы на все (или почти на все) ключевые вопросы, и теперь переходим непосредственно к самому тестированию табурета (помните, разработчик нам принёс уже готовую задачу!).

С чего начнём? Для начала, проверим соответствие базовым требованиям и обмерим табурет линеечкой — соответствуют ли реальные габариты тому, что было в задании? Зафиксируем отклонения, если они есть (в последствии бизнес-аналитик или владелец продукта ознакомятся с этими отклонениями и дадут свой вердикт — допустимо это или нет).

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

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

Далее переходим к более практическому этапу — юзабилити-тестированию. Здесь нам предстоит проверить, насколько хорошо табурет справляется со своими прямыми обязанностями. Начнём с позитивных тестов:

• Табурет устойчиво стоит на ровном полу?

• На табурете можно сидеть?

• Когда сидишь на табурете, шатается ли он?

• Можно ли встать ногами на табурет? Устойчив ли он при этом?

• Вынесем табурет на улицу и поставим на тротуар. Мы всё ещё можем на нём сидеть и стоять? Замена одной твёрдой поверхности на другую сказывается на его функционировании?

• Можно ли поставить на табурет какой-нибудь твёрдый предмет меньших габаритов? будет ли этот предмет при этом устойчиво стоять? (если по ТЗ от нас ожидался табурет с мягким сидением, эту проверку можно опустить)

• Если в ТЗ появилась дополнительная функциональность (регулировка табурета по высоте, поворотное сидение, колёсики на ножках и т.д.), проведём аналогичные позитивные проверки — испытаем только использование всех функций по прямому назначению.

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

Проведём также серию негативных тестов:

• Можно ли поставить табурет ножками вверх? Можно ли после этого сидеть или стоять на табурете приличными способами?

• А если поставить табурет на менее устойчивую поверхность, например, на мягкий матрас, можно ли будет на этом табурете сидеть? Стоять? Насколько устойчивыми мы при этом будем?

• А если поставить наш табурет на другой табурет (любой, какой найдём у себя дома), сможем ли мы сидеть или стоять на такой высоте? Насколько безопасно это будет?

• А теперь поставим табурет на лестницу в подъезде. Сможет ли он при этом сохранять устойчивость? А сможем ли мы на нём сидеть? Стоять? (все трюки выполнены профессиональными каскадёрами, пожалуйста, не повторяйте это дома!)

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

На следующем этапе проведём интеграционное тестирование:

• Поставим табурет рядом с кухонным столом. Можно ли сидеть на нём за столом? Будет ли комфортно по высоте? Будет ли достаточно пространства для ног?

• Можно ли поставить рядом с табуретом ещё несколько таких же табуретов? А других? А стульев? Продолжают ли все табуреты и стулья исполнять своё прямое назначение в таких условиях?

• Переставим табурет к рабочему столу и повторим проверки. Всё ли удобно? Есть ли разница?

При помощи таких проверок мы выясним, насколько хорош табурет при взаимодействии с остальными окружающими его объектами. 

Параллельно с интеграционным, мы можем провести также UI-тестирование и оценить, насколько же в целом красив и хорош наш табурет, как он вписывается в интерьер. Ранее, при функциональном тестировании, мы убедились, что изделие соответствует заданным в ТЗ характеристикам, но вряд ли кто-то будет рад ярко-красной модерновой табуретке в классическом интерьере в сдержанных тонах, даже если изначально он сам так и попросил. Однако, как правило, провал UI-тестов на таком позднем этапе приведёт не к тому, что мы не отдадим табурет заказчику, а скорее к тому, что мы сдадим работу и сядем ждать обратной связи. 

Теперь, когда большая часть безопасных тестов проведена, мы заручаемся разрешением тимлида и переходим к более опасной (в контексте табурета) части. Проведём нагрузочное тестирование. Сколько веса выдержит табурет? Он выдержит одного взрослого человека, сидящего на нём? А взрослого человека и мелкое домашнее животное? Взрослого человека и ребёнка? Позовём друзей и предложим им поупражняться в акробатике — как много человек одновременно сможет сидеть на одном табурете? Если в какой-то момент табурет всё-таки развалится, спрячемся от друзей в шкафу и зафиксируем результаты. Если не развалится, тем лучше — это тоже зафиксируем.

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

И под конец проведём серию стресс-тестов (при условии, что мы имеем несколько абсолютно одинаковых копий табурета, которыми можем свободно распоряжаться):

• уроним табурет;

• уроним табурет из окна второго этажа;

• уроним табурет с лестницы;

• оставим табурет на ночь под дождём;

• оставим табурет на ночь при 30-градусном морозе;

• поставим табурет в костёр и засечём время до полного сгорания;

• попытаемся разобрать табурет, даже если по требованиям он неразборный.

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

Документация

Если быть предельно откровенными, отсутствие документации не блокирует релиз и не мешает нам выдать табурет заказчику сразу же, как только будут устранены все дефекты. Однако хорошим тоном считается всё же составить все сопроводительные документы.

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

• опишем выявленную дополнительную функциональность и ограничения — это будет передано владельцу продукта для ознакомления и составления возможного плана доработок;

• опишем основные этапы тестирования в виде алгоритма — так в любой произвольный момент времени любой другой тестировщик сможет протестировать ещё десяток табуретов;

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

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

Регресс

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

Нам нужно убедиться, что в процессе сборки табурета мы не сломали остальную мебель в квартире. Проверяем всё, что окружает табурет — пол, стены, потолок, двери. Убрали ли мусор после сборки? Не поцарапали ли напольное покрытие? Не запачкали диван краской? Проверим кота — не играет ли он с блоком строительных скоб?

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

Релиз

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

О нет, он всё-таки хотел от нас компьютерное кресло!

Заключение

Итак, на простом примере табурета мы разобрались:

• как работать с неполными требованиями;

• как вывести из себя аналитика и дизайнера;

• как протестировать продукт наиболее исчерпывающе;

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

• как при помощи наводящих вопросов подготовить продукт к возможным доработкам.

Почему это важно?

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

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

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