User story

У бизнес-разработчиков за дедлайнами, сроками, клиентами и большими запусками может складываться впечатление, что инфраструктура выстраивает свой воздушный замок, который далек от того, что происходит в действительности. Захотев это изменить, Алексей Данилов из разработки перешел в команду инфраструктуры последние два года он развивает ее в Яндекс.Вертикали а это Яндекс.Работа, Яндекс.Недвижимость, auto.ru и Яндекс.Объявления.

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

Infrastructure

Под инфраструктурой я подразумеваю всё, что окружает бизнесовый код и помогает ему от начала разработки фичи до момента ее доставки. Это и базы данных, и балансировка, и мониторинг, и CI с CD. Сюда же относятся особенности разработки/работы, библиотеки, тестирование, бизнес аналитика, бизнес-специфичные возможности и много чего еще. Это как завод, на котором вместо ручного труда автоматизированы все процессы, и результат мы получаем более быстрый и более качественный.:

При этом я рассматриваю инфраструктуру как единую платформу, а не набор разрозненных частей, которые я перечислил выше. И это уместно для компании любого размера. В облаках Amazon Web Services, Yandex Cloud автоматизация может строиться, например, на основе terraform. У вас может быть собственное железо или вы его где-то арендуете и на нем может быть развернут Kubernetes, Nomad, что-то еще. Команда тоже может быть любой от нескольких человек, которые в основном используют bash или terraform, и до сотен, со своими велосипедами.

И тогда возникает вопрос как добиться идеальной инфраструктуры Platform as a Service, который мы реализуем для наших пользователей, и вообще каковы критерии идеальности? Нам не нужно разрабатывать еще один Amazon или Kubernetes поэтому достаточно небольшой и простой системы, но у нас должна быть возможность ее расширения под наши use cases. Например, если у нас есть какие-то особенные АБ-тесты, особенные условия доставки (например, канареечный релиз ) и особенные правила безопасности это как раз то, что должна закрывать инфраструктура.

Ее основой, краеугольным камнем будут минимизация/ускорение разработки, упрощение поддержки и простота использования. Остальные требования понятность, доступность, стабильность и единообразность/распространение практик, а также скрытие низкоуровневых особенностей (чтобы никому не пришлось писать самому конфиг nginx или сложный Kubernetes манифест), техническая поддержка 24*7 и связанность компонентов конечно, тоже имеют место.

Если выполнить их все, ваша инфраструктура будет не только единой платформой или сервисом, но постепенно будет превращаться в продукт, как это случилось у нас.

Infrastructure/Platform as a product (PaaP)

Сначала мы, конечно, смотрели в сторону сторонних приложений. Например, мы серьезно рассматривали Spinnaker от Netflix. Но он написан на Java, а у нас все пишут на Go, и мы не хотели добавлять еще один язык. Во-вторых, он не поддерживает Nomad и Yandex.Cloud. Следовательно, нам пришлось бы его прилично дорабатывать и интегрировать с нашими внутренними особенностями, что практически равно форку. Поэтому мы стали писать свое.

Изначально мы задумывали Shiva как абстракцию над деплоем (в нашем случае над Nomad) и как multicloud. Но сейчас она уже приросла различными системами и интегрируется со всем, что у нас внутри есть:

Основная ее часть представлена в GitHub в виде карты сервисов. Она изменяется посредством пул-реквестов, конфигурирует балансировку, контролирует деплой и различные пайплайны доставки, SOX, PCI DSS и т.д. То есть это одно описание для полноценной работы:

Архитектура Shiva в упрощенном виде выглядит так:

Сервис постоянно развивается и сейчас он уже частично похож на продуктовый: есть БД, вокруг которой построены различные микро-сервисы, есть небольшие legacy-компоненты (компонент Updater и Shiva смотрят в одну базу) и т.д. То есть с технической точки зрения он развивается как обычный бизнесовый сервис.

