Как оптимизировать процесс тестирования ПО и повысить качество продукта?

Все хотят делать качественные ИТ-системы, чтобы на «проде» ноль багов, а пользователи были счастливы от нажатия каждой кнопки. Мало у кого получается, потому что это сложно, не всегда понятно… и вообще, дотащить бы таску до статуса Ready to Test, а там будь что будет. В этой статье основное внимание уделим именно процессам. Логично, что если процесс производства плох, то и продукт получится не очень.

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

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

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

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

Это целая пачка проблем. Здесь и непонимание метрик качества проекта, и того, какой профит для бизнеса и продукта получится на выходе. Как итог, если специалиста по качеству и подключают, то в конце проекта, и ему уже сложно что-то менять. Аналогично и QA-инженер в команде видит таску, когда она попала в колонку “готово к тестированию”, и мало влияет на процесс разработки.

Мы рассмотрели самые частые причины отказа от тестирования. Но как понять, что наш текущий проект страдает от отсутствия или недостатка качества? Вот список симптомов назревающей «качественной недостаточности»:

1. Документация по проекту есть, но разобраться в ней может только тот, кто её написал.
2. Бэклог переполнен багами разной приоритетности, часть из которых плохо описана или уже не воспроизводится.
3. Всплывают серьезные ошибки в давно написанной функциональности (регрессионные баги).
4. Нет никакой «страхующей» документации. Непонятно, что было протестировано, когда и какие были результаты.
5. Нет человека, полностью понимающего работу системы с точки зрения функциональности и бизнеса (т.к. разработчики отвечают за код, а заказчики обычно за бизнес).
6. В конце спринта всё начинает гореть и дымиться, происходят авралы (нет, это не норма!).
7. Тестировщики не начинают работать над задачей, пока не закончится разработка.
8. Нарушаются первоначальные оценки времени и затрат из-за непрогнозируемого количества доработок и багов.

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

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

• Нестабильная работа
• Плохая документация
• Большой бэклог доработок и рефакторинга, которые некогда делать, так как фичи сами себя не напишут

Так идет до момента X, когда становится очевидно, что эту махину нужно срочно реанимировать, потому что решением уже сложно пользоваться.

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

Есть разные этапы разработки, на которых можно обнаружить ошибки:

1. Подготовительный этап до начала разработки: тестирование требований, прототипов, макетов.
2. Поиск и анализ проблем на тестовом окружении: функциональное тестирование проекта, описание багов и их дальнейшее исправление;
3. Рабочее приложение в продакшене: баги, которые нашли пользователи, а не команда разработки. Третий этап — самый богатый на негативные последствия. 

Например:

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

Расходы значительно растут от этапа к этапу. Это тот самый график удорожания бага с течением времени.

Это база. Многие знают её в теории, но на практике до 80% написанных требований избыточны, некорректны или никогда не используются. Понятно почему: хочется побыстрее начать разрабатывать, показать результат заказчикам и инвесторам. В итоге на второй этап попадает больше багов, чем могло бы, а если процесс тестирования оставляет желать лучшего, то и на третий этап заходят критичные ошибки.

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

Как же нащупать то самое заветное качество, чтобы радовались и заказчики, и клиенты, и даже команды разработки? Базовый принцип нашей компании: 

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

Сильно на процесс разработки влияет майндсет всей команды. Для его выстраивания важно понять и принять несколько принципов:

• Вся команда ответственна за качество, а не только QA;
• Качество важнее требований. Нужно доносить ценность до пользователя, а не слепо следовать техническому заданию;
• Баги нужно не находить, а предотвращать;
• Важно не найти как можно больше багов, а выпустить классный продукт, который будет выполнять задачи пользователей;
• Работа над проектом идёт не только в момент написания кода, но и в процессах, коммуникации и требованиях. И каждый этот аспект может улучшаться со временем.

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

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

Представьте то же производство колбасы. У нас есть рецепт, но не факт, что он верный, и прочесть его способен только один человек. Чтобы этого избежать, требования нужно проверять на качество. Смысл этого процесса в том, чтобы убедиться, что команда правильно поняла всю бизнес-логику и задала все важные вопросы. Иначе разработчики будут оценивать задачи “в вакууме”, не учитывая нюансов конкретного проекта.

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

Хорошее планирование решает сразу множество проблем. Важно сделать так, чтобы:

• Вся команда брала на себя ответственность за качество конечного продукта, включая заказчика;
• Скорость работы не определялась скоростью тестирования;
• Ориентироваться в процессе и настраивать его по ходу разработки продукта.

Что работает для нас на практике:

• Вырабатываем правила реагирования на баг. Каждый QA знает, что должно быть отражено в баге, и заводит их в систему баг-трекинга. Каждый баг описан таким образом, чтобы любой человек смог его воспроизвести. Важные и критические баги должны быть исправлены и проверены до релиза. Различные улучшения и минорные баги уходят в бэклог с последующим исправлением в рамках другого спринта.

• Задача уходит в статус «Ready to Test» только когда разработчик провел первичное тестирование своей задачи. Мы не просто пишем компилируемый код и передаем задачу QA. Разработчик сам пишет unit-тесты и проверяет работоспособность кода, а не перекидывает задачу на тестера (не оборачиваясь на эпичный взрыв). Это помогает избежать “пинг-понга” задачи между QA и DEV специалистами и оптимизировать время обоих.

В командах иногда вообще убирают колонку testing. Есть To Do, Work in Progress и Done. Вся работа идёт в колонке Work in Progress. Задача уходит в Done, только когда завершено тестирование. Некоторым командам это подходит: в таком процессе разработчики не переключаются между задачами, им не приходится вспоминать, что они писали две недели назад.

• Определяем цели и критерии готовности для релиза (DoD - Definition of Done). На их основе разрабатываем приёмочные тесты.

• Думаем о метриках качества продукта. Способность измерить результат даст возможность оптимизировать процесс и опираться не только на субъективное мнение на ретро.

• Не берём в спринт недовыясненные задачи.

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

• Тестируем задачи.

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

1. Держим в уме, что тестирование — это часть разработки. Уделяем этому внимание на всех дейли. Важно, чтобы все члены команды понимали, что тестируется, как, где и когда.
2. На проектах всегда есть определенная документация QA (в виде чек-листов, тест кейсов и других артефактов тестирования). Это помогает всем понимать тестовое покрытие, и не замыкает процесс на одном специалисте.
3. На ретро анализируем метрики качества и составляем план действий по его улучшению. Задаёмся тем самым вопросом: как поставить правильную запятую во фразе “пофиксить нельзя предотвратить”?
4. На демо собираем обратную связь и убеждаемся, что ведём разработку в соответствии с бизнес-ожиданиями и приоритетами заказчика.

То есть наш конвейер должен уверенно ехать в сторону майндсета, нацеленного на качество. Мы работаем как бы с двух сторон:

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

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

QA в данном случае — это главный технолог по качеству, который контролирует все процессы изготовления продукции.

Но это не одиночка, воюющий против всех. Это игрок, который поддерживает команду и структурирует процесс обеспечения качества.

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