Что такое T-образный тестировщик?

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

Гм…

А что/кто такое Г-образный тестировщик?

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

А кто такой Б-образный тестировщик?

Это пузан в короткой футболке. В офисе не появляется, бо у вас там слоняются Гэ и Тэ-образные тестировщики «и в проезжих сеют страх»…

Правильно соображение о том, что в будущем любой «нормальный» ИИ будет стоить много денег, и человеки будут вынуждены недоедать, чтобы суметь заплатить подписку в $1000 в месяц на chatGPT, и это будет безальтернативно, даже если появится много его аналогов. В последнее время много говорят о том, что OpenAI убыточен, но закрываться нельзя, поэтому деньги сжигаются в ожидании какого-то лучшего будущего (когда юзеры начнут платить).

Факт, что все подсядем.

И не факт, что будем платить.

ИИ внутри компаний в перспективе будет локализованным, как сервера или NAS. Поднял у себя условный RAG (перевод с румынского кому-то нужен?) или какой аналог у этого всего будет в будущем, и погнали создавать и расширять внутрикорпоративную базу знаний, в которой ИИ «всë про тебя знает и ничего не забывает» — ключевое ограничение любого внешнего сервиса.

Чем дешевле будет железо в будущем, тем проще будет поднять домашний сервер «+ИИ». Возможно, это даже будут носимые девайсы.

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

Через какое-то условное время крупным компаниям придется днëм с ментами с фонариками искать живых людей, которые еще не додумались поднять у себя дома свой, очень личный и постоянно деньгуприносящий сервис и хотели бы ходить работать в офисах будущего, с бесплатным кофе и HR. Это может быть и частный бизнес, и участие в каких-то глобальных проектах по просчитыванию гигантских проектов за мелкий прайс. Сервер крутится, биткоин мутится.

(боевым голосом Остапа Ибрагимовича) Электронный конь грядет на смену офисной крестьянской лошадки!

Современные программисты еще не совсем, но уже скоро начнут понимать тестировщиков и бизнес.

Для бизнеса программист — это живой ИИ-агент. Он что-то делает и выдает, мол, готово. Бизнес это трогает, пугается, говорит «Нет. Тут не то, тут не так. Сделай/Переделай нормально. Вот требования (контекст), учти это и это». Он приносит переделанное… Бизнес ищет другого ИИ-агента, который что-то делает и…

Тем временем программисты, которые не понимают эту бесконечную круговерть, делятся мудростью:

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

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

А это всë неизбежно, если использовать генерилки как школьник, в режиме «сделай вместо меня». Будет он проверять импорты руками, как же…

И всë поменяется. То, что вчера было нормой, станет признаком элитарной элиты — руками, сэр, только руками. Мы не покупаем искусственный код. Появится движение «Оставь агентов джунам!» с вопросами вроде «Если ты такой умный, то почему всë ещë пользуешься ИИ-агентами?» и «А вот в наше время…»

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

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

Oboe.fyi— AI-платформа для генерирования персональных образовательных курсов на определенную тему.

Там генерируются
* какой-то текст
* аудио-лекция
* подкаст с двумя AI-ведущими
* интерактив — квизы, кроссворды и флеш-карточки
* саммари и FAQ

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

Я спросил про Analytical software testing, и он сделялъ:
https://oboe.fyi/courses/unlocking-software-quality-through-analytical-testing-9wgrr7m2

Ну… он хотя бы попытался. И ведь ЧСХ, объяснить — нет, но никто ж не обещал объяснить. Сказали, что сгенерируют образовательный курс — и сгенерировали. Чего же боле, что вам могу я сгенерять?!

Если ты прежде ничего не знал и не понимал про analytical testing, то после моего сгенерированного курса ты будешь знать про analytical testing и всë ещë ничего в нëм не понимать в два раза увереннее!

Возможно, для точечных кулинарных запросов или для «как взломать замок чужого гаража» такие персональные нейрогенерокурсы подойдут идеально. Ну или для наглого генерирования платных курсов про AI… их же в наше время очень мало (опытный инфомолдаванин во мне протяжно вздыхает).

Только тебя и не хватает на https://certifiedunicorns.pro/hot-istqb-conference — 25 октября (суббота) 2025 с 11.30 до последнего зрителя, который самостоятельно отключится в 17.00

Деякі видають аромат успіху, інші — димлять порожнечею. Ми просмажимо все до хрускоту і чесно розкажемо, що реально дає користь (прямые руки), а що — фігня (кривые ожидания).

Бесплатно, за умови володіння мовою солов'їною

