Долго сидела девица и думала: что такого она умеет делать, за что ей платят денюжку. И тут осознала, запускать крупные стрессовые проекты. Быть QA для тревожника - это ну мед, медятина. А если еще ты вечная стартапница, кортизоловые горки обеспечены. Так как браться за объемные проекты, которые нужно было сделать "еще вчера" и при этом не отъезжать в отпуск в пнд?

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

А еще тут набор базовых правил, которые в принципе и так известны человечеству, но как и в случае здорового образа жизни лишним не будет проговорить о главных принципах (иначе откуда было бы столько коучей в нашем времени)?

Смоделируем ситуацию:

Большой эпик (1 шт) стремящиеся к MVP
Отсутствие документации и полного объяснение в тикетах (1 шт)
Устные договоренности, о которых ты не имеешь понятия (до бесконечности)
Запуск через неделю (1 шт)
Готовность задач (-1 шт)

Ну вот получилось так, и вариант лечь и плакать не особо поможет. Что можно сделать в такой ситуации?

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

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

Где брать информацию?

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

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

Какая главная цель? Сюда же влетает понятие ожидаемого результата от фичи
Кто получатель фичи? Определение агентов
Какое пользовательское действие выполняется? Тут подсвечивается понятие минимального хеппи пасса, без которого существование фичи в принципе не возможно
Какие особенности закладывается в поведение пользователя? Тут расширяется понятие пользовательского сценария и отказов
Какие особенности есть у самой системы? Тут мы влетаем в согласованность продукта и его технических возможностей

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

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

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

Итак, мы изучили тикеты. Нам стала более менее понятна ситуация целиком, но все еще куча куча вопросов. Что делать дальше? Знакомимся с дизайном. Да-да, я не забыла про него.

2. Здравствуй, фигма

Для начала закинь ссылку в свою вики. Это обязательное упражнение на каждом шаге.

По дизайну работают несколько принципов, которые удобны лично для меня:

Сначала посмотреть хеппи пасс без деталей, сосредоточившись на переходах
Далее посмотреть на большие блоки компонентов и отсматривать переходы внутри компонента
Попытаться соединить увиденное с прочитанным

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

И, да, до перехода к самому тестированию мелкие детали не важны. То есть шрифт на кнопке в пикселях как и ширина отступов не сделает нам погоды. Мы все еще на этапе понять, что происходит, а не утонуть в лавине вопросов и деталей.

И если вы еще со мной, то мы переходим от доступной информации к той, за которой придется побегать. Что делать если вы прочитали все, что было по требованиям, а у вас до сих пор обезьянка бьет в тарелки в голове? Спросить вопросы у знающих.

3. Бегущий за Продактом

Команды разработки бывают разные. Где-то за агрегацию информации отвечают аналитики, где-то еще разные менеджеры, но в основном главным носителем гена является продакт менеджер. Особенностями команд, в которых я работала, было что за донесения бизнес идеи до команды отвечали именно ПМы. Так, что обратимся к ним.

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

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

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

С перепиской все намного сложнее. Из плюсов текст сохранится для истории, из минусов такой диалог в основном как раз таки и стремится к бесконечности.

По итогу у нас две стратегии:

Созвон
Переписка

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

И еще раз напоминание: занеси все это в вики.

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

Как тестировать?

Теперь перейдем к самому важному.. Как это чудище тестировать?

По всем гайдам, по всем наставлениям, по всем правилам все-все говорят, что нужно составить тест план, применить все техники анализа, расписать тест-кейсы и идти по шагам. Пфф.. подержите мое пиво! Я бы хотела взглянуть на человека, который реально решится сделать так, когда вокруг аврал, сроки горят и тебя пингуют со всех сторон. Представляю реакцию команды, если я на дейлике скажу: " ну я задачу не смотрела, так как целый день писала тест-кейсы". Так как быть в данной ситуации? Без какого -то пула проверок и примерного плана тестирование действительно невозможно. Ты просто утонешь в проверках и закопаешься в оттенках кнопки.

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

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

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

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

