Кто узнает гостью?

Привет! Часто я слышу от учеников: «Я уже всем друзьям прожужжал уши про твой крутой курс по тестированию, но им же нужна мотивация!» – и я задумался, почему бы не поблагодарить вас всех за рекомендации? Ведь сарафанное радио – самая честная реклама, идёт от сердца и реального опыта. Между прочим, в январе больше половины новых учеников пришли по совету друзей)

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

1. Если ты приводишь человека на курс, он получает 10 процентов скидки, чтобы решиться на шаг в IT и не переживать за бюджет.
2. После того как он устроится на работу, ты получаешь 15 процентов от его постоплаты.

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

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

Так что бери на заметку, делись инфой и будь частью нашей дружной комьюнити. Если остались вопросы или уже есть кандидат, пиши мне в личку – всё расскажу и оформим как надо. Спасибо за доверие и до встречи на курсе.

Не тестированием едины, я же кошкотец

Как тестировать задачи на собеседованиях (и не запаниковать)

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

Эти задачи, я думаю, известны всем:

- Протестировать калькулятор
- Протестировать форму регистрации (да и любую форму вообще)
- Протестировать лифт или какие-то более абстрактные задачи

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

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

Здесь мы возвращаемся к теории тестирования (инфа по требованиям) и начинаем уточнять:

- Лифт грузовой или пассажирский?
- Может ли он ездить ниже первого этажа (подземные парковки, складские помещения)?
- Есть ли ограничения по весу или количеству человек?
- Как устроена панель управления: что происходит при нажатии нескольких кнопок сразу?
- Что делает лифт, если его одновременно вызывают снаружи и внутри?

Тут можно накидывать много разных вопросов. Для чего это нужно? Человек, который проводит собеседование, хочет увидеть, как ты подходишь к решению задач, и намеренно не даёт изначально все вводные данные, чтобы посмотреть, как ты будешь с ними работать.
После того как я уточнил весь контекст, задал все интересующие меня вопросы, получил все интересующие меня ответы, я имею полную картинку по вводным данным, по требованиям и понимаю, как должен работать наш лифт, как он должен выглядеть и что он должен уметь.
Дальше мы накидываем проверки, опять-таки идя структурно. Например, сначала тестируем внешнюю панель. Здесь просто важно понять, как лифт реагирует на вызовы с разных этажей. Очень простой сценарий: нажал кнопку «Вверх» на первом этаже, лифт приехал, дверь открылась — супер, кейс пройден. А что, если одновременно вызвать лифт на первом и на пятом этажах? Какой вызов будет приоритетнее?
Далее переходим к следующему блоку — панель внутри лифта. Здесь кейсов может быть больше. От простых: нажал этаж — приехал на этаж, до сложных: нажал три разных этажа, и лифт должен доехать в правильной последовательности (по возрастанию). Или нажал кнопку «открыть дверь», когда лифт уже поехал — сработает или нет?

Отдельная тема — двери. Если я застрял в дверях, двери откроются обратно или нет? Реагирует ли он на какие-то преграды при закрытии (например, руку)? Будет ли лифт закрываться и ехать дальше или нет?
Затем мы можем применять техники тест-дизайна. Например, проверяем граничные значения: либо количество людей, либо вес (грузоподъёмность), либо количество этажей. Здесь же мы можем дополнять негативными кейсами: что будет, если лифт перегружен? Он будет стоять на месте или подавать сигнал? Что будет, если пытаться вызвать несуществующий этаж? Опять-таки, мы можем подразумевать, что вызвать такой этаж невозможно, но проверить это обязательно должны.

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

ПРОДОЛЖЕНИЕ В КОММЕНТАХ!

Всем привет! В этом видео мы встретились с Ваней Булгаковым во время моего путешествия на Бали и поговорили о том, каково это — устроить более 140 человек в IT, зачем вести кружки в Telegram и как не перегореть, когда ты пашешь в закрытом комьюнити.

Обсудили:
– что делать, когда теряется вау-эффект от трудоустройств;
– почему именно рутина рождает профессионализм;
– как работают постоплата и рассрочка в менторстве;
– почему высокая цена — это фильтр, а не маркетинговый трюк;
– как выглядят боты, которые реально помогают;
– стоит ли заменять себя цифровым аватаром (спойлер: нет);
– и почему живой человек продаёт лучше любого ИИ.

