Бизнес: «Зачем нам тестирование? Разве нельзя написать всё хорошо и сразу?».

Разработчик: «Это не баг – это фича».

Тестировщик: «Ошибки в коде, а крайний кто? Все на тестировщика!».

Далее под термином «тестировщик» я буду подразумевать специалиста по качеству (QA), поскольку на практике разделение на QA, QC и, собственно, тестировщиков весьма условно.

Да и последний ГОСТ Р 56920-2024 дает обобщенное определение тестирования, охватывающее все три уровня, хотя и включает внушительный список ролей участников процесса.

Взгляд заказчика на тестирование ПО

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

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

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

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

Типичный вопрос заказчика: «Зачем тратить деньги на тестирование? Разве нельзя написать все хорошо и сразу?»

Такая позиция основана на мифе, что хороший программист не допускает ошибок, а наличие багов говорит о его непрофессионализме.

Что ж, с клиентами ясно. А что с разработчиками?

Мышление тестировщика и разработчика

В разработке и тестировании используются разные образы мышления.

Разработчик синтезирует код (синтез — это соединение). Он создает что‑то, собирая части воедино и придумывая различные способы объединения этих отдельных фрагментов.

У разработчика мышление творца.

Тестировщик же занимается анализом (анализ — это разделение на части). Как только все собрано, тестировщик снова все разбирает, выискивая несоответствия во взаимодействиях, возникающих в результате соединения частей.

У тестировщика мышление ученого.

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

В основе разработки лежит созидание, а в основе тестирования — наука.

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

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

Тестировщик и код: нужен ли глубокий дайвинг?

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

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

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

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

Так нужен ли «глубокий дайвинг»?

Ответ, как это часто бывает, лежит где‑то посередине. Тестировщик, который понимает код — это ценный специалист. Он может объяснить разработчикам на понятном им языке как происходит тестирование того или иного модуля программного продукта, чтобы те смогли написать более надежный и устойчивый код.

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

Поэтому ключевым становится умение находить баланс.

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

Баг! Подать сюда Тяпкина-Ляпкина!

Знакомая ситуация? Разработчик с гордостью показывает свой шедевр, а потом — бац! — где‑то что‑то не работает. И на кого все шишки? Конечно, на тестировщика: «Почему пропустил?».

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

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

Так почему же часто крайним оказывается тестировщик?

• Неверное понимание роли. Восприятие тестировщика как «дополнительной единицы», функцией которой является «проверка» работы разработчика.

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

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

• «Эффект последнего рубежа». Тестировщик, как правило, является последним звеном перед выпуском продукта. Ошибка, обнаруженная на этом этапе с психологической точки зрения кажется более критичной, а значит и виновник — последнее звено, т. е. тестировщик.

Как избежать подобных ситуаций?

• Четкие и полные требования. Детализированные и однозначные требования — залог успешной разработки и тестирования.

• Автоматизация тестирования. Максимальная автоматизация рутинных проверок позволяет ручным тестировщикам сосредоточиться на более сложных сценариях.

• Код ревью (Code review). Регулярная проверка кода разработчиками минимизирует риск человеческого фактора и «кривых рук».

• Параллельное тестирование. Внедрение тестирования на всех этапах разработки.

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

Итак, что же дает тестирование?

1. экономию денег

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

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

2. безопасность

   Продукты, обеспечивающие защиту данных пользователей более востребованы.

3. качество продукта

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

4. оптимизация процесса разработки

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

5. ускорение выхода на рынок нового функционала

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

Почему же так важно прислушиваться к тестировщикам?

Ответ прост: уверенность в качестве продукта появляется только после его тестирования.

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

В заключение небольшое напутствие.

Для разработчиков:

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

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

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

Для бизнеса:

• Снижение рисков. Прислушиваясь к тестировщикам, вы минимизируете репутационные и финансовые риски.

• Удовлетворенность клиентов. Стабильная работа продукта и отсутствие ошибок делает ваш продукт более «вкусным» для пользователей.

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