Итоги года

Моя жизнь в целом точно не стала хуже - считаю, что это самый важный итог)

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

В моем случае - почти никогда, и это очень грустно. Ну штош.

В 2023 я в основном занималась интересными вещами, поэтому к концу года наступили естественные последствия в виде заметной усталости.

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

Это потребует определенной дисциплины и смирения. Очень сложно волевым усилием перестать делать штуки, которые тебе интересны, но после энной попытки я наверняка справлюсь.

В будущем году мне очень хочется научиться отдыхать. Прямо отдыхать - чтобы в понедельник утром вставать с ощущением «душа просит подвига», а не «нууу… норм».

- Повышу приоритет хобби и физкультуре - сейчас они у меня присутствуют в жизни в следовых количествах и это не то, что я для себя хочу
- Займусь здоровьем (уже начала заниматься в 2023)

Скорее всего, года через 3 мне захочется переехать в другую страну и я очень, очень хочу находиться в этот момент на пике энергичности и здоровья:)

Профессиональные планы, которые я не вычеркнула:

- Выступление на QA митапе от нашей компании в Порту с тем же докладом про сообщества, который я представляла осенью в софийском офисе
- Подам заявки на конференции QA Challenge Accepted, Istacon, Seetest, Geek Girls Portugal - все с тем же докладом:) Может, добавлю что-то в презентацию, так как просто «копипастить» выступление мне неприятно, но основная часть работы уже сделана.
- Возможно, подготовлю доклад про тим лидство живого человека, который довольно далек от концепции успешного успеха и не может похвастаться избытком энергии. Если подготовлю - заявлюсь с ним еще куда-нибудь

Остальные планы:

- Начать снова заниматься болгарским (хотя бы раз в неделю). Мой уровень сейчас это «могу работать в супермаркете», хорошо бы дотянуть его до «объяснить дорогу курьеру или таксисту»
- Выделить больше времени на хобби и физкультуру (которые схлопнулись почти до нуля)
- Ну и уделить больше внимания здоровому образу жизни:) Режим дня, вовремя ходить к врачам, вот это все
- Отучиться и сдать экзамен на местные водительские права
- Купить уже наконец машину и регулярно на ней ездить

Мамина тимлидская радость

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

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

...список можно продолжать.

The last but not the least: я могу спокойно спать в отпуске:)

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

Но уже сейчас видно, что старт работы в QA у них очень хороший, и то время, что мы работаем вместе, прошли максимально не зря:)

Хочу быть тим лидом. Что делать? (1)

Навеяло дискуссией в одном чате. Спрашивали, что подучить для того, чтобы стать лидом. Я подумала и поняла, что не могу кратко ответить на этот вопрос.

Года три назад я бы сказала - ну, почитайте про планирование/делегирование, контроль задач, про мотивацию/демотивацию, про конструктивную конфронтацию, про переговорный процесс, то-се. Сходите на курсы.

Сейчас я бы предложила сначала разобрать это желание на составные части.

- Что, по моему мнению, делает тим лид?

- Почему я этого хочу?

- Что хочу получить в итоге?

Например, это может звучать так: "Хочу быть тим лидом, потому что мне не нравится работать руками".

О чем можно себя спросить?

Что конкретно значит “не нравится работать руками”? Что именно я не люблю делать и почему?

Причина может быть какая угодно.

Может оказаться, что не нравятся конкретные задачи, проект, команда.

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

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

Как так получается, что из этого следует вывод, что надо идти именно в менеджеры?

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

Хочу быть тим лидом. Что делать? (3)

Или так: "Хочу пойти в тим лиды, потому что там платят больше денег".

Тут можно спросить себя: почему я считаю, что лично я как инженер буду зарабатывать меньше, чем я как тим лид? А что, если как инженер я могу быть уровня ВАУ, а как тим лид я буду в лучшем случае на минимально приемлемом уровне и смогу претендовать на зарплату по нижней границе рынка?

Решение по результатам “раскопок” может оказаться примерно любым.

Например:

- Просто подождать, работая работу и увеличивая инженерные компетенции естественным образом (за счет выполнения задач). Возможно, с болью от инженерии (если она была) уйдет и желание тим лидствовать

- Перейти в другую команду, где принято иметь больший контакт между людьми

- Заняться дополнительными активностями: организацией хакатонов / багатонов /митапов в компании (как внутренних, так и внешних), волонтерской деятельностью в сообществах, участием в программных комитетах конференций

- Принять информированное решения расти в лиды. Можно договориться с текущим лидом о плавном росте компетенций. В качестве ближайшей цели взять замещение лида на время ее/его отпуска

- Изучить основ другой профессии в рамках IT и перейти в нее (скрам мастер, дев рел, менеджер проектов…)

- Выйти из IT. Такое тоже бывает!

