Обновить

Тестирование

Сначала показывать
Порог рейтинга

Как мы научили ИИ вести себя как человек — и почему это оказалось важнее остального 🤖🧠

Привет, Хабр.

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

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

В какой-то момент я решил посмотреть на эту проблему как на инженерную задачу и попробовать автоматизировать рутинную часть процесса. Так появился ИИ-ассистент OfferMate.

Но довольно быстро стало понятно: автоматизация — это не всегда про “делать быстрее и больше”.

Почему «больше автоматизации» — плохая идея ⚠️

Первая версия ассистента решала задачу максимально прямолинейно:

  • быстрый сбор вакансий;

  • частые проверки;

  • высокая плотность запросов;

  • ставка на объём.

С инженерной точки зрения всё выглядело логично:
больше данных → больше откликов → выше шанс результата.

На практике это оказалось ошибкой.

Такой подход:

  • создаёт пиковые нагрузки 📈;

  • выглядит неестественно;

  • повышает риск блокировок;

  • и, главное, не отражает реального поведения человека.

Рынок труда — не нагрузочный тест и не очередь сообщений в Kafka.
Он реагирует не только на результат, но и на паттерн поведения.

Ключевое открытие: автоматизация должна быть незаметной 🕵️‍♂️

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

Опытный специалист:

  • не откликается на всё подряд;

  • читает вакансии выборочно;

  • делает паузы;

  • меняет темп;

  • реагирует на контекст.

И если автоматизация не воспроизводит этот паттерн — она рано или поздно ломается.

Это стало точкой, после которой мы полностью пересобрали архитектуру 🔄

Что изменилось в подходе ⚙️

Вместо «ускорения всего» мы сфокусировались на естественности поведения.

Теперь система:

  • 🧠 анализирует вакансии, а не просто собирает их пачками;

  • 👤 имитирует человеческий ритм: паузы, разную скорость, приоритеты;

  • 🔄 адаптируется к изменениям в реальном времени;

  • 🛡️ работает в рамках правил платформ, не создавая аномалий.

Что это дало на практике 📊

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

  • ✅ Конверсия откликов выросла — потому что система стала бить не по площади, а в цель;

  • ✅ Пользователи перестали вмешиваться вручную — ассистент стал предсказуемым;

  • ✅ В среднем освобождается 10–15 часов в неделю, которые раньше уходили на рутину.

Именно здесь стало понятно, что мы движемся в правильном направлении 🚀

OfferMate 2.0: не «автоматизация всего», а умное делегирование 🧩

Этот подход лёг в основу новой версии продукта, которую мы сейчас допиливаем.

В OfferMate 2.0 мы сознательно ушли от идеи «пусть ИИ делает всё» и сфокусировались на том, где он действительно полезен:

  • 🤖 анализ резюме и вакансий с учётом контекста, а не ключевых слов;

  • ✍️ генерация сопроводительных писем под конкретную компанию;

  • 🛡️ нативное и естественное взаимодействие с платформами;

  • 📈 прозрачная аналитика и контроль со стороны пользователя.

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

Итоговые мысли 🧠

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

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

👉 https://t.me/offermatecrew

Там же делимся апдейтами OfferMate 2.0 и результатами тестирования.
Буду рад вопросам и обсуждению в комментариях 👇

Теги:
Всего голосов 6: ↑1 и ↓5-4
Комментарии0

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

Диана, инженер по тестированию в Naumen, делится личным опытом: как перестать бояться задавать вопросы, говорить о багах без конфликтов и выстраивать рабочие отношения на старте.

Как я справилась со страхом задавать вопросы

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

В этот период меня очень поддержал наставник. С ним можно было обсудить, как корректно сформулировать баг, что именно стоит спросить у разработчика и как не растеряться на созвоне. Он сказал мне важную мысль: «Даже самый глупый вопрос — это нормально, если ты действительно хочешь разобраться».

Как говорю о багах, чтобы меня поняли

Первые разговоры с разработчиками были волнительными. Мы смотрим на систему по-разному: я — через интерфейс, разработчик — через код. Иногда даже называем одну и ту же кнопку иначе.

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

