Бизнес: «Зачем нам тестирование? Разве нельзя написать всё хорошо и сразу?».
Разработчик: «Это не баг – это фича».
Тестировщик: «Ошибки в коде, а крайний кто? Все на тестировщика!».
Далее под термином «тестировщик» я буду подразумевать специалиста по качеству (QA), поскольку на практике разделение на QA, QC и, собственно, тестировщиков весьма условно.
Да и последний ГОСТ Р 56920-2024 дает обобщенное определение тестирования, охватывающее все три уровня, хотя и включает внушительный список ролей участников процесса.

Взгляд заказчика на тестирование ПО
Взрывной рост рынка программного обеспечения (ПО) несет в себе значительные риски, требующие пристального внимания к качеству и безопасности разрабатываемых продуктов.
Одним из ключевых инструментов для минимизации таких рисков является тестирование ПО, позволяющее предотвратить финансовые потери, репутационные издержки и снижение лояльности клиентов.
К сожалению, во многих ИТ‑компаниях до сих пор распространено мнение о необязательности тестирования, а его функции часто возлагаются на разработчиков.
Основная причина такого подхода — непонимание бизнесом реальной ценности тестирования, поскольку его результаты не всегда очевидны на первый взгляд.
Типичный вопрос заказчика: «Зачем тратить деньги на тестирование? Разве нельзя написать все хорошо и сразу?»
Такая позиция основана на мифе, что хороший программист не допускает ошибок, а наличие багов говорит о его непрофессионализме.
Что ж, с клиентами ясно. А что с разработчиками?
Мышление тестировщика и разработчика

В разработке и тестировании используются разные образы мышления.
Разработчик синтезирует код (синтез — это соединение). Он создает что‑то, собирая части воедино и придумывая различные способы объединения этих отдельных фрагментов.
У разработчика мышление творца.
Тестировщик же занимается анализом (анализ — это разделение на части). Как только все собрано, тестировщик снова все разбирает, выискивая несоответствия во взаимодействиях, возникающих в результате соединения частей.
У тестировщика мышление ученого.
И разработчикам, и тестировщикам нравится разбираться во внутренней структуре системы, но их цели различны. Разработчик отвечает за создание и функционирование продукта, а тестировщик — за его всестороннюю проверку и выявление потенциальных проблем.
В основе разработки лежит созидание, а в основе тестирования — наука.
Разработка — это творческий процесс. Разработчик, как художник, гордится своим творением и склонен видеть в нем совершенство.
Тестировщик же, напротив, ищет слабые места, чтобы предотвратить катастрофу, когда ошибку обнаружит конечный пользователь, что может серьезно подорвать его доверие к продукту.
Тестировщик и код: нужен ли глубокий дайвинг?
Бытует ошибочное мнение, что тестировщик — это «недоразработчик», а значит, некомпетентен и его голос не важен. Так думают «обиженные» специалисты, чью работу подвергли критике, т. е., по их мнению, покусились на святая святых.
Чтобы тестирование было максимально эффективным, тестировщик погружается в продукт, изучая его со всех сторон, т. е. фактически затрагивает зоны и разработки, и дизайна, и аналитики, и бизнеса.
Хороший тестировщик, кроме непосредственно тестирования, имеет навыки тест‑дизайна, программирования, работы с базами данных и консолью, имеет представление о клиент‑серверной архитектуре и еще куче полезных вещей.
Он смотрит на продукт сверху, как командующий войсками на карту, видит узкие места и потенциальные риски и в силу своего стратегического положения дает рекомендации по улучшению тех или иных характеристик на разных этапах создания и использования продукта.
Так нужен ли «глубокий дайвинг»?
Ответ, как это часто бывает, лежит где‑то посередине. Тестировщик, который понимает код — это ценный специалист. Он может объяснить разработчикам на понятном им языке как происходит тестирование того или иного модуля программного продукта, чтобы те смогли написать более надежный и устойчивый код.
Однако, важно не терять из виду основную цель — обеспечение качества продукта с точки зрения пользователя.
Поэтому ключевым становится умение находить баланс.
Таким образом, тестировщику нет необходимости глубоко погружаться в код — это даже вредно, т.к. сужает область видимости, а значит, ограничивает в комплексном анализе, что в свою очередь снижает эффективность тестирования.
Баг! Подать сюда Тяпкина-Ляпкина!

