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

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

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

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

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

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

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

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

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

Когда я только начинал работать в отрасли электроники в начале 2000-х и мечтал создавать серийные устройства на острие технологий, то мог рассчитывать только на собственные ресурсы. Не было доступа к западным рынкам свободного капитала, менторов, хабов и акселераторов всего того, что сейчас формирует hardware-экосистему, да и доступ в интернет в те времена только недавно заработал без Dial-Up :-).

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

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

Конечно, есть бизнесмены, которые осознанно запускают аутсорсинговые компании: они с самого начала мыслят категориями роста и операционной эффективности, относительно быстро преодолевают планку в 200500 сотрудников и выходят на новые рынки. В этом состоит их цель и самореализация. Но есть и те, кого просто занесло в эту гавань в силу обстоятельств: обычно такие компании работают в составе 50200 сотрудников с несколькими миллионами оборота и годами остаются на этом плато.

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

Этапы развития сервисной модели и точки для разворота

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

Так когда надо сворачивать?!

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

• Предпринимательская: главный по продажам, главный конструктор/инженер/архитектор.

• Административная роль: главный по проектам, главный по операционной работе.

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

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

То, что я имею в виду под ролями, очень похоже на то, о чем пишет в своих работах Ицхак Адизес. Вот его код PAEI: P производитель результатов, A администратор, E предприниматель, I интегратор.

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

На этом этапе гораздо сложнее повернуть к продуктовой модели, но все еще возможно.

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

На этом этапе свернуть обратно к продуктовой модели будет почти нереально без трансформации всего бизнеса.

Что делать?

В случае когда пройден третий этап, вместо разворота разумнее сохранить компанию в неизменном формате и сделать следующее:

1. Передать управление и предпринимательскую роль кому-то из своих партнеров внутри и позволить им свободно принимать ключевые решения вместо вас.

2. Очертить свою новую роль в компании. Например: я остаюсь в качестве владельца и обозначаю стратегический вектор развития компании.

3. Переключиться на продуктовую модель в рамках новой компании, опираясь на весь свой накопленный опыт и хватать за хвост новые идеи. :-)

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

Выводы: триггеры на пути к мечте и что дает аутсорсинг

Вернемся к тем, кто только стартовал, и для создания своего первого капитала и приобретения бизнес-опыта вступил на путь сервисной бизнес-модели. Итак, если вы только начинаете и готовы преодолевать препятствия на пути к своей продуктовой цели, то вполне можно посвятить 1-2-3 года работе по сервисной модели, но помнить о риске застрять в этой модели надолго и обращать внимание на важные триггеры, которые подскажут, что пора поворачивать к своей мечте:

1. Собралась крепкая команда профессионалов из 1020 сотрудников с высоким уровнем доверия друг к другу. Соответственно, дальнейший рост в текущей бизнес-модели будет только усложнять разворот к продуктовой модели.

2. Роли стали трансформироваться в функции и должности в компании это знак того, что нужно переключаться на продуктовую модель либо целенаправленно сохранять аутсорсинговую компанию.

3. Третий триггер, наверное, самый главный удовольствие от своего дела. Если нет драйва и вы не видите смысла в росте и масштабировании, то есть риск остаться в нише середняков в аутсорсинговой модели в будущем.

А тем основателям и владельцам, у кого аутсорсинговая компания надолго застряла на плато в 50200 человек, пора задуматься: Своим ли делом вы занимаетесь?

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

• получить нужные компетенции, первый бизнес-опыт и знания об отрасли;

• собрать и сработаться с командой;

• развить свой нетворк сеть бизнес-контактов.

Выбор как всегда за нами! А вы в какой лиге сейчас? Давайте вместе решим, что делать дальше!