TestGrow - software testing

ПРОБЛЕМА КРИВЫХ ДАННЫХ: КОГДА САМА ТЕСТОВАЯ БД ЛОМАЕТ ТЕСТИРОВАНИЕ Всем привет! Сегодня хочу поднять тему, с которой я регулярно сталкиваюсь в рамках моего проекта по практике для тестировщиков Store Manager. Речь про кривые данные и неконсистентость в тестовых базах. Что это значит? Кривые данные - это записи в БД, которые не соответствуют текущей бизнес-логике или нарушают валидацию. Они могли попасть туда случайно, из старых тестов или при тестировании валидации, но итог один: тестирование ломается и возникают ошибки. Например, - В таблице пользователей сохранены email без «@», и после обновления валидации логин перестаёт работать. - В заказах у части записей отсутствует обязательное поле валюта, в итоге UI падает, когда пытается отрендерить сумму, а получает, например, 500 ошибку от бекенда. - В связке заказ–товар в БД есть ссылки на несуществующие товары и на фронте ничего не отображается. и так далее, ситуаций может быть много. Почему это ломает тестирование? Тестировщик находит баг, который как ему кажется связан с системой, а на самом деле, просто данные некорректны в БД, например, в прошлом релизе тестировщик проверял валидацию полей, завел кучу неправильных данных для негативных тестов, они сохранились в БД, а на новом релизе, где валидацию пофиксили, система начинает отбраковывать старые записи, но выглядит это как будто система сломалась. И главное, на такие ошибки тратится время на их расследование и локализацию, которые на самом деле не баги кода, а мусор в данных. Что я тут советую делать: 1. Всегда проверять, с какими данными работаете (соответствуют ли они правилам валидации). 2. Всегда проверять дефекты относительно корректности тестовых данных 3. Для воспроизведения багов лучше создавать свежие тестовые данные, а не полагаться на старые. Часто проблема кривых данных сложнее, чем сам баг в коде. Потому что она искажает картину. Тестировщик ищет ошибку там, где её нет. В моём проекте я регулярно вижу, как это сбивает новичков, потому что кто-то проверяет новый сценарий, а система не работает просто потому, что старые данные не проходят обновлённую валидацию. Поэтому никогда не забываем, что тестовые данные - это не просто то, что вам нужно для прохождения тестов, это еще и сущность, которую нужно регулярно валидировать и проверять перед тестированием. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

18 сентября — митап YADRO для QA-инженеров! 📍 Санкт-Петербург, Loft Hall и онлайн 🕕 Начало в 19:00 | 🎫 Участие бесплатное В программе: — QA-практики в YADRO (Михаил Саравайский). — Тестирование систем хранения данных: от RAID до автоматизации (Артём Хюппенен, YADRO). — Интеграционные тесты глазами разработчиков: опыт облачной платформы MWS Cloud Platform (Эдгар Сипки). — Финальный доклад от экспертов YADRO (Владимир Авдеев и Полина Ященко). Офлайн-формат: демозона, стенды с «железом», квесты, подарки, afterparty. 👉 Регистрация уже открыта, количество мест ограничено.