Список грузиться при скролле
Сортировка списка по рейтингу авторов (граничные значения рейтинга: утрата, получение, блокировки, удаления аккаунта, бонусы для автора (например, держать в топе).
Сортировка списка по новизне

Тут имеется ввиду не интерфейсная сортировка, а тот запрос на бэке, который формирует список.

Действия со статьями (создание, удаление, скрытие для определенной группы пользователей, архивирование) - все что влияет на обновление списка
Статусы пользователя (список для авторизованных, персонализация, список для неавторизованных, локализация)

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

Список грузиться при скролле

2. Сортировка по рейтингу

3. Статусы пользователя

4. Действия со статьями

5. Сортировка по новизне

Почему именно так? Разберем. Первый пункт в принципе отвечает за саму сущность приложения предоставления информации (если мы не будем отдавать статьи, то какой смысл в кирпиче). Второй пункт - это сущность самой задачи. То есть если у нас не будут продвигаться наши подписочные авторы, то денюжку мы не заработаем. Если первый пункт отвечал за целесообразность всей системы, то второй за целесообразность задачи. Почему статусы пользователя важнее действия со статьями? Представим ситуацию. У авторизованного пользователя уже много лет была настроена своя системы рекомендаций статей. Вот нравилось ему читать про правильное питание хомячков. Он бережно выверял свои алгоритмы и все его устраивало. А тут мы решили пошатать витрину. И заходит он после нашего релиза к себе и у него святой рандом из режима сна хомяков и хомячки путешествуют. И таких пользователей у вас условно 1000. В общем и целом, будет плохо. Пользователь скорее не заметит, что какая то статья недоступна из общего пула (например, ее удалили, но она отображается в списке). Или другая сторона. Например, у вас международный сервис. Нужно помнить о юридических и законодательных обязательствах. В Лапландии ваше приложение пользуется популярностью, но законодательство страны запрещает распространение информации о личной жизни хомячков. А вот в Нирване наоборот пытаются поднять популяцию грызунов. Тут уже у компании могут появится юридические риски попасть в блок листы, потерять значимую часть аудитории и репутацию. Системы ролей обычно всегда неспроста придуманы. Следующие два пункта будут идти средним приоритетом, но в принципе не блокером к нашей версии MVP, если только не будет вести к падению. Например, создали статью и она не отобразилась в общем пуле? Грустно, не вкусно, но жить в первое время возможно. Но если создали статью, а она сломала витрину (это другое). Спорно? Но мы держим внимание, что мы информационно - справочный портал, а не новостной. Сортировка по новизне: тут риски минимальные. Не будет у нас впереди статьи только что опубликованной, будет неудобно для пользователя, но если у него есть обходные пути, как попасть на новые публикации, то некритично. Пользователь может перейти к своему любимому автору и увидеть нужную ему свежую статью.

Вот вы составили чек-лист своих проверок. А когда уже тестить? Остался последний пункт. Дойти до разработчика. Да, я не забыла про них. Просто считаю, что не стоит дергать разработчика до прям перехода к тесту. И есть несколько на то причин. Во-первых, главное правило тестировщика - не выяснять ожидаемый результат у разработчика. Во-вторых, не доверять словам разработчика. На моей практике в начале пути были мои первые блокеры после слов: "да все там идеально работает, поверь мне". Как бы я не любила свою команду, но не отхожу от этих принципов. Так с какими вопросами идти к разработчику? За техничкой. Это вопросы по доступам, тест данными, архитектуре работы фичи (куда-что записывается, редактируется).

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

У вас в любом случае во время проверок появится позыв еще несколько раз добежать до продакта, но в принципе тут уже обычный флоу работы.

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

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

Поздравляю! Вы выжили и сделали проект.

Но подожди! А как же тест-кейсы? Куда их то впихнуть в этой схеме? Тест-кейсы нужны, безусловно. Они станут теми якорками для проведения регресса, смоуков, дополнительным источником информации для новых сотрудников. Лично я их пишу уже после релиза фичи. Дерзко? Да. Почему именно тогда? Потому что цикл живучести фичи зависит от первой недели. Сразу после запуска смотрится ее стабильность. Дежурка на стреме. Мы же помним про принципы тестирования? Прикрыться со всех сторон при всем желании не получится. Есть такие товарищи, которые любят исключительно выползать на продовой среде. Тестовая среда, даже максимально приближенная к проду, все равно остается тестовой средой, которая не сможет повторить распределение серверов, реальную пользовательскую нагрузку. Так вот. Тест-кейсы я пишу после того, как появляется понимание, что фича встала. Из чек-листа я беру самые критичные пункты для смоуков и все остальные для регресса. По сути ваш чек-лист - это список заголовков ваших тест-кейсов. Далее уже потихоньку добиваете документацию по проекту.

Итак, подводим итоги

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

И вот выжимка:

Потрать свое время на изучения доступных материалов до вопросов
Декомпозируй от большего к малому
Челлендж вопросами тех людей в рамках их областей и ответственности
Придерживайся плана
Агрегируй информацию
Не паникуй :-)

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

P.S: эта статья отображения моего личного видения и не претендует на 100% истинность. В мире столько подходов, сколько и людей. Просто надеюсь, что кому -то это будет полезно, так же как и мне.

Ну, поехали! Или как запускать проекты (QA)