Сегодня PayPal решил мне прислать запрос на подтверждение личности. Свежий документ личности и подтверждение адреса.

Иду по процессу - закачал 1й док, все ок; закачал 2й - ошибка. Смотрю в чем косяк и оказывается, что у них требование - файл должен быть от 30кб до 10мб. А мне банк сгенерил выписку на 27кб 🙈

Почему от 30кб - хз, требование немного странное. Видимо чтобы отфильтровать пустые файлы, но тогда можно было бы и 10кб поставить 🤪

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

#qa #pro_qa #paypal #багивокругнас #funny_ux

"Типичная тяпница менеджера".

Особо цинично то, что она по идее должна быть "No-Meeting Friday" - но пока просто не до того 🤪

Ну, кто-то тут все ещё хочет в QA директора, менеджеры или лиды? Приходите на менторинг, расскажу всю правду-матку 😎

PS. Только грамотный тайм-менеджмент спасёт вас/нас от выгорания!

#qa #pro_qa #qa_lead #test_manager #time_management

Получил сертификат за активное участие в программе Mentor in Tech 6.0 от Women in Tech Russia с октября 2024 по февраль 2026 🎉

#qa #pro_qa #wit #women_in_tech #mentor_in_tech #ментор

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

Сейчас время появилось, так что в планах:
- продолжить с темами по тест-дизайну
- написать про 2 свободных места на менторство/сопровождение
- сюда же расписать про рабочие кейсы, тк оказывается что очевидные для меня вещи многим непонятны (ну это стандартный кейс, надо писать и рассказывать больше)
- снова вернуться к программе бесплатных консультаций #qa_mentoring_free
- несколько статей на тему AI в тестировании
- возможно будет несколько вакансий для ручников/автоматизаторов из дружественных проектов (удаленка, любая локация, рубли/валюта, отличные соц.пакет/команда)

#qa #pro_qa

Приглашаю всех на бесплатную конфу от OTUS.
Java, JavaScript или Python: что лучше для автоматизации тестирования

Как тестирование «открывает двери» IT? Какие языки программирования и какие инструменты используют ведущие компании для автоматизации? Вас ждёт жаркая дискуссия с разбором языков для тестирования, демонстрацией тестов UI и API, интересными примерами из практики.
Готовы сделать следующий шаг в карьере?

Присоединяйтесь!
20 февраля | 19:00 МСК

Записаться на конференцию

#qa #pro_qa #otus #automation #java #js #python #qa_обучение #qa_conf

Вопрос, который беспокоит многих рекрутеров и нанимающих менеджеров: как определить, что кандидат использует AI/LLM при ответах на вопросы?

Раньше было про то, что кандидат гуглит ответы.

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

Совсем треш с подменой, когда вместо одного кандидата устраивается другой, не рассматриваем 🤪

Я не задаю вопросов, на которые есть один вариант ответа.

Начинаю с простого вопроса:
Что происходит после того как в строке браузера ввели адрес и нажали Enter?

Даже если его задать ChatGPT с/без deep research, то ответ будет с тех.деталями, но далеко не полный 🤣

На моей практике за последние пару лет полный ответ с точки зрения процесса, а не тех.деталей дали всего 2 кандидата среди нескольких сотен.

Затем я задаю вопрос
«Обычный рабочий день, тебе прилетает задача в джире, (описание задачи), расскажи что ты будешь делать и почему?»

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

А по ходу дела наводящие и уточняющие вопросы.

При этом по видео еще язык тела считываю, мимика и движение глаз.

И тут даже подсказка от эксперта в наушник (а такие кейсы встречаются) не очень поможет 😎

#qa #pro_qa #qa_собес #ai #llm #chatgpt

На прошлой неделе выступал на круглом столе 13-го сезона Podlodka QA Crew про Quality Gates. Тема очень актуальная для тех кто выстраивает QA процессы, так что те кто не успел сходить на конфу могут приобрести доступ ко всем докладам, а полезностей там хватает и доклады были интересные.

#qa #pro_qa #conf #podlodka #podlodka_qa_crew #quality_gates #ментор

Попробовал пару дней назад ChatGPT 4.5 + Deep research на тему написания тестовой документации по QA процессам и обоснования внедрения тех или иных процессов бизнесу 🙈

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

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