Всем привет! Хочу поделиться с Вами важной информацией, что в сентябре я запускаю 2 новых учебных потока на два моих курса: 1. Оценка и тестирование ИИ, где мы в теории и на практике будет изучать проведение оценки искусственного интеллекта, начиная с классического машинного/ глубокого обучения и заканчивая мультимодальными ИИ системами, агентами, тестированием безопасности и много чего еще. Для курса я подготовил большое количество проектов (реальных ИИ систем), на которых вы будете отрабатывать практически различные техники тестирования. Старт курса 08.09, группа уже набрана, но есть еще последняя возможность попасть на поток! 2. Запускаю второй поток в этом году (и 6-й в общем) на курсе тест-менеджменту и управлению тестированием для тестировщиков с опытом тестирования. Это мой уникальный курс, потому что мы не изучаем теорию тест-менеджмента, а на практике разбираем различные ситуации, включая также ваши проекты. Более того, последней месяц посвящен только индивидуальной работе меня с каждым учеником в рамках вашей текущей компании, где мы можем проработать различные вопросы и проблемы внутри тестирования вашей компании, найти оптимальные решения именно для ваших процессов и для вас, как тестировщика или менеджера. Старт нового потока 16.09. Поэтому если у вас есть желание развиваться, то оставляйте заявку на один из курсов: На курс по оценке и тестированию ИИ оставить заявку можно на сайте eval-ai.com На курс по тест-менеджменту оставить заявку можно на сайте edu-testing.com или просто написать мне личное сообщение @al_meshkov Каждое обучение — это инвестиция не только в карьеру, но и в себя. Давайте расти вместе! Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

#Реклама Попробуйте свои силы в программировании! Бесплатный мини-курс по Data Science подходит для любого уровня подготовки — то, что нужно для старта. Вас ждут 4 задания для отработки знаний на практике, полезные материалы и подарки. В программе — знакомство с профессиями в Data Science и практика: — Поймёте разницу между профессиями в Data Science (аналитик, инженер, ML-специалист) — Освоите основы Python и напишете свой первый код — Узнаете, как применять нейросети в реальной работе, в том числе для автоматизации задач — Научитесь визуализировать данные, как это делают в IT-компаниях Практика: создадите свою нейросеть для поиска новостей и чат-бота на Python, который отвечает с помощью нейросети. Бонусы для участников: — Доступ к конференции по нейросетям — Тестовый доступ к одной из профессий — 5 чек-листов для старта — Скидка 10 000 ₽ на любой курс Skillbox Пройдите простой тест и получите доступ к мини-курсу бесплатно: Ссылка скрыта