- Уйти в отпуск за свой счет/саббатикал (если финансы позволяют) - если истинная причина желания менеджерить это сильная усталость/ выгорание от текущей работы

П. С. Задавала ли я такие вопросы себе, когда думала развиваться в менеджмент? Нет, конечно. Ретроспективно думаю, что они бы очень не помешали.

УПД: отложенный постинг странновато сработал. Переделывать не буду.

Лидеры разные

Когда-то я довольно сильно фрустрировалась об идею лидера (довольно стереотипную, если посмотреть на нее критически). С одной стороны, мне хотелось работать тим лидом, с другой - лид это же, ну… лидер! Знаете, такой, с харизмой 100 уровня, с подбородком и широкими плечами, и люди сами идут за ним стройными рядами. А я, надо сказать, нахожусь на противоположной стороне этой шкалы. Если есть какая-то неформальная компания, то обычно я в ней максимально не лидер. Это привносило неприятное сильное ощущение (с): куда мне в тим лиды? Может, не надо натягивать сову на этот глобус, несмотря на то, что очень хочется и вообще интересно.

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

Эта мысль очень перекликается с идеей профессиональной идентичности и аутентичности (про что я довольно часто думаю последний год), а также с реалистичностью требований к себе.

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

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

Можно было бы сказать себе “а ну положи свой тим лидский билет на стол!”, но делать я этого, конечно, не буду.

Вместо этого понемногу пишу доклад про тим лидство обычного живого человека. Думаю, он будет про видимость: рассказывать о том, что разные люди могут руководить командами, про заботу о себе (…коли доктор тим лид сыт, так и больному команде легче), и про то, как тим лидство может выглядеть изнутри.

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

Я начала читать блог Ольги довольно давно, еще года четыре назад. Он дал мне ворох поводов для рефлексии и огромную поддержку. Позднее мне посчастливилось познакомиться с Ольгой лично и сделать вместе некоторое количество активностей внутри сообщества QA Sisters.

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

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

Очень рекомендую Ольгу как менторку!

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

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

Ко мне приходят женщины, которые часто считают, что проблема в них. Это они не справляются и плохо работают. И ищут, чтобы такое сделать с собой ещё.

Я верю, что проблема не в человеке. Проблема – это проблема.

Я стараюсь помочь посмотреть на систему целиком, на то как она взаимодействует и влияет на человека.

Нам часто говорят, что мы можем все, если достаточно постараемся.

Фокус. Дисциплина. Контроль.

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

Мне нравится модель из трёх кругов уровня контроля. Что-то мы можем контролировать, на что-то влиять, а на что-то даже влиять не можем.

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

Мы можем что-то делать, у нас есть наша агентность, но далеко не все зависит от нас.

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

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

Как выгорание в айти, где систематически не признаются факторы рабочей среды. Или долина смерти при переходе в автоматизацию тестирования.

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

Фемоптика. Нарративная практика. Теория Волн Тоффлера. Нейроотличность. Dragon Dreaming. Модели выгорания. Подходы к обучению. И куча всего ещё.

Я не психологиня и не лезу в эту работу, стараясь определять свою зону компетентности и советуя людям других специалисток. Семь лет в терапии и иногда ношу туда рабочие кейсы.

Зато об меня можно подумать и поорать про процессы, релизы и рабочие сложности. И почувствовать, что вы не одни.

Если вам сложно, вы запутались и не понимаете, что делать – пишите в личку @red_foks, подумаем.

Организационные детали:

1. Я работаю без видео, только по аудио
2. Сессия длится 1-1.5 часа
3. Стоимость 4000 рублей за первую встречу, 3000 рублей за вторую и далее в рамках одного кейса.

#консультации_по_тестированию
#подпольный_евангелизм

В честь праздника 8 марта проведу одну бесплатную консультацию по тестированию или управлению командой.
Возьму в работу тот запрос, который мне самой больше отзовется. Писать можно в комменты или личку @pony_the_immortal.

Консультация в зуме, часовой пояс -1 к Мск.

Предложение актуально только для женщин.

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

...Прохожу курс по управлению качеством от Наташи Петровской. Вообще я планировала не брать дополнительную нагрузку, но искушение оказалось слишком велико, а режим обучения выглядел посильным. А еще мне очень заходит Наташин стиль повествования (мне кажется, у нее calming managerial voice:)

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

...Начала писать комментарии в collaborative articles в Линкедине. Испытываю неприятное сильное ощущение, что я там единственный живой человек в компании ботов. Сама идея сборной солянки из мнений разных специалистов по какому-то вопросу мне нравится, но как-то так получается, что почти все мнения подозрительно похожи на мнение ChatGPT - красивые слова максимально общего характера. Не очень мотивирует продолжать.