Когда я сообщаю о баге, всегда прикладываю:

  • шаги воспроизведения;

  • скриншоты или видео;

  • ожидаемое и фактическое поведение;

  • логи.

Что я делаю, если разработчик говорит «у меня все работает»

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

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

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

Бывает и так, что ошибка оказывается на стороне тестировщика: не тот сценарий, не туда кликнули, не так запустили. В такие моменты неловко, но лучше озвучить сомнение, чем пропустить реальный дефект.

Что помогает выстроить рабочий контакт:

  • приносить максимум информации;

  • избегать обвинений — мы ищем решение, а не виноватого;

  • предлагать созвон, если переписка не помогает;

  • не бояться переспрашивать;

  • напоминать аккуратно, если задача «зависла».

Почему важно уточнять требования

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

Требования могут быть неполными, измениться в процессе или трактоваться по‑разному. Поэтому я стараюсь задавать вопросы еще до начала тестирования и фиксировать все договоренности прямо в задаче, чтобы была единая «точка правды» для всей команды.

У меня была задача с новым функционалом. Я разработала тест-кейс и пошла к аналитику — уточнить корректность сценария. Аналитик сказал, что сценарий невозможен.

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

Почему полезно делиться опытом

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

И сама стараюсь делать то же самое: делиться тем, что знаю, помогать, если кто‑то только погружается в проект. Команда работает лучше, когда в ней не боятся спросить и не жадничают знаниями.

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

→ Подробнее своим опытом Диана поделилась в статье.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Отраслевое исследование QA: автоматизация, AI и метрики — сбор данных

Команда Test IT (бренд «Девелоника» FabricaONE.AI (акционер – ГК Softline)) запустила опрос для сбора данных перед публикацией отраслевого исследование по состоянию QA в российских компаниях.

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

Ссылка на анкету исследования

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

Присоединяйтесь, давайте вместе составим объективную картину по рынку в нашем сегменте! Всем недели без багов и без пятничных релизов)!

Теги:
Рейтинг0
Комментарии0

"У меня друг/брат/сват/муж/жена/собака хочет в тестирование! где почитать?!"

TostersSchool
TostersSchool

Несколько лет назад мы с коллегами заметили закономерность: раз в неделю кто-то спрашивает "с чего начать изучение тестирования?". Вопрос один и тот же. Ответы одни и те же. Ссылки одни и те же.

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

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

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

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

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

В общем, если вас спросят "где посмотреть что-то про тестирование для начинающих" - можете кинуть ссылку: TostersSchool

Канал легко гуглится и ищется в Telegram.

Теги:
Всего голосов 4: ↑2 и ↓20
Комментарии0

Монорепозиторий с автотестами разросся до микросервисов?

Владислав Донченко поделился опытом преобразования огромного монолитного репозитория с автотестами в модульную структуру в статье «Как преобразовать огромный монорепозиторий с автотестами в микросервисы».

Как преобразовать огромный монорепозиторий с автотестами в микросервисы
Здравствуйте! Меня зовут Владислав Донченко, я ведущий специалист по тестированию в Альфе. Хочу поде...
habr.com

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

Главная цель «реформ» — достижение максимального эффекта с минимальными изменениями (трудозатратами). Мы хотели сохранить ту практику работы с репозиториями, которая у нас уже была. Поэтому мы решили подходить именно со стороны нашего сборщика — со стороны Gradle, чтобы не производить радикальных изменений с проектом. 

Надеемся, что наш опыт поможет и вам, когда вы столкнетесь с похожими вызовами!

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Если ты — Automation QA и хочешь перейти в мир обеспечения качества AI-приложений*, как это сделала я, то мой путь может послужить небольшой дорожной картой.

*не путать с использованием AI-инструментов для тестирования классических приложений

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

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

Временные затраты
Около 7 месяцев изучения теории и параллельно более года практического опыта. Этот год я провела, участвуя в стартап-проектах (в основном в роли QA Lead), что дало мне «безопасную песочницу» для применения знаний в области ML на реальных практических задачах.

