Разбираемся, какие виды тестирования нужно проводить при внедрении заказных бизнес-приложений. Что такое воронка «бесконечного тестирования». Чем синдром «сапера» отличается от синдрома «лудомана». А также можно ли полюбить тестирование.

См. часть 1 – «лишний этап».

См. часть 2 – программирование «в уме».

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

Допущение первое – набор тестов описан с точки зрения внедрения заказных бизнес-приложений по технологии «водопада» (см. главу «про смысловой инкремент»). При использовании адаптивных технологий внедрения, набор и порядок выполнения тестов могут отличаться.

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

Сценарии тестирования

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

Может показаться, что написание сценариев тестирования перед доработкой системы делает такой подход похожим на методологию TDD (Test Driven Development), т.к. тест, пусть и только в виде сценария, появляется раньше, чем выполняется доработка. Но по своей сути это не так. Мы готовим сценарий тестирования, но не выполняем само тестирование. Таким образом, мы пропускаем «красный» этап в цикле «красный – зеленый – рефакторинг» TDD.

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

Модульное тестирование

Первым по хронологии идет модульное тестирование. Еще его называют юнит-тестированием. Цель этого тестирования – проверить доработку, сделанную программистом. Следовательно, оно выполняется в рамках этапа доработки системы. Модульное тестирование выполняет консультант, зафиксировавший в рамках этапа анализа требование, послужившее основанием для доработки.

Выполнять модульное тестирование нужно максимально оперативно, чтобы задача не успела выветриться из «оперативной памяти» программиста. Для поддержания ритмичности модульного тестирования обычно поддерживается пропорция «2 программиста на 1 консультанта». Но в зависимости от уровня исполнителей, а также от объема параллельной загрузки консультанта, пропорция может меняться в сторону «1 программист на 1 консультанта».

Модульное тестирование каждой доработки выполняется изолированно от других доработок. Это допущение нужно просто принять. Связанность разных доработок мы успеем проверить позднее.

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

Далее ответим на вопрос – «а как выполнять модульное тестирование?». Тут есть два подхода. Первый – пройти сценарий тестирования, описанный в дизайне расширения. Второй – открыть разделы «Логика решения» и «Дизайн метаданных» дизайна расширения, и скрупулезно, строчка за строчкой, проверить все, что там написано. Вот прямо дословно. Написано, что выборка из базы данных должна быть сделана с отбором по периоду. Следовательно, нужно вбить как минимум 4 набора тестовых данных: 1) в секунду, предшествующую требуемому периоду, 2) в первую секунду требуемого периода, 3) в последнюю секунду требуемого периода и 4) в секунду, следующую за требуемым периодом. И проверить, что только 2 набора из 4 попадают в выборку. Написано, что у поля тип – неотрицательное число. Следовательно, нужно попробовать вбить отрицательное. И т.д.

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

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

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

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

Управление конфликтами

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

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

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

• Синдром «сапера» у консультанта. Это когда консультант, подобно саперу, работающему до первого взрыва, тестирует до первого более-менее критического замечания, после чего, как горячую картошку, перекидывает задачу на программиста. Объективно бывают ситуации, когда так и нужно поступать. Но если есть возможность обойти ошибку и дотестировать доработку до конца, то именно так и нужно поступать, сокращая потенциальное количество итераций тестирования. Данная ситуация скорее всего говорит о том, что консультанту дискомфортно находится в процессе тестирования (см. главу «этика»).

• Синдром «лудомана» у программиста. Это когда программист, вместо того чтобы разобраться в сути доработки, начинает гадать и подобно игроку, зависшему у однорукого бандита, пытается попасть в верное решение. Закодировал первый вариант доработки – не то. Закодировал второй вариант доработки – опять не то. И так раз за разом. Программист делает очередной вариант доработки, зажмуривается и откидывает доработку на тестирование, в надежде, что на этот раз точно фартанет и доработка будет принята консультантом. Это наглядный пример отсутствия осознанности.

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

Функциональное тестирование

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

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

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

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

Нагрузочное тестирование

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

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

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

Интеграционное тестирование

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

Интеграционное тестирование проводится для каждой смежной системы.

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

Опытная эксплуатация

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

Автоматизация тестирования

Тестирование – это, бесспорно, рутина. А любую рутину имеет смысл автоматизировать. Если говорить про вселенную 1С, то здесь из множества QA-инструментов хочется выделить следующие:

• Сестры Вачовски Ванессы – Automation и ADD. Эти фреймворки позволяют быстро, в автоматизированном режиме, сгенерировать и выполнить дымовые тесты. Также этот инструментарий позволяет быстро, в пользовательском режиме, сгенерировать и выполнить функциональные тесты. При этом на основе созданных функциональных тестов, можно собрать пакет тестов для проведения нагрузочного тестирования

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

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

Этика

В заключение хочется вернуться к названию этой статьи и поговорить об этическом аспекте проведения тестирования.

В рамках модульного тестирования нет особых требований к качеству тестовых данных. Другое дело тестирования, выполняемые в рамках приемо-сдаточных испытаний. Особенно это касается функционального тестирования. В отличие от процесса модульного тестирования, в процессе приемо-сдаточных испытаний принимают участие бизнес-пользователи. Поэтому особое внимание следует уделить качеству тестовых данных. Тестовые данные должны быть релевантны бизнесу. Не нужно показывать специалистам, которые занимаются диспетчеризацией производства авиационных двигателей, пример производства мебели (хотя вы лично, когда в свое время проходили курсы обучения, разбирали примеры производства мебели и древесная стружка в качестве возвратных отходов для вас как родная). Не нужно показывать закупщикам, у которых 99% поступления материальных ценностей проходит через торговый дом, пример закупки у «ромашки» или «лютика». И здесь речь не столько про хороший тон, сколько про эффективность прохождения тестирования. Если во время проведения тестирования, бизнес-пользователь будет чувствовать максимальную связь с тем, что происходит на экране компьютера, то и замечания будут максимально сутевые.

В последний раз вернемся к допущению номер два, описанному в преамбуле статьи. Сделаем небольшое отступление и посмотрим на эти два болта.

Физически это два абсолютно одинаковых болта. Они выточены на одном станке, из одинаковой стали, по одному чертежу. Но почему один стоит 1 руб., а другой 10 руб.? Дело в том, что первый болт лежит на полке в DIY-магазине, а второй будет использован при строительстве АЭС. Понятно, что производство второго болта сопряжено с множеством дополнительных затрат на контроль, сертификации, проверки и т.д.

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

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

Теперь раздадим всем сестрам по серьгам и поговорим об ответственности за тестирование внутри проектной команды:

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

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

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

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

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

• Причина первая – «скучно». Тут сложно поспорить. Набивать тестовые данные и анализировать полученные результаты не самая творческая задача.

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

• Причина третья – «сложно». Требование от бизнес-заказчика формально зафиксировал, а зачем это нужно бизнес-заказчику, так до конца и не разобрался. Поэтому и не очень понятно, как тестировать.

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

• Во-первых, повышается дисциплинированность. Ничто так не тренирует дисциплинированность, как выполнение скучных и рутинных задач.

• Во-вторых, повышается осознанность. Понимание реальной картины на проекте (сколько и каких замечаний возникло, сколько есть времени на их исправление) повышает контроль за процессом запуска системы. А контроль – это антагонист страха. Мы не боимся того, что контролируем.

• В-третьих, повышается компетенции в автоматизируемой сфере. Чтобы корректно оценить результаты тестирования, нужно поставить себя на место бизнес-пользователя. Делая это упражнение на регулярной основе, мы поднимаем свой уровень «бизнесовых» компетенций.

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