ГОЛЫЕ API БЕЗ ДОКУМЕНТАЦИИ: КАК ТЕСТИРОВЩИК МОЖЕТ ИССЛЕДОВАТЬ ИХ ЧЕРЕЗ NETWORK-ТРАФИК Всем привет! Одна из самых частых и болезненных ситуаций для тестировщика, когда есть API, но нет документации. Swagger не завезли, Confluence пустует, разработчик в отпуске, а функционал уже нужно проверять. Что делать? Сидеть и ждать документацию — плохая стратегия. В реальности тестировщик часто становится исследователем. С чего начать: 1. Network-трафик Открываем DevTools - вкладка Network. Делаем действия в UI и смотрим, какие запросы летят: метод (GET/POST/PUT/DELETE), урлы, тело запроса, коды ответа. По паттернам можно догадаться, какие эндпоинты за что отвечают. 2. Параметры и тела запросов Если видим POST /user/login, то по телу запроса легко понять, что нужно: username, password. Иногда можно заметить лишние поля, которые UI не использует. Это подсказка о скрытом функционале. 3. Коды ответов и ошибки Даже без документации API подсказывает само: 400 Bad Request - что-то не так в теле запроса. 401 Unauthorized - нужен токен. 404 - эндпоинт не существует или нет доступа. 200/201 - успешные кейсы. 4. Форматы данных Чаще всего это JSON. Если в ответе приходит объект, можно собрать пример схемы прямо руками. 5. Метод проб и ошибок Меняем параметры запроса и смотрим реакцию API. Иногда удаётся найти скрытые поля или дополнительные флаги (например, isAdmin=true). 6. Инструменты-помощники Экспортируем запрос из DevTools в Postman и гоняем вариации. Используем Charles/Fiddler, если нужно перехватить и подменить данные на лету. Такое умение исследовательски подойти к проверке API важно, потому что: ⁃ Тестировщик может начать проверять функционал раньше документации. ⁃ Можно находить баги на стыке: например, UI отправляет 3 параметра, а API ждёт 5. ⁃ Иногда через такие исследования тестировщик находит лишние методы, которые не должны быть доступны пользователю (и это уже критика для команды). Отсутствие документации - это не тупик. У тестировщика есть инструменты и любопытство, чтобы раскопать API. И чем раньше это сделать, тем быстрее команда поймёт, где у них проблемы и несогласованность. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет! Две недели назад писал пост про мое новое хобби по сборке робота (первый пост тут) и сегодня хочу поделиться промежуточными результатами. В целом процесс движется, за две недели мне удалось установить на него камеру, подключить YOLO модель для распознавания изображений, сделать второй уровень конструкции, собрать и сломать роборуку, установить датчики температуры, трёхосевые акселерометр и гироскоп и в целом чем дальше я иду, тем больше сталкиваюсь с различными трудностями, которые нужно решать. Какие сложности были за эти две недели: 1. Я понял, что из простых дешевых деталей собрать нормально работающего робота оказалось достаточно сложно, поэтому пришлось заказывать новые моторы на колесах (потому что обычные DC моторы не могут ездить медленно), также заказывать новый драйвер для управления моторами колес, который поддерживает медленную скорость. 2. Была попытка установить энкодер AS5600 на колеса, чтобы считывать угол наклона колеса и сделать возможность для робота держать постоянно одинаковую скорость, в итоге провозился пару вечеров из-за того, что энкодер работает очень плохо и при даже минимальном наклоне сразу начинает показывать неправильно углы, в итоге этот энкодер в мусорку, решение, купить сразу мотор с энкодером. 3. Омниканальный микрофон INMP441 оказался тоже слишком слаб, чтобы улавливать команды на расстоянии, в итоге заказал нормальный (как я думаю) омниканальный микрофон для конференций. 4. Понял, что без нормального обучения модель YOLO плохо распознает элементы на видео, теперь мне предстоит самостоятельно обучить модель по фотографиям квартиры, чтобы робот понимал что вокруг него вообще происходит) 5. Снизил вес робота за счет замены 12 аккумулятора на батарейки 18650, теперь он ездит получше и пошустрее. 6. Ну и написал веб приложения для управления им, там тоже было много проблем с камерой и стримминга видео, но в итоге удалось все успешно решить. Какие планы дальше? Обучать модель компьютерного зрения на распознавание элементов в квартире, нужно сделать примерно 500 снимков с робота, разметить их и обучить модель распознавать вещи. Ну и также приступаю к написанию голосового ИИ агента, который на первом этапе научиться нормально общаться и понимать команды. Пока в общем так, надеюсь в ближайшем будущем смогу вам показать уже работающуу версию робота. Если вам интересно дальше читать посты о создании собственного робота, ставьте 👍

YADROxSPRINT OFFER: оффер QA Automation Engineer за 3 дня 🚀 Хотите присоединиться к команде, создающей телеком-решения для беспроводных мобильных сетей, и получить оффер за 3 дня? 💡 Как это работает: 1️⃣ Отправьте заявку до 7 сентября и пройдите HR-скрининг. 2️⃣ Пройдите техническое и менеджерское интервью. 3️⃣ Получите оффер в течение 3 дней. Что вас ждёт: 🚀 Автоматизация тестирования с использованием Python+PyTest. 🚀 Разработка и поддержка автотестов. 🚀 Интеграция автотестов с CI/CD и тестовыми окружениями. Кого мы ждём в команду YADRO? Инженеров QA Automation (Junior/Middle/Senior) с опытом работы в автоматизации тестирования от 2 лет и уверенным знанием Python. Желателен опыт с Linux и пониманием сетей, базирующихся на TCP/IP. 💙 Отправляйте заявку до 7 сентября и станьте частью команды YADRO!