Это неформальный и честный разговор двух менторов — про работу, усталость, радость, деньги и философию менторства. Приятного просмотра!

Кстати, чуть больше года как я не в найме, снял видос о своих мыслях на этот счет, время летит - ахуй

Всем привет!

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

В этом уроке подробно разберём что такое SDLC и STLC и поговорим об их этапах.

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

Снял видео «ответы на вопросы» из этого поста

40 минут пиздежа разговор о главном.

Ставь лайк если ждешь

Всем привет! Прошёл ровно год с того момента, как я ушёл из найма и полностью переключился на менторство. Это видео — не про советы, не про продажи и не про систему. Это откровенный монолог о том, что я понял за этот год: про страхи, свободу, ответственность, выгорание и баланс.

Поделился мыслями о том:
– почему свобода — это не про лёгкость;
– как вылезти из зоны комфорта и не пожалеть;
– как изменилась моя жизнь, мышление и окружение;
– что делать со страхом нестабильности.

Честный итог года без найма. Без прикрас. Просто опыт, которым хочется поделиться.

Уверен так и будет!

Ладно, результатом выебываться мы умеем, но есть и часть работы которая мало мной освещается (честно, хз почему), но внутри коммьюнити проводится колоссальная работа. Изменения в материалах (как доп задания, которые разрабатываются с взаимодействием дизайнера/разработчика), как частые созвоны внутри коммьюнити с приглашенными спикерами (от трудоустроившихся учеников до продакт лида Т-банка и психолога), разборы вопросов с собеседований и сходка на каяках в конце мая. Мы (я говорю Мы - это и команда, и коммьюнити в целом) работаем не просто над поддержанием работающей системы, но и стремимся ее улучшить. Я искренне верю что хороший продукт лучше маркетинга, и пусть я могу ошибаться, пока мой подход работает. Почти 30 человек трудоустроенных за первый квартал со средней зп - 170к


Ахуй? Ахуй

Всем привет! Мы записали ролик с Ромой Омелаенко (да-да, кокосовый QA 🌴) прямо на берегу океана, на Бали. Это не подкаст в студии — это разговор в кайф, с шумом волн и честными темами.

Мы говорим о том:
– как Рома стал ментором и зачем он вообще этим занялся;
– почему нужно 10 сеансов психотерапии, чтобы поверить в себя;
– что такое «кармический долг» и где его граница;
– что сейчас реально происходит на рынке IT;
– как меняется жизнь у учеников — от официанта до айтишника с квартирой;
– и как выбрать, кого менторить, а кого — нет.

Это не интервью и не мотивация в духе «успешного успеха». Серьёзно, смешно, местами философски. Но точно — по-настоящему. Приятного просмотра!

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

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

И начинается само собеседование, я отвечаю на теоретические вопросы какие-то, и в момент нашей милой болтовни тимлид кидает вопрос:

«Как бы ты протестировал кнопку?»

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

В общем, тимлид молчит и потом спокойно говорит:

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

Честно признаюсь, я завис просто пиздец.

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

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

А бывало ли у тебя на собеседовании, что понесло куда-то не туда? Поделись — соберем коллекцию проебов вместе.

Эх, вот бы научится писать прогревочные посты…

Как тестируется интеграция, На примере

Допустим, есть вопрос: "расскажи, пожалуйста, как ты взаимодействуешь с интеграционным тестированием на проекте." Как об этом рассказывать? На что обращать внимание? Как структурно подавать эту информацию? Об этом сейчас подробнее я расскажу. Допустим, я работал на проекте видеоконференции, видеосозвонов и буду рассказывать об этом. Итак, вопрос звучит следующим образом: «Расскажи, пожалуйста, как ты взаимодействуешь с интеграционным тестированием на проекте видеоконференции».

Во‑первых, интеграционное тестирование – это важный этап проверки систем, построенных на нескольких взаимосвязанных модулях или микросервисах. На проекте видеоконференции, где я работаю, система состоит из нескольких ключевых компонентов: это сервис аутентификации, сервис видеостриминга, сервис управления комнатами (room management), чат, уведомления. И всё работает через REST API и WebSocket‑соединения. Каждый из этих компонентов можно успешно тестировать через модульное тестирование, но в реальности всё может сломаться именно на стыке при взаимодействии между модулями. Именно для этого нам и нужно интеграционное тестирование.

