Качество вместо контроля качества
Говоря о качестве, обычно имеют ввиду некое соответствие требованиям. Часто под требованиями подразумевают те, что явно выдвинул заказчик, аналитик или кто-то другой, кто ставит задачи. Хуже, если они трактуются как неоспариваемые, и это неявно ведёт к самоцели — удовлетворить требования заказчика. Это часто происходит в аутсорсе, и такой фокус внимания негативно влияет на конечный результат — то, что видят и с чем работают пользователи.
Мы в SmartHead тоже занимаемся заказной разработкой, и я предлагаю рассматривать качество шире. Это не только про соответствие явно озвученным требованиям, но и про сами требования. Про дополнение явных требований своими, ориентированными не на потребности заказчика, а на удобство конечного пользователя. Пользовательский опыт, юзабилити, тексты в интерфейсе, отзывчивость, скорость релизов, их соответствие ожиданиям — всё это тоже относится к качеству.
Качество — это про «сделать классно» с точки зрения многих сторон: разработки, заказчика и конечного пользователя.
Как это сделать? Сложно. Начать стоит с формирования mindset на «встроенное» качество. Расскажу о принципах, которые могут помочь в этом.
Качество — это про разработку, а не про тестирование
Почему качество жестко связывают с тестированием? Непонятно.
Качество определяется тем, как сделан продукт, а не тем, как он протестирован.
За качество того, что сделано, отвечает вся команда, и в большей степени разработчик. Он должен быть уверен в том, что разработанная фича работает. Странно говорить «сделано», пока этой уверенности нет. Её можно добиться разными способами — технологическими и процессными, в том числе тестированием. Однако важно, чтобы на него не перекладывалась вся ответственность. Отдельный этап ручного тестирования после реализации не должен быть узким горлышком, и, в идеале, даже не должен быть необходимостью.
Итак, проектирование качества должно быть включено в реализацию. Качество включено в понятие «сделать».
Устойчивость к изменениям
В продуктах, которые живут долго, наряду с качеством сейчас (например, в момент после разработки фичи) важно качество системы, её устойчивость к изменениям. А изменения неизбежны.
Чтобы система жила и развивалась, нужны частые изменения. Их нужно воспринимать как что-то нормальное, рутинное, а не исключительное. Для этого необходимо быть уверенным, что изменения ничего не сломают.
С устойчивостью и качеством системы что-то не так, если бывает соблазн «не трогать, пока работает» или если разработчики не хотят выкидывать уже написанный код.
Кодовая база — это не то, что мы построили и сдали. Это среда, в которой мы живём, и нужно сделать её удобной для постоянной работы. Изменять, добавлять, удалять код должно быть комфортно.
Отсутствие детальных требований — не проблема
Если у нас нет детальных требований, это не значит, что нужно бежать к заказчику и спрашивать, в каком месте интерфейса должна быть кнопка. И это также не значит, что она может быть в любом месте.
Кроме заданных извне требований (или их полного отсутствия) есть common sense, общепринятые паттерны, наш опыт и чувство прекрасного. Их мы стараемся поддерживать на современном уровне и развивать. И следовать им при принятии решений (в том числе о расположении упомянутой кнопки).
Детальные требования — это набор решений, вынужденно принятых вначале — тогда, когда информации для этого ещё слишком мало (об этом неплохо написано в Getting Real от Basecamp).
Отсутствие детальных требований — не проблема, а возможность сделать максимально хорошо, гибко управлять уровнем проработки проблемы с учетом доступного времени и бюджета (подход FFF). Фокусироваться на важном, отбрасывая незначительное.
Конечно, нужно понимать, что мы делаем и зачем. Но детально описывать — не обязательно.
Баги неизбежны, но не в любом количестве
Я часто вижу, как тезисом о неизбежности багов прикрывают низкое качество разработки. То, что нельзя сделать софт без единого бага, не означает, что допустимо любое количество багов.
Баги — это нормально, если они не препятствуют движению к цели: достаточно быстро чинятся, налажен процесс, есть «иммунитет»; критические баги, ломающие основные сценарии использования, возникают крайне редко.
Если каждая задача возвращается после тестирования или при починке одного бага всплывает три новых, то с качеством что-то не так.
Не всё есть баг
К восприятию багов можно подойти и с другой стороны. Их количество зависит не только от того, как написан код, но и от того, что мы считаем багом. В ПО любого качества можно найти формальный баг. Но не всегда нужно записывать всё. Иногда это просто генерация лишней работы.
Я не предлагаю игнорировать баги. Но важно понимать, что на самом деле важно. Бывает, что тестировщики закапываются в деталях, тратят на них слишком много времени, и его не остается на проверку сути и следование общей цели. Можно потратить много времени на сверку вёрстки с макетом и не оставить ничего на проверку основного пользовательского сценария. Можно возвращать каждую задачу из-за незначительных мелочей и потерять общую картину качества, т. к. все задачи будут переоткрыты, и неясно, что сделано.
Не нужно также тестировать компетентность исполнителя. Если вы тестируете задачи определенного разработчика больше только потому, что не доверяете его компетентности, то ваша проблема не в багах, а в недоверии или несоответствии уровня исполнителя сложности задачи. Людям нужно доверять. А тестировать — ПО.
Я также не вижу смысла в тестировании дизайн-макетов и написанных требований. Сами по себе, пока не реализованы, они не приносят ценности пользователям. Ревьюить, смотреть, обсуждать, совместно проектировать макеты и требования — можно и нужно. Но не стоит их формально тестировать.
В мире с бесконечными ресурсами всё протестировать было бы классно. Но здесь есть более важные вещи.
Что тогда тестировать?
Тестировщик — это нулевой пользователь системы, который хорошо знает продукт и снаружи, и изнутри. Его работу следует ориентировать на обеспечение корректного опыта пользователя, а не проверку задач разработчика. Нужно тестировать, что сделано, а не что делалось. Фичи, а не задачи.
Задача тестировщика — не найти больше багов, а сделать так, чтобы их было меньше. В такой парадигме, наоборот: чем меньше багов найдено, тем лучше.
Тестировщик отвечает в том числе за юзабилити и доступность. Тексты, анимации, доступность интерфейса для людей с ограниченными возможностями — это тоже качество.
Кроме того, он может использовать свой образ мышления для повышения качества разработки. Например, помогает разработчикам писать тесты, закрывать граничные кейсы, обеспечивать достаточный и целесообразные уровень покрытия.
Тестирование эффективно, когда оно приносит дополнительную ценность, а не компенсирует недостатки разработки.
Итого
Выполнение заранее составленных требований — не самоцель. Важнее сделать «классный» продукт в результате.
Пользовательский опыт важен.
Уровень качества задаётся при разработке. Тратя усилия на компенсацию разработки тестированием, мы лишаем себя возможности направить эти усилия на развитие разработки и, как следствие, качества.
Тестирование — бонус, улучшающий систему, а не критическая необходимость.
В следующей статье поговорим о том, какие технологические подходы могут помочь разрабатывать качественно.