ПОЧЕМУ КЭШ БРАУЗЕРА МОЖЕТ ЛОМАТЬ ТЕСТЫ СИЛЬНЕЕ, ЧЕМ БАГ В КОДЕ Всем привет! Сегодня хочу поднять тему, которая скорее всего знакома каждому ручному тестировщику, но далеко не всегда осознается как настоящая проблема. Речь про кэш браузера. Мы привыкли думать, что кэш - это чисто про ускорение работы сайта. Но в реальности именно он часто становится источником таких багов, которые вводят тестировщика в ступор сильнее, чем настоящие ошибки в коде. Почему так происходит? Для начало важно понимать, что браузер кэширует: ⁃ статические файлы (JS, CSS, картинки), вы видите старую версию интерфейса, даже если код давно обновили; ⁃ API-запросы, данные подтягиваются из кэша, а не с сервера; ⁃ куки и токены, можно получить странное поведение при логине/логауте. В итоге тестируется не продукт, а сборная солянки из нового кода + старого кэша. Пару примеров из практики: ⁃ После релиза верстка ломается только у тестировщика, в итоге, оказалось, что браузер тянул старый CSS. ⁃ Новый функционал не появляется, хотя разработчик клянётся, что всё выкатили, в итоге, у тестировщика в кэше старая версия JS. ⁃ Пользователь жалуется на зависший аккаунт, оказалось, кэш подтягивал просроченный токен. Что с этим делать: 1. Перед тестированием чистить кэш/куки (или открывать в режиме инкогнито). 2. Знать про горячие клавиши: Ctrl+Shift+R (Windows) или Cmd+Shift+R (Mac) для жесткой перезагрузки браузера с очисткой кеша (работает для Chrome) 3. Следить, как настроен кэш на сервере (заголовки Cache-Control, ETag, Expires). Иногда виноват не браузер, а конфигурация. 4. Использовать DevTools, вкладка Network, Disable cache. Как итог, хочу сказать, что кэш браузера может доставить тестировщику много хлопот. Он часто маскируется под баг кода, но на деле ломает воспроизводимость, вводит в заблуждение команду и тратит часы на расследование. А у вас бывало, что после трёх часов охоты на баг оказывалось, что виноват просто кэш? 👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

🔥 Устал прописывать тест‑кейсы на десятки страниц и разбирать мутные ТЗ? «Почему я всё ещё делаю это вручную, если есть ИИ?» Ссылка скрыта Представь, что рутину закрывает нейросеть, а ты берёшь интересные задачи. Я собрал это в практический курс «Тестируем с ИИ» — для начинающих и опытных тестировщиков. Что меняется после курса: - непонятные задачи от разрабов — разбираешь за минуты - валидация доки аналитиков — без боли, по чек‑листам - чек‑листы, тест‑кейсы и тест‑план — по готовым промтам - макет vs реализация — быстрое сравнение -быстрый старт автотестов: фронт и API Мини‑кейсы: «Кривая» Jira‑таска: ИИ выделил неполноту требований, дал 10 уточняющих вопросов, собрал риски и Acceptance Criteria за 12 минут вместо 1–2 часов Тест‑кейсы: ~5 часов за 35–50 минут по промт‑матрице (позитив/негатив, граничные, локализация, безопасность) Документация: конфликтующие версии ТЗ сведены в единую спецификацию с пометками спорных мест — минус 2–3 часа на ревью Внутри курса: - готовые промты под все типовые QA‑задачи - практические сценарии «копируй и применяй» - экономия 30 000₽+ на ИИ‑сервисах за счёт альтернатив и лайфхаков - инструменты для ручного и автотестирования Автор курса: Дима Алексеев — 5+ лет в QA, занимаюсь ручным и авто‑тестированием. Веду канал @qa_road_channel 💰 Цена всего 4990 2900 рублей ко дню знаний (чтобы увидеть цену нужно перезапустить бота через команду /start)) ⚡ Один вечер обучения = недели сэкономленного времени Старт здесь: @qa_road_bot 🎯