"Разрабатываем без нянек" (с) или как минимизировать участие тестировщиков в вашей работе

По мотивам сегодняшнего подкаста Radio QA. Читаем, набрасываем вопросы на вентилятор в 14.05 18.00 по Мск.

Мы уже обсуждали вопрос «почему разработчики не пишут тесты«

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

А если допустить фантастическое, что верхи и низы (или правые и левые?) хотят одного: работать правильно. И писать с тестами, и тестировать, а не проверять? То есть просто супер-пупер все, с чистого листа.

отсюда

С чего начинать?

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

Нигде в литературе по программированию нет информации о способах проверки функциональности кода. То есть тупо ни в одной книжке по C++ (насчет других не знаю, но тоже не помню)  нет даже главы про тестирование кода.
Вы изучаете программирование, но зачастую не знаете, как правильно проверить то, что вы там напрограммировали. Часто на собеседованиях люди так прямо и говорят: «ручками проверяем».

В принципе мало информации о том, как это (проверку кода) правильно делать. Она, как
правило, живет у отдельных умных книжках. Эти книжки можно пересчитать по пальцам. Это одновременно и хорошо — вроде как все изучить и начать использовать несложно, и плохо — эти книги не на виду и получается, что это тема для «особенных» криворуких разработчиков которые и написать правильно не могут, и ломают написанное постоянно.
И одними юнит-тестами здесь не обойдется.

юнит-тесты (с)

Надо учить тестировщиков (если они у вас есть), как правильно тестировать. Тестировать, а не проверять. А если их нет — то этому надо учить разработчиков 🙂

отсюда

2. Научиться понимать задачи друг друга

Если вам повезло/не повезло (нужное подчеркнуть) и у вас есть выделенные тестировщики — то надо объяснить и им, и разработчикам, зачем они нужны. Как бы это не смешно звучало.

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

Тут важную роль играют коммуникации и знания (см. п.1).

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

3. Научиться переключать mindset
Часто говорят, что разработчик не может хорошо проверить свой код, потому что он его создал. Он не может посмотреть на него критически. На самом деле может, просто надо уметь мозг переключать.
А если это не получается, то тут надо подключать просто другого человека. И это не обязательно должен быть тестировщик.

4. Решить, можете ли вы обойтись без выделенных тестировщиков?

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

Дальше просто возникает вопрос эффективности и знаний.

Например, большинство продуктов, в разработке которых мне удалось поучаствовать за 15 лет, работали во взаимодействии со сложной инфраструктурой развернутой у наших пользователей. Это были Microsoft Active Directory, Exchange, SharePoint, Hyper-V, VMware vSphere и прочий зоопарк рядом с ними. Есть люди которые просто зарабатывают деньги только тем, что знают как это все работает, как это все правильно настроить и тд и тп.
Нам же, как разработчикам, приходится все это изучать, разворачивать и тд, просто для того, чтобы проверить свой код, код продукта, который работает и взаимодействует со всем этим зоопарком.
И часто это непростая задача. Задача реально выполнимая (тут вспоминается одна «животинка» от Hewlett Packard, которую я за день так и не поставил), но требует времени и часто желания.
Если бы в команде был специалист, который обладал бы этими знаниями и постоянно поддерживал свой уровень — это сильно бы облегчило всем работу.

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

Ну а если такого человека нет, то «чудес не бывает» — вы будете сами все делать. Или за вас это будут делать реальные пользователи. Хорошо это или плохо, можно ли с этим жить или нет — решать вам.

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