Как я подхожу к интеграционному тестированию? Во‑первых, анализирую архитектуру. Перед началом тестирования я изучаю, какие модули участвуют в конкретной бизнес‑функции. Например, чтобы пользователь вошёл в видеоконференцию по ссылке, участвуют Auth, (не авторизация - временный пользователь не авторизуется), Room, Streaming, UI и Notification. То есть я строю для себя схему взаимодействия и поток данных: от нажатия кнопки «Войти» до появления в комнате. Схему держу в голове, отдельно не рисую.

Дальше мы определяем ключевые точки интеграции. Например, вызов Auth API и выдача токена, использование токена для подключения к видеостриму.

Далее идут тест‑кейсы: они пишутся вручную, часто в виде сценариев «end-to-end», но ориентированных на взаимодействие между сервисами. Например, пользователь с валидной ссылкой и токеном успешно подключается и попадает в комнату; пользователь с истёкшим токеном получает ошибку авторизации от стрим‑сервиса и не может войти; после подключения второго участника оба видят друг друга и работает чат; сообщения передаются по WebSocket и отображаются корректно.

Какие инструменты мы используем? Для REST API — Postman: вручную отправляем запросы, подставляю разные параметры, проверяю, как один сервис реагирует на результаты другого. Могу использовать Swagger либо как документацию и описание API, или отправить через Swagger эти запросы. Для WebSocket — эмуляторы или встроенные DevTools, если соединение устанавливается в браузере.

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

Если возникают баги, мы анализируем логи каждого микросервиса через ELK (Elasticsearch + Kibana). Также могу посмотреть состояние в базе данных: создался ли пользователь, записался ли участник в room_members(столбец в таблице бд) после подключения, появился ли временный пользователь. При записи у нас сохраняется статистика о звонке, и мы можем проверить, отображается ли там наш новый пользователь.

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

ПРОДОЛЖЕНИЕ В КОММЕНАТРИЯХ:

Отчет за 1 квартал 2025


Квартал вроде как закрылся ещё в марте, но у меня апрель пролетел в режиме «отдыхаем‑поддерживаем, не разгоняемся» — отпуск же. Так что отчёт только сейчас. Короче, что наделали, где круто, где лажанули, и чуть‑чуть про ближайшие планы.

Что круто:
Команда расширилась. Четыре куратора, пм в команде - ахуй.

Вернули созвоны со спикерами и разборы собесов. Итог? 28 трудоустроенных с середины января до конца апреля. На нынешнем рынке это ахуенно.

Два пилотных потока уже обкатываются. Первый поток почти готов, люди скоро выходят на рынок. Серёга, Саня — спасибо, вы топ.

Статейный конвейер пашет, на YouTube стартовал курс по тестированию. Коллабов с тестировщиками стало больше (Булгаков, Омелаенко, Пше) — подкаст с Сашей на подходе. Видео по материалам так же в процессе съемок и монтажа, работаем!

Оффлайн. 30 человек на кинопоказе в Питере, 35 — на сходке в Москве. Ахуй? Для меня да! Дальше: каякинг 31 мая—1 июня (сначала Питер, потом будем планировать Москву) и летом летим в Дагестан.

Где можно лучше:
Созвоны и собес‑разборы подустали к концу квартала — возвращаем в привычный темп.

Есть ребята, у кого трудоустройство буксует. Я знаю, работаем точечно.

Что готовлю (без лишних обещаний):
Сокращаем трек обучения без потери мяса: пересобираем домашки, обновляем материалы (то, че делаем пока ни у кого нет), переводим их в индивидуальный формат в Jira. Цель — быстрее выводить ребят на рынок.

Майские созвоны с людьми из смежных направлений — iOS, фронт, product, дизайн. Плюс 27 мая большой разговор с психологом.

Апгрейд материалов + ещё видео. Стараемся сильно не уходить в YouTube, чтобы обучение не просело.

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

