Старые сказки на IT-шный лад, или Истории о фантастических «факапах»

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

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

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

Когда-то я работал в небольшом филиале крупной компании, выпускающей игрушки для мобильных устройств. К сожалению, тестирование в фирме было налажено, мягко говоря, не лучшим образом. Команда тестирования на тот момент состояла из 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.: Все истории основаны на реальных событиях.

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

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

Об авторе

Разработчик.

Поиск
Облако меток
8 марта (1)api (5)ISTQB FL (1)IT (1)kpi (1)kpi в тестировании (1)postman (1)Quality lab. Meetup (2)regress тестирование (1)rest api (2)scrum (1)scrumban (1)smoke тестирование (1)soap api (1)sqa days (1)TDD (2)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)День рождения ЛК (1)День смеха (1)Мероприятия (2)ПОИНТ (3)Приёмочное тестирование (1)РИТ (1)Эльбрус (1)Юмор (2)автоматизация тестирования (7)аудит (2)аудит тестирования (2)аутсорс (5)баги (4)банковские приложения (1)бесплатный вебинар (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)галеры_qualitylab (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (3)ежемесячный отчет (14)интернет-магазин (1)исследовательское тестирование (2)коммуникации (4)конфликты (2)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (22)лайф-хаки (4)локализация (1)медицинское ПО (1)международные проекты (1)метрики (3)модель ситуационного лидерства (1)мотивация (3)новый год (3)обеспечение качества (13)обучение (8)онлайн-конференция (1)оптимизация тестирования (12)оффлайн тренинги (1)поздравление (2)поздравления (6)пользовательские истории (1)пример (2)проблемы (3)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (6)разработчики (1)распределенная команда (3)решения (4)ритейл-приложения (1)сертификация ISTQB FL (1)собеседование (1)специализация (2)с чего начать (2)тест-анализ (2)тестирование (49)тестирование безопасности (3)тестирование для бизнеса (2)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удаленная работа (1)удобство использования (2)управление проектами (3)управление рисками (1)успехи (6)целевая аудитория (3)юзабилити (3)
Получите совет