К основному контенту

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

Первый наброс по мотивам сегодняшнего подкаста 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 устроен, как его готовят используют правильно?

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

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

Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются.

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода.

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

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

Полезные ресурсы для молодых (и не только) тестировщиков

Уже 3 месяца провожу собеседования тестировщиков.
Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным.

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.