UI мы реализовали в Telegram, а впоследствии написали WEBовский. Telegram-бот это CLI over Telegram все команды задаются в формате CLI, но дополнены различными контекстными действиями, кнопками и т.д. Нам нравится этот подход, потому что он кросс-платформенный, его легко обновлять и к нему всегда есть доступ. Можно спокойно обновить или откатить свой сервис в случае проблем. А также очень удобный механизм нотификации, когда вы получаете уведомление о начале процесса деплоя прямо в тележку.

И хоть WEB и получился удобным, все равно часть пользователей остается в Telegram. Потому что UX меняется в профессию приходит очень много молодых разработчиков. Мы привыкли к WEB, мы привыкли использовать Telegram-боты и вообще общаться в чате. С другой стороны, мы хоть и думаем сделать CLI с такой же функциональностью, но понимаем, что запросов на это не было.

Экономика

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

Но у инфраструктуры нет доходов, тогда как на этой схеме есть и доходы, и расходы. Доход от инфраструктуры равен 0 это расход компании, а ROI будет отрицательным: сколько инвестиций не вкладывай, они не отбиваются:

Profit = Revenue - Cost = 0 - X

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

• code время написания самой логики ;

• infrastructure code время написания инфраструктурного кода (код логов, метрик, алертов и т.д.)

• environments время на настройку переменных окружения, секретов и т.д.;

• delivery время, затраченное на доставку.

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

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

Следующим нашим пунктом разработки инфраструктуры как продукта стало внедрение user story.

User story

User story это фундамент любой продуктовой разработки и используется он в любых гибких методологиях идущих от Agile. Это не детальное описание задач давайте прикрутим здесь кнопку, которая будет делать вот это. User story это намерение пользователя: какую проблему пользователь решал, как он пытался её решать, почему он её решал, почему она возникла, и, наконец, как мы можем её решить. Разумеется, из user story выводится очень много различных решений. Но сам User story не является им это основа для решения и инструмент для выявления исходной проблемы.

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

Приведу для примера две наши внутренние истории.

Пример 1. Залипает обработчик Кафки. Чинится только рестартом сервиса. Фикс в пути. Хочется иметь способ быстро перезапустить контейнеры.

Проблема была понятной и мы предложили сделать команду restart -l prod my_service, в которой указывается слой сервис, чтобы сервис рестартился через телеграм бота.

Пример 2. При обновлении конфигурации хочется перезапустить сервис без указания версии.

Решением стало: /run -l prod -v 1.0.7 my_service -> /run -l prod my_service.

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

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

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

Customer development (сustdev)

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

1. Выявляем потенциальную проблему (строим гипотезу), формируем идею или решение, но не внедряем ее, а идем к пользователям, чтобы поговорить с ними об их потребностях/болях/проблемах.

2. Встречаемся с ними, например, на кофе-поинте или на рабочем месте. Можно пообщаться и в Зуме. И в обсуждении можно обнаружить, что проблема пользователям не важна она не так много времени занимает и не так сильно его напрягает, но зато у него есть более важные проблемы.

3. Прорабатывая решение вместе, мы получаем либо изначальное успешное решение (если определили проблему верно) или более успешное (поняв из общения, что волнует пользователей) то есть в выигрыше все.

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

Эта история решилась довольно просто. Мы добавили время деплоя в аннотации на Grafana, и теперь видя какую-то аномалию, можно понять, не было ли деплоя, в том числе деплоя зависимых сервисов. Эта история, кстати, ускорила у нас создание WEB UI.

А потом мы пообщались с тимлидами и выяснили, что они это видят совсем по-другому:

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

Team leads: Нужна возможность посмотреть кто, что, когда и зачем катил в прод:

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

Портреты пользователей и сервисов

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

• Разработчики: бэкенд, фронтенд и инфраструктура;

• Team leads;

• Тестировщики/Автотестировщики;

• Аналитики;

• Менеджеры, продукты, руководители.

По сути частичное отражение рабочих позиций :)