Переход на Python
Java — отличный язык, но в экосистеме ML/AI «лингва франка» — это Python. Библиотеки для работы с моделями, статистикой, метриками и трансформерами здесь есть на любой вкус и цвет. Так что, если ты Java QA, стоит сменить Java на Python.

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

Этот бесплатный англоязычный курс был действительно отличным, интересным и захватывающим — спасибо, Dr. Raj Abhijit Dandekar!

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

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

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

оригинальные посты выходят в Linkedin (англ.)

Теги:
Всего голосов 3: ↑2 и ↓1+2
Комментарии0

Услышал про Apidog. Кажется, Postman больше не единственный вариант

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

До недавних пор был уверен, что Postman это непоколебимый промышленный стандарт для работы с API. Все его знают, все используют, коллекции передаются из проекта в проект. Зачем искать что-то ещё?

Вчера разговорился с коллегой из команды, и он упомянул Apidog. Говорит, перешёл полгода назад и не жалеет. Сегодня решил посмотреть сам. Вот первые впечатления.

Что это такое

Apidog позиционируется как all-in-one платформа: дизайн API, документация, mock-сервер, тестирование и дебаг в одном месте. По сути, Postman + Swagger + Mock + автотесты без переключения между инструментами.

Что зацепило

Визуальный редактор для создания спецификаций. Рисуешь схему, она автоматически превращается в OpenAPI. Не нужно писать YAML руками.

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

Автотесты с визуальными assertions. Можно добавлять проверки без кода, просто кликая. Есть data-driven тестирование, интеграция с CI/CD.

Командная работа в реальном времени. Версионирование API, ветки как в Git, ролевой доступ.

Импорт коллекций из Postman. Миграция не с нуля.

Что смущает

Китайские корни. Для кого-то это плюс (активная разработка, быстрые релизы), для кого-то минус (вопросы безопасности данных).

Ещё один инструмент в зоопарк. Bruno, Insomnia, Hoppscotch, теперь Apidog. Выбор это хорошо, но и головная боль при стандартизации в команде.

Бесплатный тариф щедрый, но всё равно есть ограничения для больших команд.

Пока не тестировал глубоко

Это именно первые впечатления после пары часов изучения. Не готов сказать «бросайте Postman», но точно буду пробовать на реальных задачах.

Интересно послушать тех, кто уже работает с Apidog на постоянной основе. Какие подводные камни? Стоит ли переходить с Postman или это из серии «работает — не трогай»?

Ссылки по теме на Хабре

Коллеги уже делали разборы инструментов для работы с API:

📄 Отказаться от Postman, перейти на Bruno и жить счастливо — в комментариях есть отзыв про Apidog от человека, который перешёл

📄 Лучшие open-source инструменты для тестирования API в 2025 году — обзор альтернатив

📄 Как выбрать инструмент для тестирования API — сравнение Postman, Insomnia и других

📄 API Тестирование без Postman — разбор Hoppscotch

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии2

polluSensWeb теперь поддерживает 26 датчиков и веб-хуки

polluSensWeb
polluSensWeb

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

До сих пор polluSensWeb был в основном инструментом визуализации и диагностики. Данные оставались в сессии браузера. Это было удобно для тестирования, калибровки или демонстрации, но ограничивало возможности реального применения.

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

  • Пересылать измерения в базы данных.

  • Запускать оповещения или автоматизацию.

  • Отсылать данные в панели мониторинга, такие как Grafana.

  • Интегрироваться с платформами сообществ или пользовательскими API.

Открытый деплоймент
Проект на GitHub

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии0

Почему мы до сих пор спрашиваем про пирамиду тестирования образца 2010 года

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

При этом реальная работа изменилась радикально. Половина команды использует нейросетевых агентов для генерации тестов. Автоматизация пишется в паре с ассистентом. Тест-дизайн делается через промпты. А на собеседовании мы всё ещё спрашиваем "чем отличается верификация от валидации".

Я не говорю, что классика не нужна. Нужна. Но если человек не понимает, как работать с агентами в 2026 году, он будет отставать от коллег с первого дня.

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

1. Промпт-инжиниринг для тестировщика

