Есть такая широко известная в узких кругах бабушка, Элизабет Хендриксон. Это известный специалист по тестированию, которая стала знаменита благодаря своей статье 2000 года better testing, worse quality.

Пересказывая суть статьи в 2 словах: в одной софтверной компании произошла очень странная ситуация. Чем больше тестеров они нанимали, тем хуже качество софта было на выходе. Оказалось, что разработчики перестали проверять свою работу сами и стали отдавать код тестировщикам без тестирования.

Казалось бы, ну и что? Это не их работа тестировать, их работа код писать. Хорошо, но почему тогда это ломается?

Вообще говоря, ответ на этот вопрос давно известен: это типичная проблема shift-right. Кто-то помнит, как я уже рассказывал, что в автомобилестроении есть такая же беда. Заводы, где дефекты сборки не устраняют на месте, а оставляют на контроль качества, стабильно имеют радикально худшее качество на выходе, чем те, у которых косяки исправляют сразу. Просто потому что контроль качества оказывается перегружен и не способен обнаружить все пасхалки от сборщиков.

Вот и в статье проблему починили классическим lean-подходом из того самого автомобилестроения: сделали shift-left и build quality in. Короче, заставили разрабов тестить самостоятельно.

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

Про баг, который и правда фича

Так вот, история. Эта самая Элизабет Хендриксон однажды попала в команду к экстремальщикам и мрачно офигела с того, какой это другой мир. Конечно, любой экстремальщик прекрасно понимает, о чем я. После знакомства с экстремальным программированием картинка переворачивается с ног на голову у всех: как прежде ты уже на разработку смотреть не можешь.

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

- Зачем ты выдумываешь новый функционал?!
- Что значит, новый функционал? Это же недоработка, баг.
- Нет, Элизабет, - говорили ей, - баг - это когда что-то работает не так, как планировалось. А вот так, как ты хочешь, оно никогда и не планировалось. Ты просто называешь новый функционал багами.

Это я к чему вспомнил. Да вот сейчас на работе вот так: пользакам выкатили мвп, а они свои хотелки нам накидывают, оформляя их как баги. "Ну а как мы без этого должны работать?"

А ты им, как попугай, одно и то же: все сделаем, все будет, но не сразу. Давайте то, без чего совсем беда будет.

Начальство за это грызут: чего это у вас столько дефектов? Хорошо, хоть нам такие вопросы никто не задаёт. Но был в моем опыте и момент, когда в похожей ситуации начали задавать: вы ж говорили, что у вас автотесты и тдд, а тестировщик у вас баг за багом находит.

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