А портреты сервисов можно классифицировать по типу, языку или размеру. Первые бывают внутренними (realtime api, back api, async, cron, gateway, и т.д.), DB, внешними, saas и т.д. И они богатая точка роста, потому что это место отказа каких-то инфраструктурных частей. Это и наша точка роста, которую мы рассматриваем в будущем для себя.

Языки разработки мы рассматриваем нечасто, но иногда приходится смотреть: почему эта история возникает, у кого она возникает, потому что, например, у java и node.js бывают небольшие различия в работе, и это приходится учитывать.

По размеру портреты сервисов могут быть: function, microservice, service, monolith, distributed monolith и т.д. И если мы, например, понимаем, что проблематика идет из распределенного монолита, то отказываем в этой истории, потому что у нас хорошей практикой считаются мироксервисы и нашим PaaS мы популяризируем и упрощаем жизнь именно с ними..

Вот для примера портрет сервиса БД. С помощью этой карты ставятся бэкапы, происходит доступ к БД на чтение/запись и т.д. Плюс, сам сервис в свои зависимости прочерчивает эту карту, и мы знаем, что это за карта и от чего она зависит то есть, мы знаем, что сервис А зависит от базы данных В:

Feature request

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

Конечно, у нас есть проблемы:

• Технически грамотный пользователь может принести уже готовое решение, например: Сделайте такой API, в БД все сохраните, и на этом хватит.

• Личное знакомство потому что иногда мы отказываем в feature request или говорим, что будем делать по-другому, и возникает небольшой конфликт.

Но есть и решения:

• Превращать в user story находить проблематику: узнавать, с какой проблемой столкнулся пользователь и как пытался решать;

• Смотреть на доработку в контексте портретов кто к нам пришел, что за сервис, о чем идет речь;

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

• Механизм голосований/рейтинга это самый мощный инструмент. Он не нов, используется во всех хороших продуктовых разработках, например, в терминале Тинькофф-Инвестиции. У них открытые feature request, где люди открыто голосуют и в итоге в работу идут те, что в топе:

Внутри это также можно легко реализовать, потому что мы работаем в рамках одного issue-трекера. Например, здесь фильтры по нашим feature request:

Из интересного: мы недавно этот вид сделали через наш WEB не таким формальным и увидели, что люди с большей охотой голосуют за идеи то есть это тоже важно:

Механизм feature request очень удобно использовать как часть синергии с пользователем и нам не нужно будет сильно прорабатывать такую историю ведь очень много пользователей проголосовали за нее. Мы можем видеть, кто голосует и это могут быть разные люди, которые поддерживают разные сервисы. Получается в итоге даже небольшой scoring функциональности мы точно понимаем и то, что она нужна, и зачем, и насколько это нужно пользователям. Голосование к тому же может заменить множество внутренних исследований таких, как сustdev.

Roadmap

Хочу отдельно сказать про Roadmap. Это кажется довольно банальной темой, но пообщавшись с разными компаниями, я обнаружил, что у команды инфраструктуры часто не бывает долгосрочного видения. Есть понимание, что они делают через неделю или месяц, но нет понимания, какой должна быть в итоге инфраструктура. И обычно это инфраструктура посредством одной кнопки, когда все описано в GitHub-репозитории и сделана она, например, на CI сборках. Куда стремиться непонятно.

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

Кстати, как получать обратную связь?

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

• Большие посты анонсы. Несколько раз в квартал мы делаем большие анонсы, где рассказываем про всю большую функциональность и опять же получаем фидбэк. Иногда мы получаем негативные отзывы, например: Зачем вы это делаете, если можно взять вот это и то. Тогда мы либо объясняем, либо понимаем, что, может и правда можно реализовать более просто.

• У нас есть групповой чатик в Telegram/Slack/Microsoft Teams. В основном мы там собираем обратную связь, хотя он работает как инструмент технической поддержки, а также в нем выкатываем нововведения с небольшими инкрементальными релизами.

