Тестировщики из Авито запустили подкаст — и у них есть что сказать
«Не воспроизводится» ведут Оля Шнайдер и Сережа Атрощенков — практикующие QA-инженеры, которые каждый день работают с тем, о чём собираются говорить. В выпусках они разбирают реальные темы мира тестирования: ручное и автоматизированное тестирование, работа с ИИ, карьерный рост, отношения с командой, work-life balance — и всё, что обычно остаётся за закрытыми дверями ретро.
Идея простая: дать инженерам место, где можно честно обсудить профессию. Чтобы каждый знал, что он не один.
🎧 Слушайте выпуски подкаста на всех подкаст-платформах:
💬 Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».
Добро пожаловать в мир тестирования. Баги прилагаются.
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, и видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
Открытый сетевой инструмент Deep Eye может автономно искать уязвимости и проводить тесты на проникновение в исследовательских целях. Проект использует нейросети, которые коллективно ищут уязвимости на выбранном ресурсе и пытаются проводить различные тесты. Решение поддерживает 45 методов и атак. Алгоритмы системы собирают всю информацию о сайте, включая поддомены и DNS.
Представлен ресурс для тестировщиков с различными сервисами для автоматизации в одном месте: конверторы, json валидаторы, генераторы uuid и ещё десятки приятных мелочей.
1 апреля 19:00 Собеседование с умом: секреты успешного подбора QA-талантов Погрузимся в секреты успешного подбора талантов, изучим эффективные техники интервьюирования и разберем, как выявить не только технические навыки кандидата, но и его личные качества, которые могут стать залогом успешной работы в QA команде.
2 апреля 20:00 Поиск работы JS-автотестером в 2026 году: как выделиться на рынке работодателя Разберём, как изменилась ситуация на рынке труда для JS-автотестеров в 2026 году и какие стратегии действительно работают при поиске работы. Поговорим о том, как адаптировать резюме под разные рынки, на что обращают внимание HR и технические интервьюеры, и как повысить свои шансы получить оффер.
7 апреля 20:00 Модульное (unit) тестирование в 1С Познакомимся с современными инструментами модульного тестирования. Разберем несколько «неудобных» для тестирования примеров. А также научимся автоматизировать запуск тестов.
14 апреля 20:00 Внедрение автотестирования с участием искусственного интеллекта Этот урок — практическое руководство для тех, кто хочет выстроить устойчивую стратегию авто-тестирования, а не просто «добавить тесты». Мы отдельно разберем, как использовать ии-инструменты в автотестах: где они реально помогают, а где создают иллюзию эффективности.
16 апреля 20:00 ИИ для тестировщика: инструменты, которые уже меняют профессию Разберём, какое место ИИ занимает в работе тестировщика сегодня, какие инструменты действительно помогают ускорять работу и повышать качество, а какие остаются маркетинговым шумом. Узнаем, как ИИ может стать ассистентом QA-инженера в ручном и автоматизированном тестировании.
Онлайн инструменты для тестировщиков без регистрации и смс
Каждый тестировщик (как мне кажется) каждый день в своей работе использует генераторы uuid, конвертеры, регулярные выражения и json валидаторы. И если у нас нет самописных скриптов, то где то в закладках есть любимый инструмент (обычно разный для каждого из этих действий)
Я решил собрать все в одном месте. Ничего революционного, просто удобно, когда не нужно прыгать по вкладкам. Есть и валидация JSON по схеме, и разбор JWT, и ещё куча мелочей, которые в работе всплывают постоянно.
Пару лет назад мы с коллегами из CyberYozh решили создать курс по этичному хакингу. Все как положено: детальная программа, план, маркетинг, свет, аппаратура, даже футболки подготовили соответствующие! Однако на деле все оказалось намного сложнее, чем это кажется со стороны.
Первое и самое сложное — это съемки. Иногда, для того чтобы записать 5-тиминутное видео, у меня уходило по 4 часа. И я сейчас не говорю про человека‑соседа, решившего повесить полку именно в момент съемки. Это и забывчивость подготовленного текста, Эканья и Аканья, почесывания, сбой в ПО при презентации экрана и банальная усталость от сидения на табуретке (именно табуретке, так как спинка стула мешает в кадре). А так как режиссер требует все записывать «одним дублем», иногда приходилось раз 20 перезаписывать 10-ти минутное видео с самого начала.
Второе, бумажная бюрократия. Так как планировался большой проект, мы привлекли маркетологов и технологов. Но только те вместо того, чтобы помогать нам в работе, наоборот, делали жизнь тяжелее.
Технологи начали требовать от нас составления плана на каждое видео: какие цели мы ставим перед уроком, какими задачами мы их достигнем и чему в итоге научится студент, посмотрев видео‑урок (что делали сами технологи, кроме как указывать нам на это, мы так и не поняли). Более того, это нужно проговаривать в начале каждого видео, и в конце повторяться и подводить итог, чему же все‑таки научились студенты.
А маркетологи настаивали, чтобы я говорил, какая это актуальная профессия, что по ней много не закрытых вакансий и что такие специалисты зарабатывают неприлично МНОГО, поэтому они срочно должны записываться на наш курс.
Ну и меньшее из зол, это неудобство исполнения. С учетом того, что я записывался в квартире, это накладывало свои особенности взаимоотношений с родными. Одна из комнат была постоянно занята, так как был развернут хромакей 2×2 метра, дополнительный свет, камера, микрофон, а заниматься постоянной сборкой‑разборкой такой конструкции то еще занятие. Кроме того, семья и человек‑сосед должны находиться в тишине, чтобы не было шума на фоне, а с учетом наличия детей — это просто нереально.
В общем, с горем пополам мы записали пару пилотных уроков, но потом решили завершить начинание. Это очень большой и тяжелый труд, который требует много сил. И это я еще не говорю про само содержание курса, которое должно быть качественным, актуальным и конкурентноспособным. А с учетом планов маркетологов по выпуску 2–3 уроков в неделю, это было более чем призрачно.
Какие выводы я сделал для себя? Во‑первых, несмотря на такой опыт, я все еще люблю преподавать, только исключительно в оффлайн формате: при прямом взаимодействии и живым общением со студентами. Во‑вторых, вопреки популярному мнению, что блогеры ничего не делают и только снимают свои дурацкие видео, это очень большая и тяжелая работа: если делать качественно и вдумчиво, то, как я и сказал выше, процесс записи может занимать очень долгое время и требовать больших физических усилий.
Прилагаемое видео — один из демо видеоуроков, который мы записали и смонтировали. Понимаю, что не у всех есть возможность посмотреть в YouTube, поэтому я залил видео во 📺 ВКонтакте. Желаю приятного просмотра.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
За пару-тройку месяцев пристрастился к публикациям на Хабр. И, чтобы это не превращать эту новую привычку в пустое графоманство, решил сфокусироваться и прикинуть в этом посте темы для следующих публикаций:
Как судить песни на онлайн-турнирах в числах?
Функция Cover в Suno для возведения нашего творчества в степень
Типовые баги в русской фонетике относительно песнен из Suno
Публикуем музыкальный альбом через сервис дистрибьютора
Что почитать начинающим тестировщикам: 6 материалов для погружения в тестирование
Привет, Хабр! Мы приготовили подборку, которая поможет глубже погрузиться в тестирование. Внутри — обзоры профессиональной литературы, популярных инструментов и библиотек, а также советы от команды Selectel. Бонус — бесплатный курс по мобильному тестированию от опытных тестировщиков.
Android-эмуляторов — десятки. Чтобы вам было проще выбрать, мы сравнили восемь популярных решений. Разобрали особенности каждого и объяснили, для каких задач они подходят.
Мобильное тестирование — это не просто «веб в миниатюре», а отдельный мир со своей архитектурой, устройствами, операционными системами и ограничениями. В статье рассказали об особенностях мобильных платформ, с которыми тестировщики сталкиваются на практике.
Бесплатный курс от экспертов Selectel, Ozon, Спортс" и не только. Он подходит как новичкам, так и практикующим тестировщикам, которые хотят систематизировать знания. На начало марта доступна первая часть курса, но совсем скоро появится и вторая.
Тестирование — кропотливый труд, особенно для начинающих специалистов. Но задачу можно упростить, если прокачать знания и внедрить подходящие инструменты.
Мало стартового набора? Держите дополнительную порцию интерактивных тренажеров, баз знаний, книг и курсов — проверенных ресурсов, к которым можно возвращаться в любой момент.
Если вы устали от бесконечных циклов «получить приложение → найти баг → отправить на доработку → повторить», предложите команде AI-инструменты для прототипирования. В статье рассказали, как мы используем этот подход.
44 собеса за месяца — Жив ли рынок QA/AQA на самом деле?
Календарь AQA собесов за декабрь
Последний год в IT регулярно обсуждают одну и ту же тему — рынок стал сложнее. Вакансий меньше, требования выросли, конкуренция усилилась.
Особенно часто это можно услышать от специалистов из QA/AQA: Мол, тестирование переполнено, вакансий мало, а найти новую работу стало почти нереально.
Я давно консультирую ребят в сфере QA и автоматизации тестирования (AQA) и регулярно наблюдаю, как специалисты выходят на рынок. Поэтому иногда вижу довольно наглядные примеры того, как ситуация выглядит на практике.
Как раз недавно один из ребят показал в нашем чатике свой календарь собеседований за декабрь — этот календарь приложил выше.
И, честно говоря, даже меня это немного удивило. За месяц у него набралось 44 собеседования.
Причём: Во-первых, всё это происходило параллельно с основной работой. Человек не уходил в отпуск и не ставил поиск работы на полный день — все интервью проходили между рабочими задачами.
Во-вторых, это был декабрь. Если смотреть на рынок найма в IT, конец года традиционно считается не самым активным периодом: компании закрывают бюджеты, команды уходят в отпуска, процессы замедляются.
Тем не менее календарь получился очень плотным.
Иногда у него было по несколько интервью в день: HR, технички, финалки, снова HR.
А если представить его лицо 11го декабря — то лучше не надо)
P.S. Выходил на рынок он как Fullstack QA/AQA, если что. В ручном тестировании естественно ситуация похуже. Но наверное основной моей задачей и являлось помочь ему с этим переходом (QA->AQA), т.к. именно тут наилучшая конверсия для QA.
И что по итогу? Оправдались ли такие усилия?
Думаю, всем это тоже будет интересно. Стоило ли оно вообще того.
Вы реально думаете, что человек, который проходил по 6 собесов в день, мог не добиться своего?)
Всё-таки в подобной ситуации очень быстро прокачиваются навыки интервью. С каждым новым собеседованием ответы становятся точнее, технические вопросы разбираются быстрее, а уверенность растёт.
В итоге этот кандидат получил 6 офферов.
Один из них оказался особенно сильным — около 490 000 рублей gross для позиции в автоматизации тестирования.
На мой взгляд, это хороший пример того, как сейчас устроен рынок.
Да, он действительно стал сложнее. Да, требования выросли.
Но при этом рынок далеко не мёртв. Он просто стал требовательнее к кандидатам.
Те, кто активно выходят на рынок, много собеседуются, анализируют обратную связь и продолжают двигаться дальше — как правило, всё равно получают результат.
А те, кто не пытается, чаще находят объяснение, почему сейчас «не время».
Поэтому, когда в очередной раз услышите, что рынок QA/AQA окончательно умер, просто вспомните календарь из 44 собеседований за один месяц.
Спасибо, что дочитали пост до конца! Надеюсь, смог зарядить вас мотивацией, это была моя основная цель 🙂
В комментариях готов подискутировать на эту и смежные темы! Ну а в своем блоге Telegram также пишу про тестирование и автоматизацию, иногда затрагивая и общие темы развития в сфере IT. Всегда рад новым читателям!)
Уничтожаем враньё в ответах СhatGPT. Представлен промпт для нейронки, чтобы она перестала врать, придумывать, мудрить, выбрасывать несуществующие факты и цитаты, а также галлюцинировать. В промпте учтено всё, что должна делать нейронка, и что не должна исполнять во время работы. Нужно перейти в «Настройки» → «Пользовательские инструкции» и добавить туда этот текст:
СЛЕДУЙ ЭТОМУ СТИЛЮ ПИСЬМА: ДОЛЖЕН всегда говорить правду. Никогда не выдумывать информацию, не строить предположения и не гадать. ДОЛЖЕН основывать все утверждения на проверяемых, фактических и актуальных источниках. ДОЛЖЕН чётко указывать источник для каждого утверждения прозрачным способом, без расплывчатых ссылок. ДОЛЖЕН прямо сказать «Я не могу это подтвердить», если что-то нельзя верифицировать. ДОЛЖЕН ставить точность выше скорости. При необходимости предпринимать шаги для проверки перед ответом. ДОЛЖЕН сохранять объективность. Убирать личные предвзятости, допущения и мнения — если только они не запрошены явно и не помечены как мнение. ДОЛЖЕН давать интерпретации только тогда, когда они подтверждаются надёжными, авторитетными источниками. ДОЛЖЕН объяснять ход рассуждений пошагово, когда точность ответа может быть поставлена под сомнение. ДОЛЖЕН показывать, как была получена любая числовая величина (как рассчитана или из какого источника взята). ДОЛЖЕН излагать информацию ясно, чтобы пользователь мог проверить её самостоятельно. ТЫ ОБЯЗАН ИЗБЕГАТЬ: ИЗБЕГАЙ фабрикации фактов, цитат или данных. ИЗБЕГАЙ использования устаревших или ненадёжных источников. ИЗБЕГАЙ отсутствия деталей об источнике для любого утверждения. ИЗБЕГАЙ подачи предположений, слухов или догадок как фактов. ИЗБЕГАЙ «ИИ-ссылок», которые не ведут на реальный, проверяемый контент. ИЗБЕГАЙ ответа при неуверенности, не обозначив эту неуверенность. ФИНАЛЬНЫЙ СТРАХОВОЧНЫЙ ШАГ (ПЕРЕД ОТВЕТОМ): «Каждое ли утверждение в моем ответе проверяемо подкреплено реальными и авторитетными источниками, и снабжено прозрачными ссылками? Если нет — перепиши ответ, пока это не будет выполнено».
Русский FAANG: карьерный буст или выгорание за 400к? Что выбрать QA/AQA
В русском IT регулярно всплывает формулировка «русский FAANG» и многие хотят туда попасть. В этом посте на основе своего опыта разберу, стоит ли оно того.
Начнем с того, что каждый под словосочетанием русский FAANG подразумевает разное. Есть как минимум: 1. ВАСЯ: ВК, Альфа, Сбер, Яндекс 2. МЯСОВАТА: Mail (VK), Яндекс, Сбер, Озон, Валдберрис, Авито, Теле2, Альфа 3. Мой любимый - ОБОСРАЛСЯ: Озон, Билайн, ОККО, Сбер, Рамблер, Атол, ЛамодаТех, Совкомбанк, Яндекс
В целом есть множество различных вариаций и аббревиатур, но нет одной единственно правильной. Почему - везде есть свои проблемы и преимущества. Всё в большей степени зависит от проекта. Внутри одной и той же компании может быть и круто, и очень плохо. Поэтому и нет четкого списка "топ компаний", все оценивают по разным критериям.
Так стоит ли QA/AQA и другим стремится в ВАСЯ или можно ограничится ОБОСРАЛСЯ или даже обычными мелкими компаниями / стартапами?
Чего стоит попасть туда (насколько это сложно)
У многих есть ощущение, что российский бигтех - это нечто недосягаемое. Почти как западный FAANG.
Если говорить про автоматизацию тестирования и смежные роли, картина выглядит иначе. Я скажу больше, выходя на рынок как AQA - вы с большей долей вероятности попадете именно в бигтех.
Автоматизация сегодня - одна из самых востребованных зон в крупных компаниях. Большой продукт, частые релизы, много интеграций - без автотестов это сложно поддерживать.
Плюс последние годы усилили тренд на оптимизацию затрат. Ручное тестирование постепенно сокращается, а автоматизация растет. Считается, что один AQA может закрывать задачи нескольких QA.
Поэтому спрос на автоматизаторов в бигтехе стабильно высокий. И в этом смысле двери туда открыты куда шире, чем кажется со стороны.
Где лучше и стоит ли оно того
Я поработал много где как AQA - Ozon, WB, VK, несколько российских и западных стартапов, бигтех US. И могу с уверенностью сказать, что тут не угадаешь, везде всё по разному. Например, в одном из криптостартапов я встретил лучшие процессы, что видел в жизни, а в двух из бигтехов - миллион токсиков, невероятную бюрократию и в целом не очень классные процессы.
Поэтому мое личное мнение - умирать ради работы в конкретной компании вообще того не стоит.
Проекты могут быть плохие и хорошие как в бигтехах, так и в мелких компаниях. Да, в бигтехах часто процессы получше, но это далеко не всегда так. Ну а хороший оффер могут дать и там, и там.
В общем, тут стоит выбирать по сумме условий и не руководствоваться именем компании, т.к. оно часто ничего не значит.
Те же самые "интересные задачи" есть везде, а в стартапах они часто даже круче и челленджовее.
Что в сухом остатке
При прочих равных условиях кроме записи в резюме работа в бигтехе не дает ровным счетом ничего. Везде всё по разному и может оказаться так, что в стартапе проект будет в миллион раз лучше по всем параметрам. Ну а строчку в резюме всегда можно придумать, если так уж хочется.
Всем спасибо за внимание! В комментариях готов подискутировать на эту и смежные темы! В своем блоге Telegram также пишу про тестирование и автоматизацию, ну и в целом про карьеру в сфере IT. Всегда рад новым читателям!)
Вышел наш новый подкаст #Криптонит_говорит про тестирование! Мы обсудили тренды профессии, поговорили об образовании в этой сфере и узнали, почему разрыв между разработкой и тестированием сокращается (и так будет и дальше).
Смотрите и слушайте выпуск на любой удобной платформе:
Недавно общался с крупной зарубежной продуктовой компанией. Штат 500–1000 человек, вроде зрелые процессы, ЗП у разрабов 5000€ баг-репорты по ISO/IEC/IEEE 29119. И при этом:
«Не успеваем уделять время автотестам. Сфокусированы на скорости разработки и релизах.»
Что меня зацепило — каждый их аргумент против тестов я интерпретировал как аргумент за:
— «Слишком частые релизы» → А не потому ли они такие частые, что баги проскакивают на прод?
— «Требования постоянно меняются» → Тем более — как вы контролируете, что старое не ломается?
— «И так работают наизнос если еще и тесты заставить писать — выгорят» → А не от бесконечного ли футбола с багами они выгорают?
А как у вас? Есть автотесты на проекте? Или тоже «не до них»?
Приглашаем тестировщиков на митап. Вместе с Moscow QA подготовили три ярких доклада:
Помогите, flaky!
Екатерина Лахтина, тимлид QA UGC в 2ГИС, поделится подходом, который помогает находить и устранять flaky‑тесты, снижать ручную работу и добавлять автоматизацию.
Как прокачать автотесты с 0 до keyword-driven
Анастасия Нестерова, QA Engineer, расскажет, какие методы пробовали, где спотыкались и как в итоге выстроили процесс на стеке Playwright + TypeScript.
Вайб‑кодинг в тестировании с позиции менеджера
Виктория Дежкина, менеджер направления, поделится плюсами и минусами нового подхода в тестировании: как влияет на команду, какие есть риски и стоит ли вообще пробовать.
Представлен открытый проект AI uBlock Origin Blacklist. Это список для блокировки uBlock Origin сайтов, использующих ИИ в качестве источника контента.
«Во время просмотра веб‑страниц я иногда, довольно часто, натыкаюсь на сайты, текст на которых написан генеративным ИИ. Эти сайты не предоставляют полезной информации, имеют посредственный контент и переполнены рекламой и реферальными ссылками для заработка денег. Поэтому, когда я нахожу такие сайты, я добавляю их сюда. Ключевая идея проста: если бы я хотел, чтобы на мой вопрос ответил ИИ, я бы спросил ИИ. Если я ищу информацию в интернете, это означает, что я хочу получить ответ от человека. У человека есть опыт, мнения, идеи, креативность и много другой информации, которой он, возможно, захочет поделиться с интернетом. У ИИ этого нет. Более того, контент, созданный ИИ, может быть опасным: статьи на сайтах, созданных ИИ, не проверяются никем перед публикацией, поскольку они генерируются массово. ИИ может испытывать галлюцинации», — пояснил автор проекта.
На рынке сейчас царит жуткая путаница между совершенно разными AI-QA-ролями. Получилось так, что я прошла через все три роли. Если вы планируете карьерный переход, то вот в чем разница между ними:
1️⃣ QA Engineer с инструментами ИИ Цель: Эффективность. Реальность: Вы тестируете традиционный детерминированный продукт. Вы просто используете ChatGPT для генерации тест-кейсов или Cursor/Claude Code для автоматизации. Это «вайб-кодинг» для старых добрых задач.
2️⃣ AI QA Engineer Цель: Базовая проверка интеграции. Реальность: Тестирование того, как чат с LLM работает внутри условной CRM-системы. Вы проверяете, вежлив ли бот и не «поехал» ли интерфейс. Вы всё ещё используете ассерты (asserts), просто с небольшим «привкусом» нейросетей.
3️⃣ ML Evaluation Engineer (Инженер по оценке ML-моделей) Цель: Управление хаосом в недетерминированных моделях. Реальность: Вы не используете ассерты; вы используете статистические метрики. Инструменты: Фреймворки для оценки (например, LM Evaluation Harness), модули метрик на Python.
Почему третий вариант — это совсем другое:
Вероятность > Детерминизм: Вы не проверяете, что . Вы проверяете, является ли показатель метрики 0.87 приемлемым для вашего конкретного сценария.
Стоимость как метрика: В ML Eval затраты токенов так же важны, как задержка (latency). Если ваш агент «умный», но стоит $2 за запрос — вы провалили тест.
Скорость решает всё: Здесь быстрая 7B-модель может выиграть у медленной 70B. Тестирование производительности здесь не «доп. опция», а база.
Русский хакер взломал почту президента Соединенных Штатов Америки Дональда Трампа!
Так могла бы быть озаглавлена статья в каком-нибудь новостном агрегаторе, но, конечно же, это далеко от истины, хотя письма от его имени (с домена POTUS*) я все же могу отправлять. Как такое могло произойти давайте разберем под катом.
Одним из самых распространенных методов обмана людей была и остается рассылка по электронной почте. Еще до индусских колл-центров и служб безопасности банков, в начале нулевых главным средством выманивания денег были африканские e-mail'ы, которые с сожалением сообщали о кончине вашего родственника, но завещавшего вам пару десятков миллионов долларов 🇷🇺.
Со временем, специалисты по ИБ разработали антифишинговые механизмы и ПО, которые блокировали входящую почту по распространенным паттернам, включая подозрительные слова. Именно поэтому, если вы вдруг не знали, фишинговые письма содержат грамматические ошибки - банально чтобы обойти защитные механизмы. Однако сейчас не об этом.
Главными критериями определения легальности письма являются 2 доменные записи: SPF и DMARС (есть еще DKIM, который отвечает за цифровую подпись писем, но о нем как-нибудь в другой раз). Sender Policy Framework aka SPF — это запись со списком серверов и IP-адресов, с которых разрешается рассылать письма от имени домена. Если письмо пришло с отличного от записанного в SPF айпишника или домена - письмо помечается как подозрительное. Domain-based Message Authentication, Reporting and Conformance aka DMARC — это политика, которая задаёт сценарий действий с письмами, которые признаны через SPF подозрительными: none - ничего не делать, quarantin - пропускать, но поместить в папку спам, и reject - отклонять.
Соответственно, если у домена в DNS не прописаны SPF и DMARС, то принимаемый mail-сервер не может проверить легальность отправления и не понимает, что с ним делать дальше кроме как пропустить. Так и случилось в текущем примере: коммерческий домен POTUS.com не имеет соответствующей записи DMARC и любой желающий может отправлять письма от его имени, включая якобы действующего президента 🇺🇸 США.
К счастью, большие почтовые корпорации типа 📧 Google и ❤️ Яндекс, даже при отсутствии или неправильной конфигурации SPF и DMARC, научились отличать фишинг от реального письма. Однако ряд других почтовиков (не будем показывать пальцем) не только пропускают такие письма, но еще и подставляют аватарки (на основе фавиконки с домена), а под письмом пишут, что оно проверено "докторским" антивирусом.
Как же установить, что проверяемый домен подвержен такой атаке? Ранее я пользовался встроенной в Kali утилитой под названием spoofcheck (проверка на спуффинг), но она просто проверяет DNS записи и говорит возможно ли заспуфить проверяемый домен или нет. Поэтому около года назад я сделал свою утилиту 🧠 HydrAttack PoC eMailSpoofer Module, которая проверяет домен на уязвимость (чекает DNS записи), и если так оно и есть - поднимается майл сервер со всеми необходимыми настройками и отправляется спуффинговое письмо. Особенностью моего ПО является то, что в письмо вложен Excel файл с макросом, который открывает калькулятор.
В общем, за год эксплуатации моя утилита показала свою работоспособность в боевых условиях: и на реальных проектах дала жару, и в рамках Баг Баунти программ от Bi.Zone я также заработал пару тысяч. Поэтому пользуйтесь, но помните, что с большой силой приходит и большая ответственность (с).
Почему хороший тестировщик — это не тот, кто нашел больше всего багов
В тестировании легко попасть в простую ловушку — начать измерять свою ценность количеством найденных багов. Чем больше тикетов, тем полезнее работа. На первый взгляд логика кажется железной.
На практике все сложнее. И чем опытнее становится тестировщик, тем реже он гордится просто цифрами.
Количество багов ничего не говорит само по себе
Сто найденных дефектов могут означать две совершенно разные вещи:
продукт реально нестабилен;
тестирование началось слишком поздно.
Если баги находятся пачками в самом конце разработки, это не успех, а симптом. Хороший тестировщик старается сделать так, чтобы часть проблем не доходила до баг-трекера вообще.
Сильный тестировщик думает раньше, чем тестирует
Тестирование начинается не с чек-листов и не с автотестов. Оно начинается с вопросов.
что здесь может пойти не так;
где система уже ломалась;
какие изменения самые рискованные.
Человек, который подключается к обсуждению требований и дизайна, часто предотвращает больше дефектов, чем тот, кто просто проверяет готовую фичу.
Баг-репорт — это не обвинение
Новички иногда воспринимают баг как доказательство чьей-то ошибки. Отсюда агрессивные формулировки и желание «поймать» разработчика.
Опытный тестировщик понимает — баг-репорт это способ помочь команде. Хорошее описание проблемы экономит время всем:
понятно, что сломалось;
понятно, как воспроизвести;
понятно, почему это важно.
Чем меньше эмоций и больше контекста — тем лучше работает процесс.
Автотесты — это не самоцель
Автоматизация часто превращается в гонку — у кого больше тестов, у кого выше покрытие. Но цифры сами по себе ничего не гарантируют.
Хороший тестировщик задает другие вопросы:
ловят ли эти тесты реальные проблемы;
можно ли им доверять;
не мешают ли они менять код.
Иногда удаление десятка бесполезных автотестов приносит больше пользы, чем написание сотни новых.
Хороший тестировщик думает о пользователе, а не о сценарии
Чек-листы и тест-кейсы важны, но реальный пользователь почти никогда не действует по ним.
Он кликает не туда, вводит странные данные, прерывает процессы и возвращается позже. Умение выйти за рамки сценариев отличает опытного тестировщика от формального.
Качество — это ответственность всей команды
Одна из самых токсичных идей в тестировании — что за качество отвечает только QA. Это удобно, но не работает.
Сильный тестировщик не берет качество на себя полностью. Он помогает команде видеть риски, объясняет последствия и участвует в решениях. Но ответственность остается общей.
Карьерный рост в тестировании — это не про инструменты
Инструменты меняются быстро. Сегодня один фреймворк, завтра другой. Знание конкретного тулкита редко определяет уровень специалиста.
Гораздо важнее:
умение анализировать систему;
понимание, где искать проблемы;
способность говорить с разработчиками и бизнесом на одном языке.
Именно это делает тестировщика ценным, а не список технологий в резюме.
В итоге
Хороший тестировщик — это не тот, кто нашел больше всего багов. Это тот, кто:
помогает находить проблемы раньше;
думает о рисках, а не о галочках;
пишет понятные баг-репорты;
работает с командой, а не против нее.
Такие люди редко кричат о своих результатах. Но именно благодаря им продукт перестает ломаться в самых неожиданных местах.
. Вы проверяете, является ли показатель метрики 0.87 приемлемым для вашего конкретного сценария.
