tech_test

tech_test

Соображения по поводу тестирования.

Небольшое эссе, в котором изложены основные мысли неоторым вопросам тестирования.

Содержание

• tech_test
  • Содержание
  • Анализ ситуации
  • Состояние средств контроля в типовом проекте
  • Юнит-тестирование и пакетное тестирование
  • Интеграционное тестирование
  • Пользовательское тестирование
  • Сбор информации в ходе эксплуатации

Анализ ситуации

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

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

Инструменты контроля деляется на:

• локальный контроль (измерение в ходе изготовления отдельной детали);
• сборочный контроль (измерения при сборке крупных узлов и агрегатов);
• контроль качества на выходе (проводится после сборки всего изделия из компоновочных узлов и агрегатов);

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

В изготовлении цифрового продукта для этих целей служат различные инструменты по масштабу применения и целям:

• юнит-тестирование;
• пакетное тестирование;
• интеграционное тестирование;
• пользовательское тестирование;
• сбор информации в ходе опытной, опытно-промышленной и промышленной эксплуатации;

То, что Фредерик Брукс описал как "вспомогательные строительные леса".

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

Это приводит к тому, что стоимость средств контроля производства не просто кратно превышает по стоимости аналогичные средства в материальном производстве -- стоимость средств контроля в информационном производстве превышает стоимость средств материального производства на несколько порядков. Это нормально.

Состояние средств контроля в типовом проекте

Для подробного рассмотрения ситуации и её оценки следует рассмотреть ситуацию от частного к общему.

Юнит-тестирование и пакетное тестирование

Разработка юнит-тестов и юнит-тестирование должна проводиться инженером-разработчиком на этапе разработке юнитов (отдельных модулей). Степень покрытия тестами для подтверждения качества кода должна находиться в пределах 85-95%. В оответствии с результатми многих исследований покрытие тестами на уровне 50% ничего не доказывает -- как правило это прямая ветка исполнения, а интересуют именно граничные условия.

В проекте среднее покрытие тестами разнится крайне сильно -- от 0 до 95%. Отдельные сервисы покрыты тестами на 0%, отдельные даже более 95%, остальные в диапазоне приведённых значений. Отсутствие устойчивых показателей порождает ряд проблем на следующем уровне.

Довольно часто покрытие тестами на уровне 100% для отдельных микросервисов является крайне затратным, и достижение такого показателя оправдано только для критических применений. В соответствии с известным эмпирическим правилом: достижение 80% результата обеспечивается 20% усилий.

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

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

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

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

Пользовательское тестирование

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

• откровенные ошибки, заложенные на уровне ТЗ;
• откровенные ошибки, пропущенные в ходе тестирования;
• пожелания, связанные с интерфейсом пользователя;
• пожелания, связанные с работой инетерфейса пользователя.

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

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

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

Сбор информации в ходе эксплуатации

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

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

Отсутствие этих этапов приведт к тому, что потребителю проголосуют рублём в сторону аналогичных продуктов от других производителей.

Отсутствие эксплуатационной службы является признаком наплевательского отношения к потребителям.