Всем привет, я Саша, инженер по тестированию ПО в Directum. Неотъемлемая часть моей работы — поиск слабых мест, недочетов системы. Фокус на недостатках оставляет отпечаток на образе мысли, взгляде. Работа требует внимания к деталям, определенного перфекционизма.

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

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

Давайте для начала определимся с терминами. Вот что нам говорит быстрый обзор от ИИ.

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

Критика может быть и мощным драйвером, и неприятной помехой для членов команды. Поэтому хочу провести грань между «деструктивной» и «полезной» токсичностью. Деструктивной токсичностью я буду считать то, что забирает силы и время у проекта и не приносит никакого результата. Полезной — то, что заставляет пройти команду/проект/человека через конфликт к принятию какого-то недостатка продукта/процесса/даже себя.

Ниже гипертрофированные примеры.

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

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

А напиток-то он потребляет с кем-то из смежной сферы, вследствие чего совершенно случайно компания может нести неожиданные репутационные потери. Казалось бы, причем тут слабый рост зарплаты на перфоманс-ревью? А все просто, инфляцию работодатель покрывает, а вот рост не виден. Как говорится, «критикуешь — предлагай». Да и с таким тестером просто работать не очень хочется.

Кто себя относит к Х, кто к У, а кто действует альтернативно, как Й? Пишите в комментариях.

Что нами движет?

Давайте прослезимся, примем реальность и совершим экскурс в недалекое прошлое. Во времена, когда о токсичности почти не зарекались.

На дворе 2021 год. Ковид закончился. Из каждого утюга реклама онлайн-курсов по тестированию. На рынке кадровый голод. ИИ — больше шутка, чем реальный помощник.  Именно в такое время мы начали создавать систему для КЭДО Directum HR Pro. Нашей целью было упрощение корпоративной жизни. Точнее, той ее части, которая меня лично сильно раздражала — переноса бумажек с одного места на другое. 

ПО должно было поменять (и поменяло) будни всех в компании. До его создания я даже не представлял, что заявления не придется носить ногами в кабинет кадровику, а шаблоны не нужно будет искать в разных папках той же локации. 

Мы делали решение для конкретных людей: простого Петровича и кадровика Джамили Фаизовны, той самой «ну распишитесь». Я точно понимал, что мы заняты важным и полезным делом. Перед глазами стояли заводские флешбэки: как сам носил документы между корпусами и слышал знакомое «Александр, почему не расписываемся?».

Я был одним из первых прикладных тестировщиков проекта. Имел богатый жизненный опыт, но абсолютно ничего не понимал в разработке. Мне было важно ничего не пропустить. Ни одного бага. Совсем вообще ни одного бага. НИ ЗА ЧТО! Был ли я чрезмерно дотошным? Определенно, да. Принесло ли это пользу продукту и моей репутации? Да. Но для меня сегодняшнего я тогда выгляжу токсиком.

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

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

Со временем постоянный поиск несоответствий и жизнь в формате «ожидание — реальность» становятся привычкой. Начинаешь замечать мельчайшие недочёты буквально во всём. С точки зрения качества продукта — отлично.  Если ты являешься катализатором качества, ищешь и находишь ошибочные векторы, особенно в момент появления идеи новой функциональности, даже ее проектирования — супер. Но если ты тратишь время на летучке на лексический разбор значения слова Statement и разъяснение причин, почему его некорректно использовать в контексте заявления на отпуск, то,  дружочек-пирожочек, ты перешел грань.

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

Возмущаться или нет? 

У каждого человека в команде может быть своя точка зрения, отличная от других. И у всех есть причины ее придерживаться. Например, ты можешь тысячу раз беситься, что кнопка «назад» тебя выбрасывает из приложения. Но директор продукта скажет, что фиксить ее прямо сейчас слишком дорого, в приоритете другие векторы развития. И будет по-своему прав.

Тут хочется обвинить автора в биполярке и спросить, «а что же делать, если тебя не слышат и хотят оставить в продукте какой-то крит?»

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

Внимательный читатель скажет: как же так? Это что за прошлый век? Где вот эти вот все ваши CI/CD, left-shift, unit'ы и другие прелести. Дисахаридный мой читатель, отошлю тебя на пару абзацев назад. Мы начинали как стартап и не было никогда ни у кого 100% уверенности, что это вообще будет легально и востребовано. Конечно, сейчас мы обмазываемся этим вашим CI/CD и смотрим на зеленые галочки. В самом начале нам нужен был продукт. Здесь и сейчас. Завтра его просто могло не быть.

Итог

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

Да, на другой стороне всегда будут более объективные показатели, например время. Ты не можешь выиграть у времени, ты должен донести сквозь призму твоего негативного «токсичного» взгляда все худшие недостатки, которые ты не в силах принять в твоем Любимом Продукте.

