Если ты что-нибудь делаешь, делай это хорошо. Если же ты не можешь или не хочешь делать хорошо, лучше совсем не делай.

Лев Николаевич Толстой

Есть одна вещь, в которой на 100% сходятся все книжки из разряда «как быть крутым программистом» — это «вы несёте ответственность за свой код». Не буду оригинален и на вопрос «зачем нужно тестировать?» скажу: «потому что вы несёте ответственность». Хочешь быть профессионалом — будь добр, убедись, что свою работу ты выполняешь качественно.

Дисклеймер: можно много спорить, о том, что есть «качественно». Здесь я возьму простое определение: качественный — значит с минимумом дефектов и соответствующий требованиям.

Зачем тесты разработчику?

«Допустим, — скажете вы, — но это не объясняет, зачем писать автотесты. Надо просто писать без багов».

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

Кроме того, тесты могут объяснять, как работает код — по сути, хорошие тесты документируют код, который проверяют. В тестах можно посмотреть входные и выходные данные, примеры использования, ошибки, какой стейт приложения ожидается на входе, каким он будет на выходе.

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

А как же тестировщики?

Конечно, можно переложить всю работу по перепроверке своего кода на тестировщиков. У них же есть всякие наборы регрессионных тестов, тест-кейсы они там пишут какие-то — «вот пусть и занимаются своей работой». Иной раз доходит до того, что тестировщики начинают ковыряться в юнит-тестах и писать их за разработчиков! В ответ на возмущение такому подходу знакомый head of QA возразил мне фразой, попавшей в мой золотой фонд цитат: «Тестировщики вообще-то для того и нужны, чтобы делать за разработчиков их работу».

Почему так? Не на ровном же месте придумали тестировщиков! Какую проблему решают тестировщики? Тестировщики контролируют качество производимого продукта. То есть прежде, чем поставить продукт пользователям, тестировщики проверяют, что всё работает. Но неужели разработчики не справляются? Кто-то так говорит (в комментариях): «Нет! Разработчики не способны писать без багов».

Я же нередко слышу такой аргумент против тестирования разработчиками: «У нас нет времени, бизнес требует быстрее делать новые фичи». Под этим соусом мне даже один ведущий (!) разработчик предлагал не писать тесты вовсе. При этом из года в год опрос Gitlab показывает, что огромное количество инженеров считают тестирование бутылочным горлышком. В итоге:

1. Бизнес просит разработчиков быстрее пилить фичи.
2. Бизнес ставит тестировщиков проверять, сколько косяков наплодили разработчики, пытаясь сделать быстрее
3. Тестировщики отправляют на доработку фичи, чем вызывают задержки.

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

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

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