Вчера в споре на Пикабу мы внезапно начали рассматривать мир, созданный Богом, с точки зрения теории тестирования. В итоге разговор уехал в довольно сюрреалистичную сторону: обсуждали наш мир, как будто это продукт, который человечество пытается принять на приёмочном тестировании. С багами, фичами, отказами, критериями приёмки и вопросом “а кто вообще пользователь”. Получилось неожиданно смешно и местами очень в точку. Ниже — часть этого диалога, потому что получилось слишком хорошо, чтобы пропадать.

Мои ответы - обычным текстом, ответы второго участника обозначены цитатой. Итак, начнем:

...
Если бы Бог существовал, думаю, он бы давно её покинул. В поисках планеты с более адекватным населением.

А почему покинул? Что его заставило бы бросить столь гармоничное творение рук своих?

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

А что, если это не баг, а фича, просто ваша квалификация не позволяет вам оценить все ее преимущества?

Если говорить языком тестирования, то аргумент про фичу работает ровно до момента приёмки. На приёмочном тестировании решает не квалификация тестировщика, а соответствие ТЗ и ожидаемым сценариям эксплуатации.

Берём тело человека как продукт. ТЗ очевидное: жить долго, стабильно, без самоуничтожения при обычной эксплуатации. Что имеем по факту. Критически важные системы без резервирования. Один тромб или сбой иммунки — и продукт уходит в аварийное завершение. Износ заложен в архитектуру, автодеградация включена по умолчанию. Ошибки проектирования: дыхательные пути и пищевод пересекаются, из-за чего продукт регулярно умирает от еды. Спина не рассчитана на вертикальную нагрузку, зубы не восстанавливаются, сетчатка смонтирована наоборот. Это не тонкие настройки, это дефекты уровня дизайна.

Теперь функционал поведения. В систему встроены агрессия, жадность, склонность к иерархиям и насилию, при этом нет встроенного механизма коллективного самоконтроля. Итог предсказуем: войны, эксплуатация, экологический суицид. Если система массово воспроизводит катастрофические сценарии — это не сложная фича, это дефект бизнес-логики.

Любой тестировщик спросил бы: а где защита от дурака? Где ограничения на опасные действия? Почему пользователь с минимальным доступом способен уничтожить миллионы и планету заодно? Почему обновления идут через катастрофы и вымирания, а не через патчи?

Фича — это когда поведение предсказуемо, полезно и соответствует целям продукта. А когда продукт стабильно крашится, пользователи страдают, а разработчик молчит две тысячи лет — в отчёте это пишется просто: система не прошла приёмочные испытания, к промышленной эксплуатации не рекомендуется.

С чего вы решили, что вам известно ТЗ и вы - приемщик?

Ваша ошибка в том, что вы водрузили себя на вершину мироздания. Вы выше и умнее президента, бога и всего никчемного человечества, вместе взятого. Естественно, вам там холодно и одиноко в вашем совершенстве.

А всего-то нужно допустить, что окружают вас не дураки и козлы, а существа, чьи мотивы вам попросту непонятны из-за недостаточной осведомленности

Тут вы как раз подменяете роли. Я себя никуда не водружаю, я стою в самой приземлённой позиции — пользователя и эксплуатанта системы. ТЗ мне известно ровно настолько, насколько оно известно любому пользователю: система предназначена для жизни, воспроизводства и взаимодействия без постоянных фатальных сбоев. Если бы у чайника в инструкции не было ТЗ, но он регулярно бил током и взрывался, вы бы тоже сказали: вы просто не понимаете замысел инженера?

Приёмщик — это не бог и не гений, это тот, кто смотрит на поведение системы в реальных сценариях. Массовая смертность от тривиальных причин, войны как штатный режим работы, общества, которые регулярно самоуничтожаются, тела, которые выходят из строя без возможности ремонта — это не вопрос высокомерия, это наблюдаемая статистика. Тут не требуется всеведение, достаточно логов.

Про мотивы тоже забавно. В тестировании есть такой момент: если система ведёт себя непредсказуемо и опасно, разработчик может сколько угодно говорить про сложную архитектуру и скрытые смыслы. Но приёмка смотрит на результат. Если пользователь погиб, продукт не становится лучше от того, что у него была глубокая внутренняя мотивация.

И наконец, аргумент про недостаточную осведомлённость — универсальная отмазка любой кривой системы. Вы просто не понимаете, как это должно работать. Отлично. Значит система не только багованная, но ещё и с нулевой документацией и отсутствием поддержки. В промышленной эксплуатации это называется провал проекта, а не таинственная фича.

То есть допустить, что ТЗ включает в себя некоторый процент взрывающихся чайников, вы не можете?

Могу. Более того, в тестировании это давно известно и называется допустимый уровень отказов. Только есть нюанс: он всегда явно прописан, ограничен и не затрагивает всех пользователей подряд.

Если в ТЗ написано: 0,001% чайников может взорваться при нарушении инструкции — окей, подписываемся, ставим предупреждение и идем дальше. А если чайник взрывается регулярно, в любой стране, при штатной эксплуатации, убивает соседей и иногда поджигает весь дом — это уже не процент отказов, а дефект архитектуры и отзыв партии.

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

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

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

Отличный пример, кстати. Он как раз идеально показывает, где заканчивается инженерия и начинается мифология.

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

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

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