...В начале февраля у меня случился приступ вдохновения и я решила сделать курс по тест-анализу. Месяц (и примерно 50 часов затреканной работы) спустя курс стартовал. Предположительно я на него потрачу еще часов 50. Это если считать только сфокусированную затреканную работу… Диффузную работу особо не затрекаешь. Делать курс помогает моя bestie-in-testing Оля Артемьева. С ней у нас почти 30 лет опыта в тестировании на двоих, а еще она знает, как сделать так, чтобы люди не умирали от скуки на лекциях.

Постепенно собираю поток на май (почти набрала) и аккуратно планирую июнь-июль.

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

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

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

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

Итак, о чем мы там говорим:

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

Вебинар 1: Знакомство. Общие идеи и термины. На этом занятии мы с вами немного познакомимся, а затем поговорим об общих идеях, которые будут проходить через весь курс. Возможно, узнаем новое слово (1 шт).

Вебинар 2:
Работа с (как будто) понятными задачами. Если задача понятна - значит ли это, что ее можно просто протестировать? Просто протестировать - это вообще как конкретно? Можно ли применить такой же подход к сложным задачам? Давайте обсудим:)

Вебинар 3:
Теперь посмотрим в бездну:) Спросим себя - а что мы вообще тестируем? Заглянем под капот. Вспомним о нуждах бизнеса и пользователей. Найдем "слепые пятна" в покрытии.

Вебинар 4:
"Ты просто проверь, что ничего не сломалось!". Немаловероятно, что всем или почти всем из вас это знакомо:) Что-то порефакторили, или обновили библиотеку, или принесли идею фичи/улучшения... Подумаем вместе, с какой стороны тут можно подойти к тестированию.

Вебинар 5:
Работа с инцидентами. Поговорим про локализацию багов, про исследование проблем на продакшен системах и про то, что мы можем сделать на стадии тест-анализа, чтобы в будущем облегчить себе этот процесс.

Все же постараюсь не набирать больше активностей вне работы, потому что ну куда уже, оно же не лезет. Хотя вот Подлодка же - в ней так прикольно участвовать... И еще можно сделать доклад про то, как проектировался и реализовывался курс.

