Сам свой код и тестируй: кто [на самом деле] должен искать баги

Не так давно с коллегами обсуждали самостоятельное тестирование свеженаписанного кода. Один тимлид из нашей команды рассказал про разработчика, который отдавал код на тест, не проверяя за собой. Аргумент у него был «железный»: проверка не его забота, для этого есть тестировщики. 

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

Во-первых, это стоит денег и времени

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

Итак, проверять свой код и находить баги самостоятельно — элементарно быстрее и дешевле. Это не рокет сайенс и не моё предположение, а факт, который известен с 1980-х, когда была сформулирована классическая кривая Боэма, собранная на данных IBM и других крупных ИТ-компаний. Стоимость исправления дефекта может вырасти в десятки и сотни раз по мере движения по шкале готовности задачи, и чем раньше найден баг, тем дешевле его исправить. 

Это утверждение не раз было доказано и позднее. Например, в исследовании Accelerate 2018 года, в нём приняли участие более 23 тысячи респондентов и тысячи компаний. Результат однозначный: команды, где разработчики сами тестируют свой код и используют автотесты, работают быстрее и допускают меньше багов.

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

Мне кажется, достаточно очевидно, что тестирование собственного кода – просто базовое правило. И результаты исследования, и кривая Боэма прямо опровергают идею, что разработчик «не должен ничего тестировать», наоборот, вовлечение разработчиков в тестирование – один из факторов максимально эффективного результата. 

Но если этих доводов мало, у меня есть еще один:

QA — это вам не тестировщики

Многие люди, кто даже давно работают в ИТ, действительно иногда считают, что тестировщики — это такие странные программисты, которые не пишут код сами, а только тестируют чужой. Но это большая ошибка. 

QA-инженера (англ. Quality Assurance – «контроль качества») называют тестировщиком, потому что поиск ошибок и проверка продукта являются основной и часто самой заметной частью его работы. Хотя бы просто потому что именно по найденным багам у него чаще всего идет коммуникация с разработчиками. Но QA — это широкий процесс предотвращения багов на всех этапах, а идея, что тестировщик только «ищет косяки за разработчиком», выглядит откровенно снобской и очень устаревшей. 

Примерный перечень задач современного QA включает и построение стратегии тестирования, и разработку и поддержание автотестов и тестовой инфраструктуры, и участие в проектировании системы, анализ рисков и поиск потенциальных проблем до этапа разработки, контроль качества на всех этапах жизненного цикла продукта, работа с метриками качества и стабильности, исследование пользовательских сценариев поведения, а также взаимодействие с разработчиками, аналитиками и продуктовой командой. К слову, подробно и интересно про роль QA рассказывает в своем блоге sound_right, например. Рекомендую к прочтению о роли тестировщика статью «QA умерло? Как изменяется роль тестировщиков в 2025». 

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

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

Ещё один нестандартный пул задач у нашего QA – ведение продуктовой документации. Как связано тестирование и техническое описание продукта — вопрос хороший. Дело в том, что мы, как и многие, работаем с тест-кейсами: описываем сценарии, по которым должна вести себя система и возвращаемся к ним при доработках. Недавно с лидом QA мы обсуждали, что часто тест-кейсы пишутся в стол, и пришли к неожиданному выводу, что по сути накопленные у нас тест-кейсы в итоге описывают в целом, как работает платформа. Так у нас родилась идея собрать структурированную полную продуктовую документацию и протестировать, насколько она будет удобна и эффективна в работе вместо тест-кейсов. Пока это только гипотеза, но мы настроены оптимистично. Эпохальный труд по формированию всей документации при этом взяла на себя руководитель QA-отдела. Сейчас у нас уже есть документ с четкой структурой и описанием всего функционала платформы, и он постоянно дорабатывается силами QA. Круто для “тестировщиков”, да? Но мы-то давно знаем, что QA — это гораздо больше, чем поиск багов в чужом коде. 

Так и кого тут заменит ИИ

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

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

Максим Быстров

CTO SaaS-платформы TYMY