В январе 2015-го Тим Урбан, ээ, дропнул большую статью «The AI Revolution: The Road to Superintelligence». В то время было захватывающе интересно об этом всём подумать. Сегодня как-то нет, но не суть.

По-моему, именно от рассуждений Тима пошли в народ страшилки про то, что

…Но может произойти и следующее: слабому ИИ потребуется несколько десятилетий, чтобы стать AGI с низким уровнем интеллекта, но в конечном итоге это все равно произойдет. Компьютер будет способен понимать окружающий мир на уровне четырехлетнего ребенка, но уже через час он будет понимать сложнейшую теорию физики, которая объединяет теорию относительности с теорией квантовой механики, что не удавалось сделать ни одному человеку. Через еще полтора часа AGI достигает уровня ASI и будет превышать интеллект любого человека в 170000 раз или 270000, или какая разница вообще.

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

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

Разговоры о вероятном могуществе супер-интеллектуального интеллекта подобны пространным мечтаниям о том, какие бенефиты МОЖЕТ БЫТЬ подарит мне жизнь, когда я, наконец-то, выучу гамму ми минор, соберу группу, запишу звездный альбом и начну куролесить по миру с многотысячными концертами. Осталось только купить гитару и научиться дёргать на ней струны… а потом вдруг понимаешь, что тебе уже 50 лет и гамма ми минор выучена только на 75%.

В файлах по делу Эпштейна есть вот такенный файл: https://www.justice.gov/epstein/files/DataSet%209/EFTA00315849.pdf

Внутри 158 страниц забористых примеров всякого растления малолетних линуксоидов на BASH образца 2005-го года.

Там же указаны имена авторов сего документа, очевидно связанных с консультированием покойного Эпа Штейна:

* Chet Ramey, Case Western Reserve University
* Brian Fox, Free Software Foundation

Я давно знал о тлетворном влиянии обожаемого мною программирования на bash, но даже и не подозревал о масштабах трагедии! Спасибо товарищам Рамею и Фоксу за долголетнюю службу на благо обществу свободного ПО!

https://testitquickly.com/2026/02/20/mesterul-manole-rastoarna-caldarea/

Что осталось за кадром — очень часто и много хотелось ругаться по-боцмански, но меня ж могут читать дети минут, которые никогда не поймут круговорота часов, а мат они поймут и запомнят…

Ну и нет ответа. Хорошо поставленный вопрос нуждается в разрешении (хотя бы и в тонику), но его нет. Удручённый сидишь такой и думаешь о чем-то неудручённом. А не о чем таком думать.

Есть книга Роберт Пëрсиг «Дзэн и искусство ухода за мотоциклом»

Рычу от удовольствия! Вроде ни про что конкретно, но о чëм-то очень базовом и важном; постоянно отвлекаюсь на «это надо обдумать».

Краткий пересказ: один чувак в США изучал философию, свихнулся, вышел из дурдома, обзавелся друзьями, взял своего сына, одежду, большое острое мачете и все вместе на двух мотоциклах (Honda & BMW) поехали в семнадцатидневное мотоциклопутешествие из Миннеаполиса в Сан-Франциско. Смартфона у автора нет, поэтому по пути он постоянно думает об основах мироздания и прописывает базу подхода к работе в будущих айтишных офисах XXI-го века. В итоге до куда они там ехали доезжают только двое. Кагбэ всë.

Книга 1974-го, но изложенная в ней база до сих пор верна — перед тобой встаёт НЁХ (тикет), которую надо решить, чтобы она передвинулась в Done. А как ты решишь то, что непонятно откуда взялось и хз как оно работает? А точно так же, как дворовые пацаны чинят моцотиклы и потом злят мусоров — вовлекаешься в задачу (присутствуешь), расчехляешь научный метод познания, выдвигаешь гипотезы и проверяешь их одну за другой, пока проблема не будет решена. Одной рукой читаешь справочник моториста, второй листаешь Канта чтобы понять, откуда мы вообще знаем то, что мы знаем (источник требований для тест-кейса), и как мы определяем, верно ли оно или придумалась очередная чертивня. И так в цикле.

В какой-то момент понимаешь, что весь тест-дизайн основан на принципах ремонта первого массового «супербайка» Honda CB750 1969-го.

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

В одном из ранних интервью Пирсиг отмечал, что разные издательства отклоняли книгу 121 раз, прежде чем издательство Уильяма Морроу приняло её к изданию (что является рекордом Книги рекордов Гиннесса). На деле издательства отклоняли не всю книгу, а только краткую заявку на неë, но всем как всегда…