Всем привет! В этом долгожданном выпуске, ради съемок которого я прилетел в Дубай, мы встретились с Сашей Пшеборовской — айтишницей и предпринимательницей, которая начинала свой путь с подработок по ночам и дошла до оффера в Deutsche Bank, а потом ушла в свободное плавание. Говорим про путь через страх, выгорание, синдром самозванца и про то, как вывозить, когда кажется, что всё против тебя.

Саша поделилась:
– как жила одна с юных лет и совмещала работу с учёбой;
– что чувствовала, получив первую зарплату в 80к после смен по 900₽;
– как приняла решение уйти из найма;
– как справлялась с английским, работая в команде из индийцев;
– особенностями жизни в Европе, будучи экспатом;
– своим опытом руководства командой;
– и почему даже «подаренные шансы» – это всегда следствие большой работы.

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

Как я тестирую внешнюю интеграцию на примере YooKassa

Давай разберем ситуацию тестирования внешней интеграцию в проекте интернет-магазина — я всегда привожу в пример работу с платёжным шлюзом YooKassa. Это отличный кейс, чтобы показать, как я подхожу к тестированию: системно, но без отрыва от реальных задач и пользователей.

Что вообще такое внешняя интеграция?

Если говорить простыми словами — это когда наш сайт (или приложение) должен взаимодействовать с внешним сервисом, чтобы всё работало. В моём случае — интернет-магазин, и нам нужно было принимать оплату через YooKassa

Интеграция построена на REST API: мы отправляем HTTP-запросы (например, чтобы создать платёж), а YooKassa отвечает, и в нужный момент сама присылает нам уведомление (это и есть webhook — когда сервис сам «стучится» к нам и сообщает, как прошёл платёж).

С чего начинать?

Первым делом читаю документацию от и до — спецификацию YooKassa. Там расписано:

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

Например, чтобы создать платёж, мы отправляем POST-запрос на /v3/payments с суммой, валютой, типом подтверждения (чаще всего redirect — то есть пользователя перекинет на форму YooKassa), ссылкой на возврат и уникальным idempotence_key (он нужен, чтобы два одинаковых запроса случайно не создали два платежа).

Как я рисую схему взаимодействия

Я не сразу лезу писать тест-кейсы или проверять. Сначала в голове (а иногда и на бумаге/миро) строю цепочку:

1. Создание платежа
2. Редирект пользователя на форму YooKassa
3. Оплата (в песочнице — тестовыми картами)
4. Получение webhook (то самое автоматическое уведомление от YooKassa о результате)
5. Если webhook не пришёл — можем вручную запросить статус

Потом под каждый шаг составляю сценарии. Вот базовые:

- Всё прошло успешно, пользователь получил подтверждение.
- Попытка оплаты неудачна (например, карта просрочена).
- Пришёл webhook → мы обновили заказ.
- Webhook не пришёл → сами дернули API и узнали, что с оплатой → мы обновили заказ.

Инструменты и подход

Для ручной работы использую Postman. Сначала создаю платёж и смотрю, что в ответе есть payment_id и confirmation_url. Перехожу по ссылке, ввожу тестовые данные (есть специальные карты от YooKassa для[песочницы.
Дальше руками отправляю webhook (имитирую его через Postman), чтобы проверить, как среагирует наше приложение — обновит ли статус заказа, отправит ли уведомление пользователю и так далее.

А как же ошибки?

Обязательно прохожу и негативные сценарии. Они ничуть не менее важны:

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

Где ищу баги?

Если что-то пошло не так, и платёж не обработался, — иду в Kibana или Grafana, смотрю логи по payment_id, проверяю, пришёл ли webhook, и есть ли нужный статус в базе. Иногда просто смотрю в таблицу заказов напрямую.

Примеры багов и что с ними делать

Баг 1. Изменился формат webhook (после обновления API)
После обновления YooKassa немного изменила структуру webhook-сообщений — поле `status` переехало в другую часть JSON. Наш код этого не «заметил» — и заказы просто не обновлялись.
Почему случилось: мы не следили за обновлениями и пропустили изменение.
Как починил: добавили JSON-схему, сделали проверку формата, написали юнит-тесты на парсинг webhook'ов. Теперь любое несоответствие быстро видно.

ТВИТТЕРЕДА ПОДПИСАТЬ / ПРОДОЛЖЕНИЕ В КОММЕНАТРИЯХ