Почему полезно наступать на грабли, или 5 пропущенных багов Manual QA
Меня зовут Михаил, и я мануальный тестировщик. Написал эту статью, чтобы предостеречь вас от моих граблей и подарить бесценный шанс наступить на собственные. В материале вы познакомитесь с примерами багов, которые стоили их автору бессонных ночей и седых волос. Читать о чужих ошибках всегда полезно, ведь можно сэкономить много своего времени и нервов или просто улыбнуться над ситуациями, описанными ниже. Статья будет поучительной для новичков и развлекательной для опытных тестировщиков.
У многих начинающих тестировщиков возникает желание узнать побольше о собеседованиях и том, какие вопросы там часто задают. Вопросы на знание теории или такие, которые требуют конкретного ответа, обычно не вызывают проблем, если, конечно, к интервью готовиться. Но бывают те, на которые нельзя дать однозначный ответ. Их специально задают кандидату, чтобы понять, как тот думает, как выстраивает логические цепочки и разбирается с чем-то, о чем нельзя просто прочесть в литературе.
Один из таких вопросов — просьба рассказать о багах, которые специалист пропускал в своей практике. Таким образом кандидат может проанализировать последовательность действий, приведшую к возникновению ошибки, и описать, какие шаги необходимо было предпринять для недопущения такой ситуации в будущем. Пропущенные баги, если они были серьезными, — это грабли, наступая на которые получаешь болезненный, но запоминающийся опыт.
Существует даже такая система оценивания опыта, при которой учитываются провалы в карьере человека, а не его успехи. Успех в немалой степени связан с везением, какой-нибудь сложный и опасный баг можно воспроизвести и случайно. А вот набитые шишки — это уже опыт, который сложно забыть, и любой здравомыслящий человек предпримет все меры для того, чтобы избежать подобных ошибок в будущем.
Но где молодому специалисту взять такой опыт? Для этого я составил свой топ-5 самых больших багов, которые были пропущены на моей практике. Это не то же самое, что столкнуться с ними и их последствиями лично, но все же лучше, чем полное отсутствие опыта и, как следствие, неспособность ответить на распространенный вопрос на собеседовании. Для своего списка я выбрал ошибки из двух областей тестирования: из разработки игр и разработки веб-приложений. Итак, приступим.
Иллюстрация Алины Самолюк
1. День, когда игра остановилась
Немного предыстории. Баг произошел на крупном игровом проекте, разработку которого вела распределенная команда из нескольких стран. В какой-то момент отдел разработки по своим внутренним причинам решил поменять систему ID на проекте. На новом билде это ни на что не повлияло, поэтому они не сообщили об изменениях ни отделу тестирования, ни другим смежным отделам. Лога изменений или другой документации тоже не было. Несмотря на то, что проекту было уже три года, описаны были только самые базовые вещи.
В итоге, когда в новый билд подключался сейв от предыдущего билда, ID, отвечавший в нем за отметку о пройденном туториале, был невалидный, и игра считала, что игрок еще не прошел обучение. Запускалась последовательность туториала. Вот только игрок к этому моменту мог быть уже на дальних уровнях, где выполнить требование обучения невозможно. А пропустить его было нельзя, оно блокировало все управление.
Новый релиз был привязан к одному из праздников, поэтому был завязан на фичеринг в магазине приложений. Отложить его было нельзя, и он ушел на лайв. В результате у всех игроков, у которых был прогресс (а игре, как я уже упоминал, было три года), игра останавливалась. Совсем. Немного спасало ситуацию то, что билд становился доступен игрокам постепенно, в первую очередь в неплатящих странах. Нас ждала бессонная ночь и хотфикс, которым мы сделали туториал необязательным. Благо сам билд позволял такие изменения отправлять без перезаливки его в магазин.
Грустно, что ошибка была обнаружена еще до релиза. Баг переоткрывался восемь раз, но каждый раз попадал к одному и тому же разработчику, который его отметал с пометкой, что это сломанный сейв. Да, у разработчиков было право закрывать баги самостоятельно, без вердикта тестировщика. Здесь, конечно, со стороны QA нужно было настаивать и биться за эту ошибку. Доказывать, что она присутствует и ее необходимо исправить. Но распределенная команда, когда нет возможности даже подойти и переговорить, не позволила предотвратить этот серьезнейший недочет.
Как же можно было бы избежать этой ситуации? Налаженной коммуникацией между командами, документированием изменений, созданием обязательных проверок обновлений (на жаргонном языке это «накатывание», когда старую версию билда обновляют до новой версии) и изменением жизненного цикла бага, когда он не может быть закрыт и забыт без учета мнения команды тестирования.
2. Фикс, который пользователи приняли за баг
Это случилось на игровом проекте, который обладал званием «Игра года» на фейсбуке. Система монетизации игры была построена на том, что в случае, если игрок не проходит уровень, он теряет жизнь. Всего жизней пять, и, когда они заканчиваются, играть дальше нельзя, но можно докупить их за деньги или ждать, пока они восстановятся по таймеру. Также можно было попросить жизни у своих друзей, которые тоже играли на фейсбуке. Эта функциональность была нужна для бОльшего вовлечения игроков, которые заходили в игру, чтобы помогать друг другу. Именно здесь и был баг.
Игрок мог отправить запрос на пополнение жизней сколько угодно раз, а другой игрок мог такое же бесконечное количество раз их отправить. Таким образом, имея всего два связанных аккаунта на фейсбуке, можно было перекидывать самому себе жизни бесконечно долго, ничего не тратя на их пополнение. Не удивительно, что игрокам эта функциональность очень нравилась.
Когда этот баг обнаружили, продюсер проекта слегка побледнел, потому что, по самым осторожным оценкам, это лишило компанию многих потенциальных покупок. Причина его пропуска была до банальности проста: тестировщик создавал себе второй аккаунт, тратил жизни на одном, отправлял запрос на второй, возвращал жизнь, убеждался, что она пришла, и считал проверку пройденной. Даже если он отсылал себе таким образом несколько жизней, подозрений у него не возникало, так как никакой документации, которая бы описывала этот функционал в игре, не существовало.
Что могло бы предотвратить такую ситуацию? Документация, описывающая функционал, четко и однозначно составленная проверка, ну и умение тестировщика взглянуть на проект чуть шире, чем просто на набор функций, и подумать, как именно он зарабатывает. Последнее справедливо вообще для всех участников разработки, будь то игры или другие приложения. Часто за частоколом текущих задач теряется видение, зачем мы вообще работаем, но это тема для отдельного материала.
Когда баг исправили, игроки завалили службу поддержки жалобами на то, что их любимый функционал по бесплатному пополнению жизней перестал работать, но было поздно — дырка в монетизации была прикрыта.
3. Айтем, который уничтожит вашу игру
Этот баг был не таким дорогостоящим, как первые два, но зато гораздо более зрелищным. Когда он происходил, игра крашилась и после не запускалась. С чего все началось? Сперва это был игровой проект на смешении жанров. Основной механикой был тайм-менеджмент: нужно было успевать обслуживать клиентов в закусочной. Зарабатывая очки, игрок строил новые кафе и таким образом развивал город. Второй механикой был простенький сити-билдер, в котором пользователь строил домики и проводил дороги, чтобы у закусочных были клиенты.
В какой-то момент от второй механики решили отказаться и создали одну большую карту, на которой уже были построены все домики и закусочные. Их нужно было только открыть по мере прохождения игры. От сити-билдера остались только декоративные украшения в виде лавочек или цветов, которые можно было расставить вокруг своих кафе. При открытии второго заведения на карте появлялся небольшой айтем в виде лавочки. Его можно было переместить, повернуть или положить в инвентарь. В последнем случае игра крашилась. Причем не только первый раз, но и все последующие разы, когда подгружался сейв.
Дело было вот в чем. Лавочка возле заведения осталась еще с тех пор, когда игра имела в себе элементы сити-билдера, но теперь она стала декоративным предметом, который должен был появляться в качестве награды в середине игры. И в момент, когда игрок добавлял айтем себе в инвентарь, на сейве возникал предмет, которого не могло существовать на данный момент игры. От чего, собственно, она и падала.
До пользователей этот баг, к счастью, не дошел, но потребовал серьезного рефакторинга билда. Тут, как и в предыдущих случаях, ситуацию могла бы спасти документация, описывающая изменения, или хотя бы коммуникация с командой разработки, которая также отсутствовала.
4. Маленькая деталь, которая ломает все
Чтобы разнообразить наш чарт ошибок, добавим пару примеров из веб-разработки. От клиента поступил заказ на редизайн сайта для одного из лучших ресторанов Лос-Анджелеса, находящегося на Беверли-Хиллз. Все очень серьезно и пафосно. Была тут одна особенность — заказчик попросил не делать сайту бэкенд, так как зарабатывал на том, что предоставлял конечному клиенту услуги по поддержанию платформы. Если бы там была возможность удобного редактирования контента через админпанель, помощь нашего клиента владельцу ресторана была бы не нужна.
Поэтому мы все сделали на обыкновенных HTML-страницах. Но был нюанс: у ресторана часто проходили акции, мероприятия и все такое. Под них создавались свои лендинги, и ссылки на них нужно было помещать в header сайта. Не проблема, если у вас есть админка, но ее не было. А вот страниц на сайте присутствовало полторы сотни, поскольку здесь выкладывали еще и рецепты от шеф-повара.
Мы предложили реализацию, при которой header и footer были бы отдельными файлами и подставлялись к каждой странице. Так можно было бы редактировать их из одного места. Быстро и удобно.
Никакой документации на сайт не было, и мы делали его только по макету из фотошопа. С клиентом общался менеджер, и прямой связи с ним ни разработчики, ни тестировщик не имели. Сверстав проект с точностью до пикселя, мы передали его на ревью. Клиент вроде как дал добро или его так понял менеджер, и проект залился на лайв-сервер. Поздравив друг друга с еще одним довольным клиентом, мы пошли домой.
Что тут началось! Клиент сначала написал, потом и позвонил, со слезами умоляя починить то, что мы наломали. Оказалось, что мы упустили такую малость, как систему бронирования мест в ресторане. Как нам позже эмоционально объяснял заказчик, в ресторане бронируется мест на 50 000 долларов в день, так как он известный и очень популярный. А мы все сломали. Этот баг, конечно, глупый, но показательный.
Как я уже замечал выше, мы часто забываем об общей картине. Сайт был проверен по всем требованиям компании в полнейшем соответствии со всеми процедурами и этапами, принятыми для таких проектов. Но то, что кажется очевидным для клиента, для тестировщика может таким не быть, если оно не описано. Поэтому важно не забывать об общей картине, это не раз спасет.
5. Тяжелое наследие
В примерах выше я уже рассказывал о том, что бывает, когда нет хорошей коммуникации. Этот кейс не станет исключением. Был у нас клиент, который разрабатывал большое приложение для управления трудовыми ресурсами в корпорации. Программа умела все: учитывать рабочее время, фиксировать переработки, отпуска, больничные, вести расписание внутренних занятий и тренингов, собирать фидбеки от работников, вносить запросы на финансирование курсов повышения квалификации. Учитывала даже расходы на уборку помещений офиса.
Нам же, как подрядчику, досталась разработка фронтенда, который представлял собой кучу таблиц. Заказчик был из Франции, разработка шла спринтами, и он просто раз в пару месяцев присылал несколько новых макетов на разработку. Мы их делали, отправляли обратно и даже ни разу не получили фидбека. В команде шутили, что француз, наверное, просто не знает английского и не может его написать.
Время шло, и часть разработчиков уволилась, часть перевелась в другие отделы. Получилось так, что в команде не осталось ни одного человека, который бы имел опыт работы с этим проектом. Не так уж редко такое бывает. И вот, новый, молодой и перспективный разработчик получил очередную порцию таблиц для верстки. Все было сделано по макету. Тестировщик, сверив с макетом, убедился, что все соответствует дизайну. И только после передачи проекта клиенту выяснилось, насколько все плохо.
Не зная о том, что проект существует уже долгое время, разработчик создал все стили заново и таким образом перебил старые. Когда его стили добавили на уже существующие страницы, они разлезлись и весь проект перестал работать так, как следует. Таким образом мы выяснили, что клиент очень даже неплохо владеет английским, особенно в области крепких выражений.
Всех бы могла спасти документация. Даже самая простенькая, которая бы сообщила последующим поколениям разработчиков о том, что тут происходило до них. Но, как это часто бывает, все знания по проекту участники разработки носят у себя в голове. И когда эта голова отправляется в другой отдел или компанию, все ее знания уходят вместе с ней. Документация — это, возможно, не самое увлекательное, что есть в сфере IT, но она, как спасательный круг, поможет во время шторма.
На этом буду заканчивать свой топ. Конечно, это не такие эпические баги, как ошибки в работе системы управления Boeing 737 МАХ, приведшие к падению двух рейсовых самолетов с пассажирами на борту. Или баг в системе наведения ракет «Пэтриот», который приводил к промахам во время войны в Персидском заливе, из-за которого пропустили ракету «Скад», убившую 28 человек в американском военном лагере. Но это все живые, настоящие примеры, которые может и не будут такими запоминающимися, как ваши личные шишки, но все же помогут обойти пару граблей на своем пути. Я уверен, что у многих найдутся похожие истории. Призываю описать их в комментариях.