https://testitquickly.com/micropost/%d1%8d%d1%82%d0%be-%d0%bd%d0%b0%d0%b4%d0%be-%d0%be%d0%b1%d0%b4%d1%83%d0%bc%d0%b0%d1%82%d1%8c/

Наткнулся на канал, который настойчиво прогнозирует технологическое будущее человечества

Если суметь посмотреть (в бездну) без истерики, то LLM в отдельных задачах рулез, но в целом — нездоровая тема.

Хорошо, когда LLM помогает что-то сделать или понять. Но…

Это ПО: не всегда адекватно, не всегда стабильно, иногда меняется, иногда недоступно (saas же)… И не может ПО «учиться на исправлении ошибок». Истинная галлюцинация LLM в том, что это все воспринимается хьюманами как результат чего-то интеллектуального.

LLM подстегивают возможность снижать и техническую, и когнитивную рабочую нагрузку, а это незаметно размывает/ослабляет рабочие навыки. Как же это похоже на судьбу многих менеджеров! Постоянно кажется, что ты всë понимаешь и можешь в любой момент вмешаться и сделать как надо, а когда таки надо вмешаться — ты ВНЕЗАПНО не понимаешь, что там происходит, не можешь что-то исправить, не управляешь ситуацией, но все еще обязан за все это отвечать.

Ты уже вообразил себя «AI-кентавром», в котором ты постоянно сидишь в разделе управляющей головы, а на деле тебе уже поручили шуршать копытами, которые незаметно переходят в раздел лошадиной задницы, по которой постоянно и заметно больно стегают плеткой, чтобы ты громче игогокал и шибче скакал не спрашивая, куды мы бегим и зачем. Ну что ты за голова, если уже не понимаешь, как там все устроено и уже неспособен объявить новую функцию с одной переменной без запроса в LLM?!

А еще могут исчезнуть компании, которые держат LLM на своих серверах. А у тебя pipeline уже полностью на удаленном Claude. А оно обанкротилось.

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

Поэтому да, the planet is fine…

https://youtube.com/clip/Ugkxq-M0KSdm1QH1huzUgzBkhzNnhcZpTdYy?si=OWu67alyrJvWuKqJ

В конце игры останутся только две компании, которые будут хоть кого-то хоть как-то нанимать:
* openai
* anthropic

Andrej Karpathy:
Personal update: I've joined Anthropic.
https://x.com/karpathy/status/2056753169888334312

https://quality-lab.ru/blog/kakie-zadachi-v-testirovanii-pora-otdat-ii-chtoby-poluchit-rezultat-a-ne-novye-problemy/

Вязанный бабушкой енот в деле

Доброго ранку,
Запрошую тебе сьогодні о 20:00 у Сувору QA ком'юніті на панельну дискусію «Ми всі тепер АІ-експерти. Чи ні?»

AI вже всюди: у роботі, в побуті, в резюме, у вакансіях, у чатах, у задачах і, здається, навіть у місцях, де його ніхто не очікував.

Тому ми вирішили зібрати панельну дискусію і поговорити про те, що зараз відбувається з AI в IT та навколо нього.

Разом із запрошеними експертами обговоримо:
- які AI-тренди зараз справді варті уваги;
- що робити, коли AI вже всюди;
- як ефективно використовувати AI у роботі;
- де AI реально допомагає, а де заважає;
- як змінюється роль спеціалістів у командах;
- і чи всі ми тепер справді АІ-експерти, чи просто дуже стараємось такими виглядати 😄

Ведучий панельної дискусії: Костянтин Телтов, QA Team Lead / SDET

Запрошені експерти:
▶️ Євген Пасєка, QA Manager у SQUAD
▶️ Марина Дідковська, Senior Director, Quality Architecture at EPAM Systems
▶️ Олексій Іващенко, QA Team Lead в TheyDo
▶️ Анна Величко, Senior Software Engineer in Test

Усі наші експерти не просто говорять про AI, а вже активно впроваджують його у своїх компаніях та командах.

Приєднуйся, щоб дізнатись, як це працює на практиці, з чого почати і як використати цей досвід саме у своїй роботі.

📅 Коли: 25 червня, 20:00
🎟 Квитки тут (50% вартості квитка йде на ЗСУ)
🔴 Запис буде

1. Впихнуть своё резюме в chatGPT с запросом:

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

2. Читать ответ.

Понимать, что, собственно, именно так твоё замечательное резюме воспринимают наши славные Неизвестные отцы-рекрутеры — злобно и безжалостно трезво. А современные системы отпинывания кандидатов от компании (ATS) как раз и делают краткие саммари по всем резюме, которые ещё не были автоматически перемещены в газенваген. Ну и вот.

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

