Настоящий CTO: думай как технический директор - Алан Уильямсон

9.4. Обеспечение качества (QA)

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

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

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

• ручное;

• автоматизированное.

9.4.1. Ручное тестирование

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

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

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

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

Заметки с полей

Тестирование тестировщиков

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

9.4.2. Автоматизированное тестирование

Мечта любого технического директора, инженера или владельца продукта – добиться полного покрытия кода автоматизированными тестами. Автотесты работают без участия человека, и их можно выполнять как часть процесса сборки и деплоя приложения. Они могут включать в себя модульные тесты (unit tests), тестирование API, тестирование функционала для конечных пользователей – все, что последовательно проверяет кодовую базу без участия человека.

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

Заметки с полей

Не ведитесь на количество

Глен Мартин (Glen Martin), который в свое время был менеджером по продукту спецификации Java Enterprise, преподал мне ценный урок о важности качества, а не количества тестов. Он проиллюстрировал это утверждение, спросив меня, какой автомобиль я выберу: тот, который прошел 10 000 тестов, или тот, который прошел только один тест? Естественно, как молодой наивный инженер, я выбрал первый вариант. И попал в классическую ловушку, предположив, что количество равняется качеству. Глен ответил, что автомобиль, прошедший 10 000 тестов, не прошел тест запуска двигателя, а единственным тестом, который прошел другой автомобиль, был именно этот тест. Простой и очевидный пример, который я помню спустя почти 25 лет.

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

Поэтому при оценке покрытия кода необходимо определить наиболее важные компоненты. Для них необходимо обеспечить максимальное тестирование. 100 % покрытия кода достичь почти невозможно; хорошим результатом можно считать 50–70 %.

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

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

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

9.5. Непрерывная интеграция и внедрение (CI/CD)

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

Заметки с полей

Только Фред может обновить эту службу

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

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

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