Что пишут в блогах

Подписаться

Конференции

Heisenbug 2022 Spring
Большая техническая конференция по тестированию
Online — с 30 мая по 1 июня. Offline-день — 21 июня

TestDriven Conf

Профессиональная конференция по автоматизации в тестировании и рядом
27 и 28 июня, Москва, Radisson Slavyanskaya.

Что пишут в блогах (EN)

Разделы портала

Онлайн-тренинги

Почему разработчик не может быть тестировщиком (или может?)
25.01.2022 00:00

Автор: Долгополов Денис

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

Эта статья в основном для менеджеров компаний\руководителей стартапов, которым нужно решить — выделять ли отдельный бюджет на должность "тестировщик" или доплатить за часы разработчика?





Тестировщик — это

профессионал, который проверяет, адекватно ли приложение ведет себя в различных пользовательских сценариях на различных устройствах и версиях ОС

Дисклеймер

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

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

Весомые причины нанять отдельного специалиста

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

"Умеет разрабатывать" не равно "умеет тестировать"

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

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

Soft vs Hard

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

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

Найти ошибки в своей работе всегда сложнее, чем в чужой

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

Любит разрабатывать, а не тестировать

Большинство программистов гарит желанием именно "разрабатывать" - писать код, строить архитектуру, держать в голове сложные связи макаронного кода, ревьюить код...

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

Профдеформация

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

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

классéка

классéка

Деньги

Тут могу ошибаться, но обычно час тестировщика стоит дешевле часа разработчика (на сколько это правильно - вопрос на ветку в 300кк комментариев). Соответственно, вам просто не выгодно, чтобы разработчик тратил время на тесты.

Весомые причины не нанимать тестировщика

Я смог придумать только две:

  • никто не знает продукт лучше, чем тот, кто его разрабатывал. именно разработчику известны наиболее слабые или чувствительные точки;

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

Выводы

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

Потому что какой-то крутой не был код, главное, чтобы пользователю было не больно пользоваться конечным продуктом. А уследить за этим может только тестировщик. Имхо)

Еще #очевидные_вещи и про мобильную разработку в tg-канале - t.me/dolgo_polo_dev.

Обсудить в форуме