Если говорить про цифры, то такой запрос/ответ экономит порядка 1-2 дней работы и это здорово! Если кто-то до сих пор не начал использовать такое подспорье - поторопитесь! 😎

Но пока ни о какой полноценной замене на текущий момент быть не может, зато в плане сбора/анализа/систематизации данных, с которыми затем можно работать - очень достойный результат.

#qa #pro_qa #chatgpt #ai

На одном проекте заказчику очень сильно хотелось автоматизацию, причем не абы какую, а скриншот-тестирование, тк казалось, что "это решит все проблемы" 🙈

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

Что же делать в таком случае, когда вас приглашают как эксперта прийти и "сделать так, чтобы все было хорошо и качественно" и желательно чтобы t2m не увеличился 😜

Предлагаю начать с...

Риски автоматизации без тестировщиков и Quality Gates

1. Некому грамотно разрабатывать и поддерживать автотесты. Автоматизированные тесты сами по себе – это программный продукт, который требует навыков и ресурсов для разработки и сопровождения. Без опытного тестировщика или QA-инженера некому тщательно продумать сценарии тестирования, регулярно обновлять эталонные скриншоты и разбирать причины падения тестов. В результате авто-тесты могут покрывать не те случаи или постоянно “краснеть” из-за мелких изменений, и команда начнет игнорировать результаты. Это сведет пользу автоматизации к нулю.

2. Ложное ощущение качества и пропущенные дефекты. Существуют примеры, когда проекты имели тысячи автотестов с зеленым статусом, но это не спасло их от серьезных сбоев. Если нет полноценного QA, легко попасть в ловушку: «раз тесты прошли, значит все в порядке». Скриншот-тесты проверяют только визуальные изменения и не гарантируют, что функциональные баги или проблемы UX не просочатся в релиз. Без ручной проверки и аналитического взгляда тестировщика возможны серьезные дефекты, которые авто-тесты попросту не умеют выявлять. Итог: команда уверена в качестве, а пользователи продолжают находить баги.

3. Отсутствие “Quality Gate” – нет механизма удержать сырой код. Quality Gate – это условный “шлагбаум качества”, который не позволяет выпустить изменение, пока не выполнены определенные критерии (например, прошли все тесты, нет критичных багов, покрытие кодом не ниже порога и т.д.). В нашем случае таких механизмов нет. Это значит, что даже если автоматические тесты выявят проблему, ничто не помешает неопытной команде пропустить не исправленный дефект дальше. Без процесса код-ревью, без обязательного прохождения тестов перед слиянием в ветку – автотесты легко обойти. Получается иллюзия контроля: тесты есть, но они не влияют на решения.

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

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

Продолжение:
Типичные проблемы проектов без QA

#qa #pro_qa #qa_процессы #qa_автоматизация #qa_нет #quality_gates #qa_жизнь

После новогоднего перерыва в пару месяцев возобновляю программу бесплатных консультаций #qa_mentoring_free 😎

Для тех кто недавно на канале:
Немного обо мне: https://t.me/pro_qa/6
С чем могу помочь в качестве ментора и наставника: https://t.me/pro_qa/8
Отзывы в @qa_advisor_feedback.

Условия участия:
1. быть подписанным на @pro_qa
2. поставить эмодзи ❤️ к этому сообщению
3. быть джуном или мидлом
4. скинуть информацию о своем бэкграунде или свое резюме мне в личку @qa_advisor
5. сформулировать запрос или дать вводные, если запроса нет
6. написать отзыв в @qa_mentors после консультации

Сбор заявок провожу до 18 марта 23:59 gmt+3, а 19-20 марта разбираю и выбираю финального кандидата.

#qa #pro_qa #ментор

Начало истории:
Риски автоматизации без тестировщиков и Quality Gates

Типичные проблемы проектов без QA

Проекты, где отсутствует выстроенный процесс качества и нет QA-специалистов, как правило страдают от ряда системных проблем:

1. Нет должного контроля качества. Если в команде никто не сфокусирован на тестировании, качество остается “размытой” ответственностью. Разработчики проверяют лишь то, что считают нужным, часто ограничиваясь минимальными проверками “чтобы работало у меня”. В результате многие дефекты обнаруживаются слишком поздно – уже на стороне пользователей или в продакшене. Нет независимой оценки продукта перед выпуском, что повышает риск пропустить критичные баги.