Как правильно формулировать запросы к нейросети, чтобы получить качественные тест-кейсы, а не общие фразы. Какая структура промпта даёт лучший результат. Почему "напиши тесты для этой формы" работает хуже, чем детальное описание контекста и ожиданий.

2. Валидация результатов работы агента

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

3. Границы применимости нейросетей в тестировании

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

4. Работа с контекстом

Как правильно передавать агенту информацию о проекте. Что такое контекстные файлы и зачем они нужны. Почему один и тот же запрос в разных условиях даёт разные результаты. Как не потерять контекст в длинном диалоге.

5. Этика использования нейросетей

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

6. Интеграция агентов в процесс тестирования

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

7. Оценка качества сгенерированных тестов

По каким критериям оценивать тесты, которые написал агент. Покрытие, читаемость, поддерживаемость, соответствие стандартам команды. Как отличить хороший сгенерированный тест от плохого.

8. Работа с разными типами агентов

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

9. Ограничения и риски

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

10. Критическое мышление в эпоху нейросетей

Почему важно понимать, что делает агент, а не просто использовать результат. Как развивать экспертизу, когда рутину делает машина. Почему человек с глубоким пониманием предмета получит от агента лучший результат, чем новичок.

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

А какие темы про работу с нейросетями вы бы добавили в собеседование?

Теги:
Всего голосов 6: ↑3 и ↓3+2
Комментарии6

Владельцы iPhone 17 Pro и Pro Max сообщили о возникновении статического шума из динамиков смартфонов во время зарядки. Звук напоминает шипение старого радиоприемника. У части пользователей проблема с шумом возникает при воспроизведении видео на низкой громкости, а у кого-то шум появляется при скроллинге страниц в интернете. Этот шум слышно при использовании любой зарядки, как оригинальной, так и от сторонних производителей. Часть пользователей, которые заменили свои смартфоны на новые, также продолжают жаловаться на неприятный звук. В техподдержке Apple сообщили, что уже изучают вопрос с этим шумом.

Теги:
Всего голосов 3: ↑2 и ↓1+3
Комментарии0

Как тестировать Joomla PHP-разработчику? Компонент Patch tester.

Joomla - open source PHP-фреймворк с готовой админкой. Его основная разработка ведётся на GitHub. Для того, чтобы международному сообществу разработчиков было удобнее тестировать Pull Requests был создан компонент Patch Tester, который позволяет "накатить" на текущую установку Joomla именно те изменения, которые необходимо протестировать.

На стороне инфраструктуры Joomla для каждого PR собираются готовые пакеты, в которых находится ядро + предложенные изменения. В каждом PR обычно находятся инструкции по тестированию: куда зайти, что нажать, ожидаемый результат. Тестировщики могут предположить дополнительные сценарии, исходя из своего опыта и найти баги, о которых сообщить разработчику. Или не найти, и тогда улучшение или исправление ошибки быстрее войдёт в ядро Joomla.

Напомню, что для того, чтобы PR вошёл в ядро Joomla нужны минимум 2 положительных теста от 2 участников сообщества, кроме автора.

Компонент на GitHub

Это видео также на:

Чат русскоязычного Joomla-сообщества

#joomla #php #webdev #community

Теги:
Рейтинг0
Комментарии0

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

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

Что происходит с профессией?

Тестировщики все чаще подключаются на этапе проработки аналитики, еще до реализации фичи. Уточняют детали и находят пробелы в логике — это помогает избежать багов на старте.

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

Почему ИИ — главный тренд?

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

Какие навыки важны?

Чтобы быть полезным тестировщиком, важно развивать как технические, так и гибкие навыки:

  • Внимательность, критическое и системное мышление — чтобы видеть не только конкретную ошибку, но и ее влияние на продукт в целом.

  • Английский язык — чтобы читать логи, понимать настройки.

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

Что еще необходимо?

  • REST, HTTP, Linux, Docker — это основа, особенно если вы работаете с DevOps‑задачами. Чтобы глубже тестировать инфраструктурные задачи, полезно пройти курсы и прокачать навыки.

  • Работа в команде и инициативность — в любой задаче важно уметь взаимодействовать с разными ролями: аналитиками, разработчиками, другими тестировщиками. Тестировщик не просто проверяет — он помогает команде находить и устранять слабые места.