Знакомая ситуация? Разработчик с гордостью показывает свой шедевр, а потом — бац! — где‑то что‑то не работает. И на кого все шишки? Конечно, на тестировщика: «Почему пропустил?».
Но так ли все однозначно?
Тестировщик работает с тем, что ему предоставили, анализируя, прогнозируя и проверяя. Он не видит ошибок до их появления, хоть и может предугадать некоторые.
Так почему же часто крайним оказывается тестировщик?
-
Неверное понимание роли. Восприятие тестировщика как «дополнительной единицы», функцией которой является «проверка» работы разработчика.
-
Культура «сдать и забыть». При таком подходе тестировщик оказывается под давлением, заставляющем его «пропустить» некоторые недочеты, дабы не тормозить выпуск продукта.
-
Плохая коммуникация. Обнаружение ошибок лишь на финальной стадии вместо выявления их на ранних этапах в результате неконтактности разработчика, неготовности прислушаться к рекомендациям тестировщика.
-
«Эффект последнего рубежа». Тестировщик, как правило, является последним звеном перед выпуском продукта. Ошибка, обнаруженная на этом этапе с психологической точки зрения кажется более критичной, а значит и виновник — последнее звено, т. е. тестировщик.
Как избежать подобных ситуаций?
-
Четкие и полные требования. Детализированные и однозначные требования — залог успешной разработки и тестирования.
-
Автоматизация тестирования. Максимальная автоматизация рутинных проверок позволяет ручным тестировщикам сосредоточиться на более сложных сценариях.
-
Код ревью (Code review). Регулярная проверка кода разработчиками минимизирует риск человеческого фактора и «кривых рук».
-
Параллельное тестирование. Внедрение тестирования на всех этапах разработки.
-
Обучение и развитие. Повышение квалификации и тестировщиков, и разработчиков с целью внедрения новых технологий и полезных практик способствует оптимизации процессов и улучшению качества продукта.
Итак, что же дает тестирование?
-
экономию денег
Тестирование позволяет значительно сэкономить средства, выявляя и устраняя ошибки на ранних этапах разработки. Чем раньше обнаружена ошибка, тем дешевле обходится её исправление.
Как показывают исследования, стоимость исправления дефекта экспоненциально растет по мере продвижения проекта от разработки к тестированию и, наконец, к эксплуатации.
-
безопасность
Продукты, обеспечивающие защиту данных пользователей более востребованы.
-
качество продукта
Потребитель будет не в восторге от продукта, дающего сбои, особенно частые сбои, и уйдет к другому производителю.
-
оптимизация процесса разработки
Внедрение тестирования на всех этапах разработки позволяет значительно снизить количество ошибок, обнаруживаемых на этапе финального тестирования.
-
ускорение выхода на рынок нового функционала
Тестирование ускоряет процесс создания продукта и его запуск, позволяет быстро адаптироваться к меняющимся запросам пользователей, что обеспечивает компании преимущество перед конкурентами.
Почему же так важно прислушиваться к тестировщикам?
Ответ прост: уверенность в качестве продукта появляется только после его тестирования.
Разработчики создают продукт, выстраивая его кирпичик за кирпичиком. Бизнес видит в нем потенциал для роста и прибыли. Но именно тестировщики с их въедливым вниманием ко всему построенному «зданию» в целом и каждому его элементу дают уверенность, что продукт работает «как часы».
В заключение небольшое напутствие.
Для разработчиков:
-
Объективная обратная связь. Тестировщики — это ваш спасательный круг. Они смотрят на продукт с точки зрения пользователя и видят ошибки, которые вы, будучи погруженными в код, упускаете. Их рекомендации не критика вашей работы, а конструктивные предложения для оптимизации.
-
Повышение качества кода. Понимание того, как ваш код будет тестироваться, позволит использовать более продуманные решения и повысит устойчивость кода. Что в свою очередь, способствует предотвращению потенциальных проблем.
-
Экономия времени и ресурсов. Исправление ошибок, выявленных тестировщиками, на ранних этапах разработки обходится дешевле, нежели после релиза. Как показывают исследования, стоимость исправления дефекта экспоненциально растет по мере продвижения проекта от разработки к тестированию и, наконец, к эксплуатации.
Для бизнеса:
-
Снижение рисков. Прислушиваясь к тестировщикам, вы минимизируете репутационные и финансовые риски.
-
Удовлетворенность клиентов. Стабильная работа продукта и отсутствие ошибок делает ваш продукт более «вкусным» для пользователей.
Тестировщики — это не просто «ловцы багов». Это специалисты, которые понимают продукт с точки зрения его применимости. Доволен пользователь — доволен заказчик, что в свою очередь положительно отражается на всех участниках процесса создания продукта.
ссылка на оригинал статьи https://habr.com/ru/articles/936418/
Добавить комментарий