2. Хаотичные изменения и регрессии. Без регламента по тестированию обновления вносятся поспешно и не проверяются всесторонне. Регресс (когда новая доработка ломает старую функциональность) становится обыденностью, ведь нет регламентированных регресс-тестов перед каждым релизом. Проект живет по принципу “пофиксим на лету”, что может работать какое-то время, но не масштабируется. Чем больше система, тем чаще неконтролируемые изменения порождают хаос: одно исправили – другое сломалось, и так по кругу.

3. Сложности в определении и воспроизведении дефектов. В отсутствии структурированного QA-процесса часто неясно, что считать багом, а что – нормой. Требования к продукту могут быть неформализованы; нет четких критериев приемки. Это приводит к спорам: клиент считает поведение ошибкой, разработчик – “так задумано”. Даже выявленные проблемы документируются бессистемно: может не быть единого реестра багов. Как следствие, некоторые дефекты теряются или повторяются из релиза в релиз. А при попытке разобраться, где и почему случился сбой, команде не хватает фактов – нет ни тест-кейсов, ни отчетов о проведенном тестировании.

4. Отсутствие ответственности за качество. В таких проектах нередко царит реактивный подход: реагируют на проблемы постфактум, вместо того чтобы предотвращать их. Никто не занимается проактивно качеством – не составляет тест-планы, не анализирует метрики дефектов, не думает над улучшением процесса. По меткому выражению одного эксперта, “отсутствие QA – это отсутствие адвоката качества в команде”. То есть важных для качества вещами (тестовая стратегия, процедуры проверки, отслеживание багов) в лучшем случае занимаются «по возможности», а в худшем – не занимается никто. Отсюда низкая предсказуемость: выпуск каждой новой версии – это небольшой риск, потому что нет уверенности, насколько она качественно проверена.

#qa #pro_qa #qa_процессы #qa_нет #qa_жизнь

В этот раз желающих на #qa_mentoring_free было больше чем обычно и кейсы были интересные, так что решил помочь консультацией 2-м кандидатам вместо одного 🎉

Те, кто не попал в топ-2, не теряйте надежды - в апреле будет повторение.

И я думаю:
1) увеличить кол-во с 1 до 2-ух каждый месяц, благо время сейчас позволяет 😎
2) поменять формат: один кейс я выбираю сам, а второй кейс рандомно 😇

#qa #pro_qa #ментор

Из жизни нанимающего QA менеджера

Только что запостили вакансию Manual QA Engineer (удаленка, мидл/синьор) на #hh.ru - 47 откликов через 10 минут, 180 через 30 минут, 300 через час.

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

#qa #pro_qa #qa_найм #headhunter #qa_жизнь #найм

Начало истории:
1. Риски автоматизации без тестировщиков и Quality Gates
2. Типичные проблемы проектов без QA

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

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

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

1.1. Определение требований и критериев приемки. Каждая функциональность должна иметь понятное описание того, как она должна работать, и что считается корректной работой. Формализуйте эти требования (в user story, спецификациях или просто списком условий). Это станет основой и для ручного тестирования, и в будущем для автотестов.

1.2. Введение “Definition of Done” с упором на качество. Согласуйте с командой, что каждая задача считается выполненной не только после написания кода, но и после прохождения определенных проверок качества. Например: код написан и отрецензирован, изменение протестировано вручную (самим разработчиком или коллегой), нет открытых критических багов, обновлена документация и т.д. Это встроит качество в процесс разработки.

1.3. Заведение метрик. Начните собирать простые метрики: сколько багов выявляется до релиза vs. после, скорость исправления, и т.п. Это покажет прогресс (или проблемы) в качестве более объективно, чем субъективные впечатления.

1.4. Код-ревью и статический анализ как “мини-QA”. Обязательные обзоры кода (code review) перед слиянием изменений – эффективный “фильтр” многих ошибок. Коллега может заметить неточность в логике или нарушение стандарта, пока баг еще не попал в продукт. Инструменты статического анализа (линтеры, SonarQube и пр.) тоже выступают в роли Quality Gate: они автоматически проверяют код на уязвимости, ошибки стиля, потенциальные дефекты. Внедрив эти практики, вы уже снижаете процент дефектов, еще до этапа тестирования.

