Home

Автор: Роман Буданов, специалист по тестированию компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/unbelievable-fuckup-stories/

Мальчишки и девчонки!
А также их родители!
Рассказы про «факапы»
Послушать не хотите ли? 

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

История первая: «Тараканище»

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

Каждый специалист тестировал то, что ему нравилось, – лишь иногда «сверху» приходило конкретное ЦУ: проверить конкретный модуль или посмотреть пофикшенные баги . В остальное время мы были заняты «свободным плаванием». Изначально продукт предназначался для iPad, но затем было принято волевое решение портировать игру на iPhone. Естественно, релизу iPhone-версии проекта предшествовали недели портирования и тестирования, но этот процесс каким-то образом прошел мимо меня (я был полностью погружен в планшетную версию), о чем впоследствии горько пожалел.

Итак, обычный рабочий день подходил к концу, стрелки часов приближались к 6 часам, а мои коллеги либо уже ушли домой, либо были на низком старте. Я же слегка задержался, доделывая недобитую задачку. Закончив работу, я уже двинулся к выходу, но был остановлен внезапно появившимся начальником. По его хищному взгляду и хитрющей улыбочке стало понятно, что рабочий день продолжается. «Ребята, нам надо – кровь из носу – сегодня отдать продукт в аппстор!». Следует пояснить, что сама игра уже давно была загружена в аппстор, но на очереди стоял приуроченный к определенному событию контентный аддон с добавленной поддержкой iPhone (собственно, данный факт является ключевым моментом этой истории). Из всех тестировщиков на проекте только я один в глаза не видел iPhone-версию продукта (так уж получилось).

Разработчикам была дана команда срочно доделывать ключевые фичи аддона и не уходить до тех пор, пока я не проверю результат. Ребята внесли правки, я прогнал смоук-тесты и протестировал новый функционал. Как уже говорилось, тестовой документации практически не было, но, к счастью, я уже полгода был на проекте и весьма свободно владел продуктом. Багов не нашел, о чем незамедлительно сообщил начальству, и, мысленно собравшись домой, был возвращен на землю резонным вопросом: «А в iPhone-версии тоже все хорошо?» Действительно, одна из важных целей срочного тестирования – проверка аддона на iPhone – не была учтена, а время близилось к часу ночи.

Я нашел тестовый девайс, залил билд и начал прогонять тесты, при этом все время стараясь понять основные различия телефонной и планшетной версий. ТЗ в печатном виде у нас тоже не было; оно хранилось только в голове ПМ-а, с которым в тот момент связаться не получилось. Через полтора часа, когда мне показалось, что все функциональности были проверены, я решил пробежаться по рандомным частям продукта. Каково же было мое удивление, когда в одной из основных функциональностей обнаружился критический баг! Проверив еще несколько основных функций приложения и не выявив новых проблем, я пошел с докладом к начальнику, и вскоре ревизия с фиксом бага была готова. Вновь последовала заливка новой версии, запуск, проверка фикса, смоук. Все работало нормально, багов не нашлось. В итоге ревизию сдали в релиз, а я наконец-то ушел домой спать.

Мораль: все делать в последний момент – это привычно, но плохо!

Вывод

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

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

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

Наметим пути решения упомянутых проблем. При планировании релизов следует учитывать следующие этапы процесса разработки:

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

На основании этих 7 пунктов можно примерно подсчитать количество времени, требуемого команде для выпуска готовой версии продукта. Не следует забывать и о так называемом антропогенном (человеческом) факторе – вы не можете всего предугадать, а работники – люди с разной скоростью работы. Смело добавляем еще 15-20% времени «на непредвиденные нужды» и риски. Подробнее о планировании релизов можно прочесть в следующих работах: источник 1 и источник 2.

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

История вторая: «Поди туда – не знаю куда…»

Эта история произошла со мной во время работы на одном крупном проекте медицинской направленности, включающем целую сеть подсистем. Нашу команду постоянно перебрасывали с одной подсистемы на другую, часто используя как «скорую тестерскую помощь». Мы не только гоняли GUI-ные тесты и готовили тестовые наборы по новым/обновленным подсистемам, но и работали с БД, а также участвовали в интеграционном тестировании. Нередко на конкретный участок «брали попользоваться» не всю команду, а одного-двух человек.

Как-то прекрасным понедельничным утром мне дали установку: на сегодня я поступаю под начало коллеги, ответственного за тестирование сервисов Я запросил у нового руководителя разъяснения по тестируемому функционалу, но в ответ получил лишь название сервиса и ссылку на него. На запрос ЧТЗ с описанием сервиса и методов мне ответили в стиле «сегодня не подвезли». При попытке узнать, кто системный аналитик продукта (для получения информации из первых рук), всплыл неприятный факт – со вчерашнего дня он был в отпуске. Более того, неделю назад уволился и разработчик.