Как развиваться тестировщику?

  • Развитие через практику и обмен опытом

Новые подходы можно черпать на конференциях, например, Heisenbug, SQA Days. Дополнительное развитие — брать задачи не только по тестированию, но и по улучшению процессов, участвовать в аналитике, работать над задачами смежного продукта, тестировать мобильное приложение. Наставничество также помогает расти — учишься вместе с теми, кого поддерживаешь.

  • Развитие через ИТ-сообщество и техбазу

Начинающим тестировщикам будут полезны материалы Артёма Русова. У него есть сайт и тг-каналы: @qachanell, @qa_sklad.

Развиваться помогают и внутренние ресурсы в компании: коллеги делятся опытом, обсуждают кейсы, рассказывают, как решают задачи. Если у вас в компании есть что‑то подобное — не упускайте. Это классный способ расти и смотреть на профессию шире.

Полезные книги:

  1. «Тестирование DOT COM», Роман Савин

  2. «Тестирование ПО», Святослав Куликов

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Оптимизации функционала Apache Iceberg в задачах real-time загрузки и обработки данных

В блоге Data Sapience, технологического партнера GlowByte, вышла новая статья.

Технические лидеры направления разработки Apache Spark в составе платформы Data Ocean рассказывают:

  • С какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg;

  • Что такое equality delete;

  • Почему они создают нагрузку при чтении таблиц в Apache Iceberg;

  • Как оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Ближайшие события

Нагрузочное тестирование YMatrix

Привет, друзья! Мой коллега Марк, ведущий архитектор GlowByte, поделился в новой статье результатами тестирования YMatrix.

Сразу оговорюсь, что это дополнение к предыдущей статье, для того, чтобы сформировать понимание сравнимости результатов различных форков GreenPlum, поэтому акцентировать внимание будем только на YMatrix. Детали по методике тестирования и как были получены результаты для GP6, GP7 и Cloudberry 1.6, можно прочитать в предыдущей статье по ссылке выше. 

Добро пожаловать в статью! Комментарии приветствуются.

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии2

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

«Я без проблем делаю упражнения по грамматике, но стоит начать говорить… все, коллапс».

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

Поэтому я всегда говорю своим студентам: смотрите сериалы в оригинале и «воруйте» фразы и интонации.

Я добавила ролик про Леонарда и Пенни не чтобы вас повеселить. Посмотрите, сколько пользы можно выжать из 1 минуты живого языка, а не бесконечных упражнений:

1.Will you pull them up? — Можешь открыть их на экране?

Future Simple. Вежливая просьба.

2. It’s not working — Не работает (пароль).

Present Continuous. Прямо сейчас не работает.

Спорим, вы часто говорите в такой ситуации «It doesn’t work»? Ловите себя на этом!

3. What number were you putting in? — Какое число ты вводила?

Past Continuous. Говорим про конкретный момент в прошлом.

Нас всегда тянет сказать «What number did you put in?», так ведь?

4. You don’t know my birthday, do you? — Ты не знаешь мой день рождения, не так ли?

Если кажется, что tag questions — это что-то из начальной школы, то нет. В сериалах они встречаются постоянно.

5. Your birthday is December, 2 — Твой день рождения 2 декабря.

Хорошее напоминание, как произносить даты в американском английском.

Если забылась разница между британским и американским английским, давайте подсвечу:

🇬🇧 British English

Пример: The third of April, twenty twenty-five

На письме: 3 April 2025 = 03.04.2025 или 03/04/2025

🇺🇸 American English

Пример: April third, twenty twenty-five

На письме: April 3, 2025 = 04/03/2025

Запомните так:

🇬🇧 UK → сначала день, потом месяц.

🇺🇸 US → сначала месяц, потом день.

6. I’m not gonna say your password out loud — Я не скажу твой пароль вслух!