#qa #pro_qa #qa_процессы #qa_жизнь #qa_автоматизация

Начало истории:
1. Риски автоматизации без тестировщиков и Quality Gates
2. Типичные проблемы проектов без QA
3. Шаги, которые стоит предпринять прежде, чем автоматизировать, часть 1

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

2. Внедрить ручное тестирование и QA-поддержку. “Автоматизировать можно только то, что сначала понятно и проверено вручную.” Поэтому прежде чем писать автотесты, нужен налаженный процесс ручной проверки:

2.1. Назначить ответственных за тестирование. Идеально – ввести в проект тестировщика (или команду QA), чьей задачей будет планирование и проведение тестов. Если выделенного тестировщика нет, распределите обязанности: например, один из разработчиков или аналитик может выполнять роль QA на время релиза, или привлекайте внешнего специалиста на аудит качества. Главное – чтобы была роль, фокусирующаяся на проверке продукта.

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

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

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

#qa #pro_qa #qa_процессы #qa_жизнь #qa_автоматизация

Внезапно в Duolingo произошло какое-то обновление программы - прогресс (модуль такой-то, урок такой-то) сохранился, но сами модули поменяли местами и в итоге оказалось, что у меня пройдено примерно половина того, что я не изучал и апка считает, что я весь этот материал знаю и спрашивает исходя из этого. Балин, тестировщиков на них нет 🤦‍♂️

Пришлось переключиться с русский-немецкий на английский-немецкий и начать с самого начала. Зато программа более понятная, есть объяснения грамматики и некоторые вещи более логичны и понятнее, когда их с английского на немецкий переводишь 😎

#qa #pro_qa #багивокругнас #german #duolingo

Всем привет!
У меня появилось 2-3 места на полноценное сопровождение (аудит знаний, мок-интервью, подготовка к интервью, работа с резюме, работа с вакансиями, поиск теплого входа в интересующую вас компанию, составление ИПР, помощь на текущих проектах с процессами/наймом и тп) и несколько свободных слотов для разовых консультаций.

Формат и стоимость:
• 15 мин знакомство и обсуждение запроса: бесплатно.
• Мин.пакет на сопровождение из 5ч: 330€ / 30 тыс.руб
• Разовая консультация: 88-166€ / 8-16 тыс.руб - в зависимости от запроса.
• Разбор резюме (рус, англ) с подробными комментариями: 55€ / 5 тыс.руб - голосом до 30 мин / текст в асинхроне

Скидки (на разовые консультации):
• 10% - моим подписчикам
• 20% - на вторую консультацию

Про меня https://t.me/pro_qa/6
С чем еще могу помочь: https://t.me/pro_qa/8
Отзывы: https://t.me/qa_advisor_feedback
LinkedIn: https://www.linkedin.com/in/evgeniidanilov

#qa #pro_qa #ментор

Приглашаю всех 9 апреля на открытый бесплатный урок нового потока курса QA Lead.

📕 Открытый урок по управлению QA-командой для тестировщиков, руководителей QA-команд, middle/senior разработчиков и системных аналитиков

На открытом уроке 9 апреля в 19:00 мск мы погрузимся в секреты успешного подбора талантов, изучим эффективные техники интервьюирования и разберем, как выявить не только технические навыки кандидата, но и его личные качества, которые могут стать залогом успешной работы в QA команде.

📗 Основные темы:
- Описание и публикация вакансии;
- Отбор кандидатов и ревью резюме;
- Проведение собеседования;
- Оценка результатов проведения
собеседования;
- Обратная связь кандидату и
составление оффера.

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

👉 Регистрируйтесь прямо сейчас, чтобы не пропустить мероприятие: https://otus.ru/lessons/qa-lead/#event-5603

📙 Все участники открытого урока получат скидку на курс "QA Lead"

Курс QA Lead: https://otus.ru/lessons/qa-lead/
Программа курса: https://otus.ru/lessons/qa-lead/program/
Код на скидку 10%: DANILOVV10
Условия использования скидки: Оплата курса со скидкой по промокоду преподавателя, без рассрочек. Без участия менеджера.

#qa #pro_qa #qa_собес #otus #qa_обучение #qa_lead