Вооружившись запасом терпения и термосом с кофе, мы принялись за работу и в первую очередь попытались «выехать на интуиции», ориентируясь просто на названия функций и блоков. Сервис наотрез отказывался работать с нами, выдавая ошибку некорректности данных. Поразмыслив логически, подобрали сложившиеся в красивую схему тезисы, составили наборы тестовых данных, забили их в тело запроса, отправили и вновь получили сообщение о невалидных данных. Порядком раздраженные, мы предприняли обходной маневр и попытались узнать нужную информацию у нового разработчика. Увы, этот неопытный сотрудник еще не успел войти в курс дела. Поход к начальству также не дал положительных результатов: нас внимательно выслушали, посочувствовали, но намекнули на то, что эту работу сделать необходимо, так как скоро будет реализован пользовательский интерфейс, и времени на сервисы не останется. Смирившись с ситуацией, пришли к единственно верному (на наш взгляд) выводу: нам придется перебирать варианты («брутфорсить»). Какие только длинные и извращенные логические цепочки мы не составляли… Но это давало свои плоды – дело двигалось.

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

Мораль: вовремя поданная информация – залог успеха!

Вывод

В данном случае мы столкнулись с одной существенной проблемой. Кто-то банально забыл о жизненном цикле продукта, а точнее, об одном из его этапов – о подготовке спецификаций. Конечно, сама спецификация существовала, ибо в противном случае система не была бы реализована (не писали же разработчики продукт по собственному разумению!). Но вот найти этот заветный документ нам так и не удалось. Сложилось впечатление, что ЧТЗ было составлено на коленке, набросано на салфетке в кафе, согласовано в курилке и в этом же виде отдано в разработку. Такой несерьезный подход в итоге вылился в серьезную головную боль конечных исполнителей, а главное – в неоправданные затраты рабочего времени.

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

СУТ предоставляет следующие возможности:

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

Последний пункт также предоставляет удобную возможность отслеживания полноты ТЗ относительно функционала. В том случае, если существует задача на тестирование/реализацию продукта, но нет ЧТЗ, вы узнаете об этом и сможете заранее принять меры по ликвидации этой проблемы. Самый простое и распространенное решение в этой области – JIRA+Confluence (платное, но оправдывающее затраты). О необходимости иметь полное и поддерживаемое ТЗ также можно прочесть здесь.

История третья: «Долго ли, коротко ли…»

Последняя история произошла во время моей удаленной работы в западной компании, разрабатывающей систему онлайн-банкинга для американских банков. Это было сложно, но жутко интересно. Система американского банкинга сильно отличается от того, к чему мы с вами привыкли. Огромное количество банков связаны между собой в «альянсы», которые по-разному относятся друг к другу: например, из банка «альянса А» в банк «альянса Б» деньги переводить можно (так как они «дружат» по каким-то там своим соглашениям), в «альянс В» – нельзя (они друг друга «не любят»), а в «альянс Г» – можно, но с определенными оговорками (например, только определенную сумму в день). Сложность системы рождала и интерес к работе: приходилось иметь дело с немалым объемом функционала и нюансов! Тестирование у нас было в чистом виде «черноящичное», без каких-либо поползновений в сторону внутренностей системы. Тестили end-user часть и админку в различных сочетаниях и взаимодействиях.

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

В назначенное время (рабочий день перевалил за середину) народ был на местах в боевой готовности. Но рабочий стенд все так же бездушно выдавал 503-ю ошибку. ПМ в бешенстве звонил во все инстанции, стараясь донести эту информацию до самого заинтересованного лица в компании. Мы продолжали «ждать ответа». Часов в 10 вечера нас распустили «по кроватям», обещая восстановить рабочий стенд к следующему утру…

Утро встретило меня уже успевшей набить оскомину 503-ей ошибкой на логин-странице тестового стенда. Просмотрев рабочий чат, я увидел там сообщение в стиле «через час все будет работать»… И так много раз за день. В общем, стенд встал только к утру понедельника. Тогда же нам поведали душещипательную историю о том, как админ взял трехдневный отгул, а кто-то из сотрудников, уходя с работы в пятницу, обесточил весь офис. После наших звонков электричество в офисе, конечно, включили, но сервер со стендом сам по себе почему-то не поднялся. Админа вернуть из отгула не получилось, а поднять сервер больше никто не мог. В итоге две команды тестировщиков и команда разработчиков 2 дня бесполезно просидели на рабочих местах, прикованные обещаниями «ща всё починим». Пилот был перенесен, заказчик негодовал…

Мораль: внезапный овертайм требует не просто лозунгов «Ребята, мы работаем до посинения!», а грамотной организации процесса!

Вывод

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

Заключение

Сказка – ложь, да в ней намек,
Добрым молодцам урок!

P.S.: Все истории основаны на реальных событиях.

Подведем итоги. На примере реальных ситуаций мы убедились в правильности трех постулатов:

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

Уберечь от большинства крупных ошибок может выбор подходящего метода управления проектами (узнать о них можно здесь). Никто не застрахован от провалов, но к ним можно (и нужно) заранее готовиться. Развивайтесь, учитесь на своих и чужих ошибках. Главное – не стоять на месте!

Обсудить в форуме.