Если вы в международной команде и ваши коллеги из области tech не говорят на языке XIX века, то вы точно часто встречаете “gonna” и “wanna”. Однако я не рекомендую использовать эти варианты при общении с клиентами и на формальных встречах. Посмотрим на примеры:

Gonna = going to

I’m gonna install a new update this afternoon – Я собираюсь установить обновление сегодня днем.

Are you gonna do that today? – Ты собираешься сегодня сделать это?

I’m not gonna review your code today – Сегодня я не собираюсь проверять твой код.

I was gonna break down this code into smaller parts – Я собирался разбить этот код на более мелкие части.

Wanna = want to

I wanna ask for your help. – Я хочу попросить тебя помочь.

I didn’t wanna change the deadline. – Я не хотел менять срок.

Do you wanna join? – Ты хочешь присоединиться?

Lots of developers will wanna relocate. – Много разработчиков захотят переехать.

***

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

А если вам интересно читать об английском для IT и digital и незаметно прокачивать язык, заглядывайте на мой Телеграм-канал.

Теги:
Всего голосов 2: ↑2 и ↓0+3
Комментарии2

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

Pairwise online tool — инструмент для генерации парных комбинаций проверок

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

В чем польза:

  • сокращает количество проверок без потери покрытия;

  • учитывает логические условия и исключает невозможные сочетания;

  • упрощает тестирование форм, статусов и сложных конфигураций;

  • ускоряет подготовку кейсов, в том числе для группы автоматизации.

Катя: Использую Pairwise, когда нужно быстро собрать оптимальный набор проверок. Но важно учитывать ограничения: если дефект зависит от 3–4 условий, техника может его пропустить, а найденный баг сложнее локализовать — непонятно, какой параметр повлиял на воспроизведение.

Visual Studio Code — удобный редактор для создания, чтения и редактирования файлов

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

В чем польза:

  • красиво раскрашивает код до читаемого, удобная навигация;

  • позволяет делать поиск по нескольким файлам одновременно;

  • подходит для анализа конфигураций и настроек системы;

  • поддерживает расширения — все доступно в бесплатном магазине. 

Катя: Использую VS Code как легкий и удобный текстовый редактор — аналог Notepad++. Для разработчиков, мне кажется, он еще полезнее: напоминает полноценную IDE, только в более гибком формате.

Bug Magnet — расширение для Google Chrome с библиотекой тестовых данных

Bug Magnet подставляет в поля формы готовые тестовые значения: длинные строки, разные алфавиты, необычные символы, валидные и невалидные email‑адреса, числа, города и многое другое. 

В чем польза:

  • ускоряет проверку форм и валидации;

  • предлагает значения, которые сложно придумать вручную;

  • поддерживает разные режимы ввода — вставка, симуляция ввода с клавиатуры;

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

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

Flaticon — библиотека бесплатных иконок для интерфейса

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

В чем польза:

  • есть большое количество бесплатных иконок;

  • предлагает варианты под светлую и темную тему;

  • можно скачать в форматах PNG и SVG;

  • упрощает выбор готовых размеров под Android, iOS и веб.

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

Burp Suite — инструмент для тестирования безопасности веб‑приложений

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

В чем польза:

  • позволяет перехватывать и подменять запросы и ответы;

  • помогает изучать авторизацию и поведение параметров;

  • дает возможность автоматизировать переборы значений через Intruder;

  • упрощает анализ и сравнение запросов с помощью Decoder и Comparer;

  • визуализирует структуру сайта и все перехваченные запросы.

Арина: Burp Suite кажется сложным из-за количества модулей, но на практике все просто: перехват — подмена — отправка — анализ. Это удобный инструмент для проверки авторизации, поведения параметров и работы безопасности в целом.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии2

Электроавтомобиль Xiaomi SU7 съехал передом в водоём во время выполнения манёвра автоматической парковки. Бортовая система не заметила перепад высот, повернула и поехала в пруд для разведения рыбы, свесившись передними колёсами над водой. Машину пришлось вытаскивать на дорогу с помощью эвакуатора.

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

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии2

Нетипичный QA