Интересных штук намного больше, чем времени и сил:(

Коротко о разном: всякое бывает (с)

- Приехала в Порту в командировку и отпуск
- Сходила на Geek Girls Portugal (правда, не с докладом, а просто постоять на стойке компании:) Никогда не пробовала этот вид деятельности, было в каком-то смысле интересно
- Выступила с презентацией "Think Twice Before Becoming a Team Lead" на митапе. Видео будет когда-нибудь (скорее всего, в ближайшие дни)
- На следующей неделе уйду в отпуск, планирую максимально гулять, лежать и не думать про трудовые подвиги

Несу видео моей презентации "Think Twice Before Becoming a Team Lead", с которой я выступила на оффлайн митапе dxTechTalk в нашем португальском офисе.

Возможно, потом сделаю отдельный пост с текстом презентации, но это не точно.

https://www.youtube.com/watch?v=SC3EaC5nqVA

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

Конечно же, это не даст полной картины затрат времени. Затрекана только сфокусированная работа, а сколько было размышлений в диффузном режиме - не сосчитать.
Тем не менее, на основе трекинга я могу сказать, что на проведение первого потока курса было потрачено точно не меньше 106 часов.

В эти 106 часов входит подготовка презентаций к 6 вебинарам (перекладывание идеи из головы на “бумагу”, черновые прогоны, обработка фидбэка от Оли), взаимодействие с дизайнеркой и юристкой, административная работа, проведение самих вебинары, подготовка и рассылка сертификатов.

На второй поток (апгрейд презентаций, административная работа, взаимодействие с дизайнеркой, проведение вебинаров (на данный момент - 2 из 6) ) я пока потратила 36 часов. Ожидаю, что в сумме уйдет примерно 50.

Очень помогает не впадать в иллюзии вроде “быстренько сделаю презентацию, у меня ж все в голове есть, надо просто презентацию набросать” или “у меня весь материал готов, надо просто рассказать его еще раз”.

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

🌟 Проверки логирования в тестах (формулировка проблемы)

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

В чем проблема, собственно? Мне навскидку пришло в голову несколько.

Проблема 1: Консистентность бага тесту. Точнее, ее отсутствие.

Например, баг observability фейлит функциональный тест. Функционально некритичный баг фейлит функционально критичный кейс.

А что бы мне хотелось? Чтобы баги фейлили соответствующие тесты, чтобы была консистентность между багом и тестом. Критичный функциональный баг фейлит критичный функциональный тест. Мелкий баг про смещенную кнопку фейлит некритичный тест про отображение кнопки.

Из проблемы консистентности вытекает проблема прозрачности.

Проблема 2: Прозрачность документации.

Если функционально все ок, а в логах проблема (например, что-то не залогировано или есть эксепшен) - получается, я должна пометить этот кейс как failed.

То есть документация говорит: у нас не работает важный функциональный сценарий!
Чтобы увидеть, что проблема именно с логами, а не функциональностью, нужно уже посмотреть на баг репорт.

А что бы мне хотелось: чтобы документация максимально прозрачно показывала, какие есть проблемы и какова их критичность. Если в тест ране пофейлен тест про создание сделок - значит, у нас проблема именно с созданием сделок (а не с логированием, цветом кнопок, расположением окна создания сделки и т п). Если у нас проблема с логированием/цветом кнопок и т п - то тест на создание сделки Passed, тест на логирование/цвет кнопок и т п Failed.

Проблема 3: Затраты на прогон тестов.

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

Если мы не можем аргументировать, почему мы тестируем это так - возможно, мы тестируем это просто по привычке, потому что так принято, потому что кто-то в прошлом написал тесты такого вида, а все остальные просто повторяют этот паттерн, принимая его на веру.

А что бы мне хотелось: чтобы мы не только тестировали то, что нужно протестировать, но и НЕ тестировали то, что НЕ нужно протестировать. Чтобы мы не только уточняли и расширяли тестовое покрытие там, где нужно, но и сокращали его там, где оно не нужно, и не делали работу, которую можно не делать.

Проблема 4: Затраты на автоматизацию

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

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

Проблема 5: Очень сложно сфокусированно протестировать именно логирование.

Например: решили улучшить логирование, для чего начали использовать Кибану. Чтобы логи можно было смотреть через Кибану, логи должны быть в одном формате. В настоящее время они в другом формате. То есть нужно переделать логирование так, чтобы оно производилось в другом формате.

Логирование каждого компонента переписывается ручками разных людей и тестируется отдельно. Каждая область логирования может сломаться более-менее независимо от другой.Проверки логов размазаны ровным слоем по примерно всем тестам. Гонять все тесты как есть - очень дорого. Придется проводить много функциональных проверок, причем с точки зрения проверки именно логирования значительная часть этих проверок будет дублировать друг друга. Будет сложно искать пробелы - что мы НЕ проверили в логах и какие функциональные тесты покрывают именно эти пробелы. То есть по сути надо будет полностью продумать тестовое покрытие для логирования, сделать черновик этого покрытия, потом как-то сматчить функциональные тесты на этот черновик… Решать эту задачу "в лоб" довольно долго и мучительно.

Что с этими проблемами делать, как решать?

Да просто давайте уберем логи из тестов! С вас пять тыщ (с)

Шутка. Над решением я еще думаю, но кое-какие идеи есть, я ими обязательно поделюсь в следующем посте.

🌟 Итак, тесты по логированию (big picture)

Что точно не хочу делать:
- тестировать логирование, когда это не надо (например, тестировать его по умолчанию для каждого релиза, особенно в рамках смоук тестирования)
- тестировать функциональность библиотеки логирования

Что хочу делать:
- тестировать, что нужная нам информация залогирована
- тестировать это недорого (не прогонять 100500 функциональных тестов, чтобы проверить логи)

Какое решение вижу:
- вынести проверки логирования в отдельные тест-кейсы
- убирать или добавлять их в план в зависимости от рисков возникновения проблем с логированием

Какие тесты я бы прогоняла в разных контекстах:

Контекст 1: Разработка новой фичи
- функциональные тесты: да
- тесты на логирование: да

Контекст 2: Фича уже в продакшен (активная работа над ней закончена)
- функциональные тесты: да
- тесты на логирование: нет

Контекст 3: Фича меняется (изменения функциональности, рефакторинг, что-то еще)
- функциональные тесты: да
- тесты на логирование: да

Контекст 4: Библиотека логирования существенно меняется (например, переходим на радикально другую версию библиотеки)
- функциональные тесты: нет
- тесты на логирование: да

Контекст 5: Переходим на другую библиотеку логирования (или интегрируемся с сервисом логирования, или что-то в этом роде)
- функциональные тесты: нет
- тесты на логирование: да

Позже напишу про дизайн конкретных тестов.

К вопросу о лишних словах.

Я знаю одного человека, который знает одного человека...

...который запустил поиск по тестам в Jira по слову "успешно" и нашел примерно 2700 тестов.

То есть в тестовой документации есть минимум 2700 слов, которые совершенно точно не приносят никакой пользы.
Только засоряют пространство.

(По мотивам обсуждения презентации коллеги)

Darling, you got to let me know
Should I test or should I no?
If you say the ticket's mine
I'll be testing till the end of time
So you got to let me know
Should I test, or should I no?

UPD:

Should I test, or should I no?
Should I test, or should I no?
If I no, there will be trouble
And if I test, it will be double
So come on and let me know