«Для человека, который позиционирует себя как тренер по QA и свободно владеет английским:

consalter
appications
Roumanian
re￾quirements (артефакт PDF)
M ay

Часть — ошибки OCR, но часть присутствует именно в тексте».

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

А дальше ВНЕЗАПНО очень плохое:

Рекомендация от последнего работодателя вызывает вопросы

Подписана CTO. Однако письмо выглядит необычно:

нет фирменного бланка;
нет логотипа;
нет адреса компании;
только текст и email.

Рекомендация выглядит слабее, чем должность. Для Team Lead обычно пишут про:

руководство людьми;
принятие решений;
влияние на процессы;
достижения команды.

Здесь ничего подобного нет. Само по себе это ничего не доказывает, но подлинность желательно проверить.

Ну ёптыть, какой pdf дали, такой и использую… Но кто будет разбираться?

Ок, рекомендуется эту рекомендацию удалить. Удалил.

Дальше вообще ой:

Вторая рекомендация подтверждает работу в Astound Commerce до 2020 года.

Она не подтверждает:

работу в криптоплатформе;
работу Team Lead;
нынешний консалтинг.

Так стоп! (© КВН) В Astound Commerce всего этого и не было, это всё было ПОСЛЕ. Но кто будет разбираться?

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

Наиболее объективно проверяются:

* действительно ли человек работал Team Lead;
* действительно ли письмо подписал указанный CTO;
* существовала ли указанная должность именно в этот период;
* подтверждается ли опыт в LinkedIn, GitHub, конференциях, публикациях и других независимых источниках.

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

А если бы моё резюме было безусловно-прекрасным, отвечающим на все вопросы до того, как их задали, то и его кинут фтопку, потому что слишком всё прекрасно, ненатурально, а значит, это мошеннический фрод, Фродо!

https://youtu.be/WdbqPK2Bof4?si=GH5e1YkRQCXBJI-K&t=50

Вкратце цитата из https://t.me/RakovskyXP/153:

Есть такая широко известная в узких кругах [широких] тестировщиков Элизабет Хендриксон.

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

- Зачем ты выдумываешь новый функционал?!

- Что значит, новый функционал? Это же недоработка, баг.

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

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

Всегда так было и всегда так будет.

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

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

Например, вот у нас на этаже аж 70 тестировщиков, и хотя все они тестируют отдельные направления одного и того же проекта, они то и дело сообщают о багах, которые «не по сценарию», а также разными словами настырно сообщают об одних и тех же проблемах.

А на стороне заказчика программисты сидят (например, в Шри-Ланке) и злобно отпинывают всё, что «не по требованиям», потому что им за баги не просто втыкивают втык, а их ещё и наказывают штрафами.

А архитекторы смыслов на стороне заказчика сидят в (тогда ещё не знавших налета самолетов) башнях международного торгового центра в NY, бесконечно фигачат новые требования и сильно нервничают, когда им приходится по семь раз в день читать разные баг-репорты всё об одном и том же, и особенно сильно говорят вслух, что «ДА ТВОЙ КРОЛИК ПИШЕТ!», когда к ним прилетают баги, найденные по непредусмотренному сценарию.

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

Элизабет попала в промежуточное состояние — когда команда небольшая, всяческие предложения об улучшении приветствуются, но разработка всё сильнее переходит на рельсы «Мы договорились сделать так, и сделали именно так», потому что у них стала важнее стабильность и воспроизводимость работы всего проекта, нежели глобальное «А давайте добавим Bluetooth, станет удобнее!» или вроде бы адекватное «Данные приходят корректно, но есть лишнее поле; хорошо было бы его не передавать…» А давайте не надо нам делать отдельную петлю проверки наличия отсутствия отдельного поля…

Хочется однозначности, но…

Про почкование

Слышал как-то одну прикольную историю от Дейва Томаса. Одна команда в огромной американской конторе топила за XP. Им от нечего делать сунули проект, который полтора года никак не мог сдвинуться с мёртвой точки. Они сдали его за месяц. Начальник мрачно офигел и пошёл выяснять, как это они так. Они говорят: ну, тесты, рефакторинг, парное программирование, все такое. Начальник: отлично, научите этому всю компанию. А они ему: нет, Дед Мороз, погоди.

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

Всю компанию так не перевернули, но здоровенный кусок организации переехал на XP.

Моя история

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

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

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

Осталась с нами и схема. Любой новичок первые несколько недель сидит в паре с носителем и пишет боевой код.

К чему это всё

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

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