Мы в 2ГИС верим, что в QA есть место опыту из самых разных сфер. И каждый месяц рассказываем истории людей, которые это доказывают. «Нетипичный QA» — это рубрика про инженеров, чей путь в тестирование начался далеко за пределами IT. У каждого свой путь, но всех объединяет одно: стремление к качеству и умение смотреть на задачи под неожиданным углом.

Николай, руководитель команды Ads QA

Николай с детства занимался хоккеем с мячом — сначала в школе, потом параллельно с учёбой в университете. После выпуска стал профессиональным спортсменом: играл за команды в Новосибирске, Красногорске и Хабаровске и выступал за сборную России. В его карьере — серебро чемпионата мира. О достижениях скромничает, но у него даже есть статья в Википедии. Завершить карьеру пришлось из-за состояния здоровья — в 34–35 лет.

После спорта встал вопрос: чем заниматься дальше? Вспомнил школьный интерес к алгоритмам и программированию — и выбрал тестирование. Переезд в Калининград и пандемия усложнили поиск работы, но Николай не сдавался. В итоге устроился в аутсорсинговую компанию, где работал с API и десктопом. За год вырос в зарплате и уверенности.

По совету брата подал резюме в 2ГИС — указал и спортивный опыт. Прошёл собеседования, удивился вопросу «о чём пожалеешь, если уйдёшь?». Сейчас тестирует мобильные приложения, влияет на процессы и ценит логику в работе. Удалёнка, гибкий график и возможность расти — всё это стало частью новой жизни. Тестировщик, по его словам, — это клей между идеей и реализацией.

Екатерина, тимлид в команде UGC (это я, автор поста)

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

Такое место оказалось буквально этажом выше — я перешла в рекламный отдел 2ГИС. От офис-менеджера до руководителя сервис-менеджеров — прошла весь путь бумажной работы. Но в какой-то момент стало слишком скучно. Внутренний голос всё настойчивее подсказывал, что мне нужно что-то другое, что-то по-настоящему увлекательное.

Так я пришла в тестирование. Прочитала описание позиции — и почувствовала: вот оно. То, что искала. Я сменила руководящую должность на стажёрскую, и, хотя поначалу было непросто, уже не представляла себя в другой роли. А сейчас я уже тимлид в QA!

Наталья, QA-инженер в команде WebAPI

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

Желание освоить нечто новое не отпускало, и Наталья решила разгадать тайну тех самых «палочек и отступов». Курс Python-разработчика стал отправной точкой. Освоив основы, она выбрала тестирование — здесь соединились её бухгалтерские навыки организации, педагогический опыт структурирования и технические знания.

Уже полгода Наталья в QA и уверена в своём выборе: тестирование стало для неё увлекательным миром поиска багов, неожиданных сценариев и постоянного совершенствования.

Почему захотелось поделиться этими историями? Потому что тестирование — не про «нажал кнопку — получил результат». Это про понимание, как думает пользователь, как работает система и где она может дать сбой. А значит, чем разнообразнее опыт — тем сильнее команда. Если у вас тоже был нетипичный путь в QA — расскажите!

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

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Tesla Model X поцарапала другую машину из-за активации опции автоматического открытия двери. Бортовая система заметила приближение владельца со смартфоном и сама распахнула ему водительскую дверь. Правда в этот момент владелец как раз проезжал мимо на второй машине - Mini Cooper. В итоге дверь Tesla Model X ударилась о кузов, а на обеих машинах остались царапины. Если бы не камера со дворе, то владельцу бы никто не поверил.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии4

«Сегодня мы запустили децентрализованную сеть для ИИ‑вычислений Cocoon («Кокон») — https://cocoon.org. Она обеспечивает пользователям 100% конфиденциальность при взаимодействии с ИИ. Часть запросов Telegram, связанных с автоматическим переводом сообщений, уже проходит через эту сеть. Разработчики получают доступ к вычислительным ресурсам по более низким расценкам, чем у централизованных провайдеров вроде Microsoft или Amazon. А владельцы видеокарт могут зарабатывать криптовалюту TON в реальном времени, подключая своё оборудование к сети Cocoon», — сообщил Павел Дуров.

Теги:
Рейтинг0
Комментарии1