Критикуй, но не оскорбляй. Объективно указывай на недостатки, а не ненавидь просто так. Предотвращай факапы, а не вини кого-то в них. Говори о несовершенстве, но слушай другую сторону. Помни: ты тоже человек и можешь ошибаться. И, пожалуйста, не переноси работу в повседневную жизнь.

Комментарии (6)


  1. Oeaoo
    22.12.2025 06:43

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


    1. Bratken
      22.12.2025 06:43

      Автор упустил огроменнейшую возможность подискутировать на тему нейродивергенций и мета-когнитивности. Эти две вещи объясняют жизнь на 80%


  1. Bratken
    22.12.2025 06:43

    Я тоже QA, но не тот, который зеленит кейсы и гриндит регрессы (это тоже есть, конечно), а кто топит за шифт-лефт, разбирает автоматизацию, если надо, и не боится закатать рукава и систематизировать хаос, пытаясь найти общий язык со своими разработчиками. А причина одна - почти все тестеры выучили беспомощность, поэтому и ходят ноют, что то не работает и это. И вообще все им должны все приносить готовое. Отчасти потому что начали с такой компании, где поощряется не отвечивать и проявлять инициативу и любознательность и не знают, что можно иначе. И про "критикуя - предлагай, предлагая - делай" проникся по самые шары.

    Посмотрите на разработчиков: люди шпилят на двух-трех языках, пишут автотесты и юнит, и интеграционные (на +1 языке), сами себе докера строят, CI/CD, БД админят/дебажат запросы. Я теперь понимаю, почему QA часто ненавидят. Не потому что въедливые на уровне, простите, аутизма с его низкой толерантностью к размытым задачам и мыслям, а потому что не хотят ничего учить и прокачиваться. Наслушались о том, что QA это изи и многие со своих условных техподов повылезали на роль тестировщика и понимают, что ИТ это про постоянное обучение, и решают засесть на много лет, думая, что обойдется. А потом собесишь вот такого с 10 годами "опыта", а человек даже линукса не трогал. Меня в свое время стебали на собесе, мол, "бро, у тебя в команде были пайплайны налажены и ты не удосужился заглянуть внутрь?" У разработчиков аналогичные истории, конечно, тоже есть. Но тестировщики бьют планку выученной беспомощности влегкую.

    Насчет того, что кому-то что-то нужно доказать по багам - это красный флаг dysfunctional команды. В нормальной здоровой команде люди понимают систему, которую разрабатывают, только если это не условный Сбер с кучей легаси и сервисов. Ну и просто в нормальной команде люди послушают друг друга. А так, компания не твоя - ьы в ней никто и звать тебя никак, и тебя в любой день могут сократить, поэтому никто не стоит твоих нервов. Если команда адекватная, то за нее стоит держаться, конечно, потому что это редкость. Если обычная мыльная команда с дейликами "взял таску, сделал таску, переключился на таску", то там просто логируешь все свои телодвижения, чтоб не прикопались, если вдруг что-то пойдет не так.

    Описываю это как человек сменивший 6 компаний за 9 лет. В первой проработал 3 года, в текущей, седьмой - 1.5 года. Т.е. 4.5 года на 5 компаний осталось. Всякое повидал и нормальных компаний и/или команд мало. Затыки на уровнях от исполнителей и среднего звена до руководства выше. И сбегал именно из-за болота и пассивности коллег. И чаще всего это были кьюеи, которым даже env в питоне было западло переключить, чтоб воспользоваться внутренней тулзой для тестирования. Не говоря о том, что люди проработали там по 2-3 года и все равно не знали, как сервисы работают.


  1. RomanLoshkarev
    22.12.2025 06:43

    А зачем девопсы, если вы сами всё делаете?) или их у вас нет на проекте? Почему тестировщик тратит 16 часов на развёртывание?)


    1. Pushin_as Автор
      22.12.2025 06:43

      Обращу внимание, что это были гипертрофированные примеры. Не из совсем реальной жизни.

      А вообще практика тестировщикам самим поднимать тестовое окружение вполне себе адекватная, просто для этого требуется инфраструктура. И вот для этого как раз и нужны девопсы.


  1. next_account
    22.12.2025 06:43

    хвалить нужно человека а ругать предмет - тогда люди меньше расстраиваются. пример из детсада как надо: "Оля смотри какое солнышко кривое получилось" (солнышко само получилось, оно виновато), "Оля какие красивые и пушистые тучки ты нарисовала" (хвалим Олю, молодец она). как возможно надо с коллегами: "смотри какая функция медленная" (функция виновата), или "о какой ты молодец, еще тестов добавил" (хвалим человека). а если ты поругал человека 1 раз - то должен похвалить потом не менее 5 раз - эмоционально негатив кратно тяжелее воспринимается, что бы поднять человеку настроение нужно кратно больше сил приложить чем для того что бы его уронить (настроение, не человека).