• Открытые встречи для вопросов/ответов. Мы пока что провели её только один раз, но результат был неплохой.

• Еще можно встречаться на демо продуктовой разработки и там отвечать на вопросы. Но мы не проводим демо сейчас для нас это большая потеря времени.

• Еще можно использовать индекс потребительской лояльности NPS (Net Promoter Score). Это простые анкеты: насколько вы удовлетворены нашим сервисом, насколько вам удобно базовые вопросы для того, чтобы собрать общую статистику лояльности пользователей. Мы не используем NPS, потому что из чата получаем и критику, и позитив, а остальных записываем как нейтральных пользователей.

MVP

После планирования хочу напомнить про инструмент MVP (Minimum Viable Product). Это известный подход, но в инфраструктуре есть нюансы. Мы, как любой бизнесовый продукт, выкатываем частично недоделанный продукт, где-то не самый удобный, но минимально рабочий. Потому что мы не можем делать 2-3 месяца какую-то историю, выкатить её, получить средний фидбэк и потом еще месяц переделывать:

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

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

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

Overkill

Важно понимать, когда продуктовый подход становится слишком сложным. Бизнесовые команды становятся настолько большими, что состоят из множества людей с разной направленностью и спецификой. Есть product owner, цель и задачи которого выстраивать roadmap и определять, какие из историй делаются. Есть product менеджер, UX-специалисты, разработчики, тестировщики и т.д. Когда большие истории разбиваются только по user story и пытаются делать с добавлением какой-то пользовательской ценности. Всё это очень круто, но сейчас для нашей команды это overkill. Как в принципе, и A/B-тестирование.

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

• Стараться понять: Зачем? То есть не Разработчик хочет 500 Тб БД, а: Разработчику нужно сохранять информацию о машинках (которую мы никогда не сохраняли) тогда мы сможем работать вместе над одной проблемой пользователя

• Добавить в команду продуктового разработчика, потому что DevOps расширяется, кода мы пишем сейчас больше, и нужен разработчик, который пропитан этой атмосферой.

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

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

• Собирать roadmap и сделать его открытым.

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

• Нужно много автотестов , так как я все еще не представляю вакансии тестировщика в команде инфраструктуры, как и дизайнера по крайней мере в 2021 году.

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

Итог

В заключении рекомендую книгу Психбольница в руках пациентов Алана Купера я ее прочитал очень давно и с огромным удовольствием, она меня вдохновила. Сейчас настало время, когда ее стоит рекомендовать не только product owner, продуктовым разработчикам, дизайнерам, но и команде инфраструктуры. Там очень много полезных примеров, в которых можно найти себя.

Подытоживая:

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

• Относитесь к внутренней инфраструктуре как к единой платформе, как к единому PaaS.

• Разрабатывайте PaaS как полноценный внутренний продукт.

• Используйте проверенные простые продуктовые подходы, но только те, которые окажутся простыми. Если тот или иной подход (тот же сustdev или портреты пользователей) кажется сложным, возможно, сейчас их не стоит использовать.

• Повышайте ценность PaaS (скорость/расходы разработки/поддержки).

• Создавайте современные интерфейсы.

• Примите, что современная команда инфраструктуры приближается к продуктовой. Её уже официально называют командой DevOpsеров. Эта мифологическая команда приближается к продуктовой по своим требованиям и тому, как она должна работать. Следование новым веяниям и использование современных подходов поможет создавать действительно удобную инфраструктуру

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

Профессиональная конференция DevOpsConf 2021 пройдёт 31 мая и 1 июня этого года в Москве, в отеле Radisson Slavyanskaya. Расписание уже сформировано. На сайте вы можете познакомиться с программой и спикерами.

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

До встречи в оффлайне!

За пять лет работы в Аркадии компании-разработчике программного обеспечения на заказ, где я работаю тестировщиком, мне довелось поучаствовать в самых разных проектах. Большая часть из них была связана с веб-разработкой, меньшая с мобильной. Некоторые проекты длились более года, другие были краткосрочными (полгода или даже пару месяцев). Менялся и размер команд: от трёх до трёх десятков человек.

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