Так что да, можно придумать сколько угодно летающих крокодилов и алюминиевых огурцов. Только в отчёте по качеству всё равно будет сухо и скучно: архитектура неустойчива, цена функционирования неприемлема, система ориентирована не на пользователя. А дальше пусть разработчик сам решает — переписывать продукт или продолжать рассказывать сказки про великий замысел.

А с чего вы решили, что вы пользователь, а не огурец на поле, а то и вовсе крокодилье дерьмо?

Отличный ход, кстати. Но он снова мимо приёмки.

В тестировании роль не выбирают по философским соображениям, её определяет наблюдаемое поведение системы. Я пишу, думаю, спорю, фиксирую дефекты и формулирую требования. Огурцы этого не делают, крокодилье дерьмо — тем более. Значит, по факту я пользователь и наблюдатель, а не элемент удобрения.

Если бы система позиционировала меня как навоз — вопросов нет. Тогда ТЗ должно быть честным: человек — расходный материал для поддержания роста алюминиевых огурцов. Но система почему-то продаётся под лозунгами смысла жизни, свободы воли и высокой миссии, а не как аграрный субстрат. Это уже несоответствие заявленного назначения фактическому использованию.

В инженерии это называется скрытая функциональность с разрушительными побочными эффектами. Когда выясняется, что ты не пользователь, а побочный продукт, — приёмка разворачивает релиз без разговоров. Потому что если продукт не знает, кто его пользователь, значит архитектура сломана на базовом уровне.

Так что кем угодно меня можно объявить задним числом. Но пока система позволяет мне фиксировать баги и задавать неудобные вопросы — тест продолжается, а релиз всё ещё не принят.

Откуда вы знаете, что делают огурцы и навоз, вдруг у них внутри тоже вселенная, просто она недоступна нашему пониманию? Почему вы не допускаете существование точек зрения, отличных от человеческой и лично вашей?

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

Я как раз допускаю. Более того, в тестировании это стандартная практика — разные стейкхолдеры и разные точки зрения. Пользователь, администратор, система, окружающая среда. Всё учитывается. Разница только в одном: у кого есть интерфейс обратной связи.

Если у огурцов и навоза есть внутренняя вселенная, логи, требования и канал эскалации — отлично, пусть приходят на ревью. Но пока ни один огурец не оформил баг-репорт, не описал сценарий воспроизведения и не предложил критерии приёмки. А люди это делают регулярно, причём массово и тысячелетиями. Это не мания величия, это просто наблюдаемый факт.

И да, мироздание не только про людей. Но почему тогда именно людям выдали сознание, рефлексию, способность осознавать дефекты и обсуждать устройство системы? В тестировании это называется не венец творения, а компонент с диагностическим модулем. Очень странно встраивать такой модуль и потом говорить: а чего вы вообще что-то анализируете, вы, может, навоз.

Если же принять вашу логику до конца, то любое обсуждение качества системы теряет смысл. Огурцу больно, навозу обидно, крокодилу страшно — и у всех своя правда. Отлично. Тогда остаётся только один вывод, тоже вполне тестировочный: система не имеет определённого пользователя, не имеет измеримых критериев качества и не подлежит приёмке в принципе. А это уже не великая сложность мироздания, а просто продукт вне инженерного анализа.

Так что точки зрения я допускаю любые. Но пока разговаривают люди, а не огурцы, тестирование неизбежно остаётся человеческим. И баги от этого никуда не деваются, сколько ни расширяй вселенную.

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

Такое ведь тоже может быть?А если они приходят, но не к вам, потому что не знают о вашем существовании?

Еще раз: с чего вы взяли, что вы - пользователь? С того, что разговаривают только люди? Так люди разговаривают с людьми, а больше ни с кем. Да, были попытки общения с дельфинами, касатками и гориллами, существует дрессура и обучение многих животных.

Но это говорит не о том, что огурцы не разговаривают, а только о том, что они не разговаривают так, как можем мы.

Может. Теоретически вообще всё может быть. В тестировании это называется нефальсифицируемая гипотеза — красивая, но абсолютно бесполезная для оценки качества.

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

Так вот, если человек не пользователь, а побочный эффект, то это не откровение, а просто плохой продукт-менеджмент. Потому что система массово взаимодействует именно с людьми, а не с богом. Люди получают урон, люди несут издержки, люди фиксируют инциденты. В тестировании это и есть пользователь, нравится это кому-то или нет.

Аргумент про огурцов, которые обсуждают нас в своей вселенной, симпатичный, но он ничего не меняет. Если у них есть своя приёмка — прекрасно. Но это никак не отменяет того, что в человеческом контуре система нестабильна, опасна и плохо документирована. Два параллельных контура не взаимоисключают друг друга.

И последнее. Когда разработчик говорит: система не предназначена для вашего понимания, приёмки и оценки, но вы обязаны в ней жить и умирать — это уже не философия. Это отказ от ответственности под видом великого замысла. В любой зрелой инженерной культуре такой проект закрывают, а не оправдывают разговорами про высшие уровни приёмки.

Так что да, возможно, бог доволен. Но пока релиз крутится на людях, а SLA выполняется за их счёт, человеческая приёмка остаётся валидной. И она эту систему, мягко говоря, не принимает.

Спор продолжился, но дальше было уже не так интересно.
Спасибо за внимание!