Заблуждения и факты о тестировании в IT

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

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

Давайте разберем несколько популярных ошибочных мнений в отношении Обеспечения качества (QA). Мы уверены, что эта тема не только интересна, но также может быть полезна при аргументации добавления автоматизированного тестирования в проект.

Тестирование — это дорого и долго

Заблуждение: Тестирование требует больших затрат времени и ресурсов, которые можно было бы сэкономить.

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

Факт 2: Внеплановые работы по экстренному исправлению дефектов в production-среде приводят к остановке разработки новых функций, что напрямую увеличивает общее время выхода последующих обновлений.

Факт 3: Согласно исследованиям Systems Sciences Institute at IBM (2010), стоимость исправления ошибки, обнаруженной после развертывания ПО, в 15 раз выше, чем если бы она была обнаружена на этапе проектирования, и в 100 раз выше, если её выявили уже на стадии эксплуатации и сопровождения.

Тестирование — это исключительно статья расходов

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

Факт 1: Полная стоимость владения продуктом (TCO, Total Cost of Ownership) включает в себя затраты на его поддержку. Продукт с низким уровнем качества требует больших затрат на обслуживание, техническую поддержку и исправление сбоев, что значительно увеличивает его TCO, делая продукт менее привлекательным для инвесторов и акционеров.

Факт 2: Исследование, проведенное Национальным институтом стандартов и технологий США (NIST) в 2002 году, оценивает, что недостаточное тестирование обходится экономике США в $59.5 миллиардов ежегодно. Эти затраты связаны с потерями производительности, усилиями на поддержку и исправление.

Тестирование ПО выявляет только баги

Заблуждение: Многие считают, что задача тестировщика - находить ошибки.

Факт 1: Согласно международному стандарту ISO/IEC/IEEE 29119 «Цель тестирования — оценить качество ПО и выявить несоответствия с заданными требованиями». Таким образом, тестирование направлено не только на поиск ошибок, но и на подтверждение соответствия программного продукта его требованиям и спецификациям, а также обеспечение качества.

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

Тестируют только завершенные продукты

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

Факт 1: Историческая практика тестирования действительно основывалась на финальной проверке продукта — так называемом «последнем этапе» перед выпуском. Так же происходит и в традиционных водопадных моделях разработки, где тестировщики для проверки получают уже полностью готовый продукт. Обнаруженные дефекты исправляются на поздних этапах, что удорожает стоимость ошибки.

Факт 2: Согласно современным принципам Agile и DevOps, тестирование проводится непрерывно на всех этапах жизненного цикла разработки, по методу так называемой пирамиды тестирования. Что позволяет выявлять и исправлять дефекты еще до завершения полного продукта.

Факт 3: Средства автоматизированного модульного тестирования (JUnit, TestNG, pytest, Selenium); инструменты для интеграционного тестирования (Jenkins, Travis CI, GitLab CI/CD); статические анализаторы кода (SonarLint, Pylint, ESLint) позволяют проводить глубокое тестирование еще не готового продукта.

Достаточно тестирования силами разработчиков

Заблуждение: Нет необходимости нанимать тестировщиков, свой код могут протестировать и сами разработчики.

Факт 1: Разработчик, написавший код, подвержен когнитивному искажению — «эффекту слепоты к собственной ошибке». Он тестирует код на соответствие его собственному пониманию требований, а не на соответствие реальным, потенциально ошибочным, сценариям использования.

Факт 2: Различия в подходах. Задача разработчика — проверить, что код работает так, как он задуман. Задача тестировщика — проверить, что код не работает так, как не задуман, и найти ситуации, в которых он может сломаться.

Нет критических сбоев, значит тестирование избыточно

Заблуждение: Отсутствие критических инцидентов после релиза означает, что тестирование было слишком подробным или даже лишним.

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

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

Излишний перфекционизм

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

Рекомендуемый уровень покрытия тестами кода, считающийся хорошей практикой, обычно составляет от 70% до 80%. Такой диапазон обеспечивает баланс между качеством тестирования и затратами времени и ресурсов. Для этого многие современные среды разработки (IntelliJ IDEA, PyCharm, Xcode, VS Code) уже «из коробки» или с использованием плагинов позволяют оценить степень покрытия кода тест-кейсами.

Также хочется упомянуть про Закон убывающей отдачи: достижение 100% автоматизации требует экспоненциального роста усилий и ресурсов. А также, что эффективность автоматизации тестирования особенно низка для систем, часто подверженных изменениям.

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

Выводы

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

Андрей Богер, старший специалист отдела разработки