Как всё начинается

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

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

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

Или другой пример. Есть работающий сайт, который заказчика устраивает. К сайту заказчик хочет разработать мобильное приложение, в которое нужно добавить несколько небольших новых фич.

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

Когда и как начинается тестирование

Тестирование на краткосрочном проекте начинается с Shift left, то есть со сдвига тестирования влево относительно традиционного места в хвосте производственной цепочки, состоящей из определения требований, анализа и проектирования, кодирования, тестирования и развертывания.

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

Источник картинки:https://devopedia.org/shift-left

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

Вопросник: тестирование концепции

Целевая аудитория и условия использования ПО

Материальная база тестирования на чём тестируем

Интеграция с тем, что уже есть

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

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

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

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

Описывая ожидаемое поведение, тестировщик закладывает базу для чек-листов, выявляет противоречия и пустые места. А затем находит ответы, задавая вопросы программистам и заказчику. Так мы отлавливаем часть багов ещё до того, как софт попадает на проверку. Иногда даже до того, как программист напишет код.

Тестировщик берёт требования в том виде, в котором они есть. Допустим, это будут user stories (пользовательские истории).

1. User story

Userstory(пользовательская история) состоитиз заголовка, представляющего собой основной сценарийиспользованияи дополнительныхсценариевсконкретикой.

Дополнительные сценарии могут быть описаны в критериях приёмки (acceptance criteria). О том, как их можно конкретизировать, я расскажу позже.

AcceptanceCriteria

2. Глоссарий проекта

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

а) понятия, упомянутые в истории, понимаются одинаково всеми участниками разработки. Например, под словом упражнения команда разработки и заказчик имеют в виду одно и то же;

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

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

Пример глоссария

3. Умолчания и дополнения

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

После восстановления умолчаний задаём вопросы для получения дополнительной информации:

4. Acceptance Criteria основа для чек-листа

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

а) конкретизируемAcceptanceCriteria;

б) закладываем основу для чек-листа.

Далее переходим к созданию основы чек-листа. На этом этапе выкидываем обороты типа система должна и также ожидаемо и отжимаем текст от воды до списка требований по пунктам.

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

После того, как были конкретизированыAcceptanceCriteria, переходим к тест-дизайну.

Тест-дизайн и тестирование прототипа

Заголовок user story становится заголовком для группы проверок. Acceptance Criteria становится заголовком отдельного чек-листа или интеллект-карты, куда мы выписываем и ранжируем проверки.

Что получается в результате

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

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

Примеринтеллект-карты

Источник картинки: автор статьи

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

В параллель с тем, как тестировщик пишет чек-листы, UX/UI-дизайнер создаёт прототип. Тестировщик проверяет интерфейс прототипа, корректирует чек-листы, обсуждает найденное с командой.

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

Специфика тестирования в краткосрочном проекте

В краткосрочной разработке нет привычной нам рутины: планирование спринта спринт демо ретро, но есть промежуточные дедлайны. Однако есть пользовательские истории, описывающие функционал разного приоритета, который, согласно этим приоритетам, реализуется. Тестирование идёт параллельно с написанием кода.

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

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

Пример позитивного кейса

<Пользователь может делать задания с 9:00 утра до 8:59 вечера>

Затем мы проверяем негативные кейсычто у юзера ни в коем случае выйти не должно.

Пример негативного кейса

<Задания недоступны для просмотра и выполнения с 9:00 вечера до 8:59 утра>

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

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

Жизнь после релиза

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

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

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

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

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

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

Заключение

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

Далее следует этап тестирования требований, во время которого тестировщик создаёт максимально целостное и непротиворечивое описание продукта и его работы. Здесь идёт работа с user story и acceptance criteria, на основе которых тестировщик составляет чек-листы и интеллект-карты со списком конкретных проверок.

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