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

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

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

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

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

Что еще посмотреть:
Нужны ли тестировщики, если разработчики пишут тесты?
Почему разработчики не тестируют свой код?
Кто такой хороший тестировщик?

Комментарии

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

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

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

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то ...

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе...