TestGrow - pruebas de software

🛠️ ТЕСТИРОВАНИЕ УСТРОЙСТВ ЧЕРЕЗ COM/SERIAL ПОРТЫ: когда “всё подключено” не значит “всё работает” Последний месяц я ушёл с головой в новое направление: робототехника, микроконтроллеры, моторы, Bluetooth и всё, что связано с железом. Да, это не совсем про привычные API и UI-тесты, потому что это про тестирование устройств и сериал-подключений, где “отладка” часто означает не только запуск кода, но и поиск нужного пина на плате и проверку, не умер ли кабель 🔌 🤖 Сейчас я собираю своего робота: Arduino, моторы, драйверы, Raspberry Pi, Bluetooth-модуль и управление прямо с Mac через Python. Мало того, что всё это нужно собрать, так ещё и проверить, как всё работает. А работает… интересно. 🎯 Что важно тестировать при работе с COM/Serial-портами: 💬 Логика работы устройства: Передача через скрипты нужных команд, проверка их выполнения на стороне робота. Для тестирования я использую Python. Помимо самой логики есть еще ряд задач, на которые стоит обращать внимание. 📡 Настройка соединения ⁃ Baud rate, data bits, stop bits, parity, несовпадение хотя бы одного параметра может выглядеть как “пустой порт”, хотя физически всё в порядке. ⁃ Порт может быть занят другим процессом (например, IDE или другой скрипт), поэтому без корректной обработки это приведёт к зависанию или падению. ⁃ Таймауты (timeout, read_timeout) должны быть настроены с учётом особенностей устройства: где-то 100 мс хватает, а где-то нужно 3–5 секунд на ответ. ⁃ Некоторые устройства “просыпаются” только после открытия порта и требуют паузы перед первой командой (особенно Bluetooth). 📤 Передача данных ⁃ Команды должны быть отправлены в нужной кодировке (UTF-8, ASCII, HEX, зависит от устройства). ⁃ Ответ может приходить частями (по байту), и парсер должен уметь собирать его в полноценное сообщение. ⁃ Некоторые устройства используют протокол с контрольной суммой (CRC, XOR, длина + payload), поэтому проверка этих данных необходима. ⁃ Поддержка команд различной длины и формата: от фиксированной длины до строк с завершающим символом (\n, \r\n, 0x0D, ETX и т.д.). ⚠️ Стабильность ⁃ Физическое отключение устройства (кабель выдернули, батарея села). ⁃ Помехи и шум могут повредить данные. Нужно уметь определять и игнорировать “мусор”. ⁃ Буфер порта может переполниться, особенно если устройство шлёт много данных, а ты читаешь их слишком медленно. ⁃ Некоторые устройства “зависают”, если долго не получают команд. ⁃ Как система реагирует при быстром переподключении устройства (в течение секунды). Для тестировщика это значит, что важно понимание не только логики кода, но и особенностей железа, сигналов, напряжения. Ошибки могут быть в коде, а могут быть в проводе или микросхеме. Или в том, что ты просто забыл вставить перемычку на драйвере, или использовал не те коннекты для питания или заземления (да, у меня так было 🙃). Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

PATH И QUERY ПАРАМЕТРЫ В REST API: В ЧЁМ РАЗНИЦА И КАК ТЕСТИРОВАТЬ? Пару недель уже провожу собеседования на тестировщика с опытом и пониманием API тестирования и не знаю, почему так, но пока еще ни один из кандидитов не ответил нормально на вопрос “Что такое path/query параметры в API?”. Поэтому решил выложить отдельный пост на эту тему. Итак, path и query параметры — это принципиально разные способы передачи данных в API, которые имеют различное назначение и требуют разных подходов к тестированию. Path параметры - это часть URL, которая идентифицирует конкретный ресурс: ⁃ /users/{id} - где {id} это path параметр ⁃ /orders/{orderId}/items/{itemId} - здесь два path параметра Query параметры - это дополнительные параметры после знака "?" для фильтрации, сортировки, пагинации: ⁃ /users?age=25&city=Moscow ⁃ /products?sort=price&limit=10&page=2 В итоге, если вы посмотрите внимательно на логику REST API, то можете заметить, что path параметры определяют что мы запрашиваем, а query параметры — как мы это делаем! Что это значит для тестирования? Главное, что подходы к проверке path и query параметров отличаются. Для path параметров тестируем: - Валидные и невалидные ID - Несуществующие ресурсы - Некорректные форматы (строка вместо числа) - Спецсимволы и кодировка Для query параметров проверяем: - Работу каждого параметра отдельно и в комбинации - Граничные значения - Некорректные значения, например, для сортировки - Пустые и отсутствующие параметры - Влияние на производительность при больших данных в ответе В общем сохраняйте себе и если вам зададут такой вопрос, то вы точно сможете ответить. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

🚀CI/CD ДЛЯ ТЕСТИРОВЩИКА: ЧТО НУЖНО ЗНАТЬ О DEVOPS? Всем привет! Вчера на собеседовании кандидат рассказывал, как полгода изучал Kubernetes, чтобы соответствовать требованиям продвинутого тестировщика в расширенным техническим бэкграундом. В итоге, кандидат конечно хорошо знает теорию про поды и сервисы, но не может настроить простейший запуск автотестов в GitLab CI. 💡 DevOps, это не про изучение всех инструментов разом. На самом деле это про решение конкретных задач тестирования более эффективно. В основном инстурменты DevOps могут использоваться в автоматизации или нагрузочном тестировании, но иногда и в ручном тестировании с ними можно столкнуться. 🎯Что желательно знать тестировщику: Умение читать и модифицировать pipeline конфиги, чтобы добавить свои автотесты или изменить параметры запуска. Понимание этапов сборки, а именно, где запускаются юнит-тесты, где интеграционные, где UI-тесты, как посмотреть результаты. Работа с артефактами — как сохранить отчёты тестов, скриншоты падений, логи для дальнейшего анализа. Базовые команды Docker — запустить контейнер с тестами, пробросить порты, смонтировать папки. ⚠️ В большинстве случаев остальные знания уже приобретаются по потребности в зависимости от проекта, например, изучать Kubernetes нужно только если ваши тесты реально там запускаются. Мониторинг и алертинг (например через prometheus и Grafana), только если вы отвечаете за стабильность тестовых стендов, а инфраструктуру как код, если участвуете в создании тестовых окружений. 🗣️ Мое мнение, что начинать нужно с задач, которые есть прямо сейчас. Нужно автоматизировать деплой тестовых данных? Изучите соответствующие инструменты. Тесты падают из-за нестабильности окружения? Разберитесь с мониторингом. DevOps для тестировщика — это не про статус и знания, а про эффективность работы. Лучше знать на практике 3-4 инструмента, чем поверхностно 20. Какие DevOps инструменты используете в работе?👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет! Недавно в десктоп-приложении от Anthropic для AI моделей Claude появилась возможность напрямую подключать различные MCP-коннекторы для получения информации из разных источников. В пятницу я решил посмотреть, насколько хорошо они работают. Моя цель заключалась в том, чтобы Claude AI с нуля написал проект автоматизации тестирования для моего проекта Store Manager (на базе Pytest и Playwright) на основе документации и описания ручных регрессионных тестов. Вот что получилось. За пару часов Claude полностью создал структуру проекта и не просто базовую, а модульную: с вынесенной core-функциональностью, расширенным логированием, клиентами для работы с API и базой данных. Также были реализованы утилиты, хелперы, генератор тестовых данных, интеграция с CI/CD и динамическая настройка переменных окружения. Уже через 2 часа, после 3–4 итераций небольших правок (например, улучшение логирования, пара багфиксов, переработка общих шагов для переиспользования в тестах и другие мелочи), у меня были полностью готовые автоматизированные тесты по моим ручным регрессионным сценариям - всего получилось 29 API-тестов, которые я успешно запустил и получил корректный результат выполнения. Что я использовал: - Подключил MCP-коннектор к Google Docs, откуда подтянулись требования к релизу и ручные регрессионные тесты (выгрузил просто из TestIT). - Подключил MCP-коннектор Filesystem для полного доступа Claude AI к проекту автоматизации. Я не написал ни одной строки кода — код писался прямо в проект автоматически. - В контексте проекта я указал, как должна выглядеть структура проекта по автоматизации тестирования. - Также планировал автоматизировать UI-тесты, но коннектор подключения к Google Chrome работал нестабильно, как итог не удалось получить селекторы. Скорее всего, проблема была на стороне самого коннектора, надеюсь, это скоро поправят. Итог: Работу, которую раньше выполнял синьор-автоматизатор примерно за неделю, Claude сделал за 2 часа, пусть и без UI-тестов. В целом я мог бы выполнить JS для сбора селекторов с HTML-страницы и Claude AI сам бы разобрался и написал UI-тесты, но это потребовало бы моего прямого вмешательства, чего я хотел избежать. Поэтому, как я уже говорил не раз: будущее точно за AI в ИТ-профессиях. Те, кто готов меняться и интегрировать ИИ в свою работу, добьются больших успехов. Если вы еще не пробовали использовать AI как ассистента в своей работе, то настоятельно рекомендую начать. Уже сейчас AI способен решать довольно сложные задачи за пару часов, на что раньше уходила неделя. Если интересна данная тема, то еще больше про работу с AI и его тестировании рассказываю на канале @testingofai Полезная информация: Курс по evaluation AI | С чего начать изучение AI | Инструменты для оценки AI

QA В СТАРТАПЕ VS QA В КОРПОРАЦИИ: ГДЕ ЛУЧШЕ? Всем привет! Сегодня я хочу поделиться с вами своим мнением касательно выбора между работой в стартапе и корпорации тестировщиков, в том числе рассказать вам мою точку зрения касательно встречающейся достаточно часто истории, что в стартапах можно быстрее вырасти профессионально. Так вот, начать я хочу с того, что стартап и корпорация - это две принципиально разные среды для развития тестировщика, каждая из которых даёт уникальные возможности и имеет свои ограничения. В итоге, если вы посмотрите внимательно на задачи тестировщика в стартапе и то, чем занимается он в крупной компании, то можно заметить, что в стартапе скорее всего вы будете универсалом, который делает всё подряд, а в корпорации экспертом в конкретной области! В стартапе вы получите: • Широкий спектр задач: от мануального тестирования до возможности настройки CI/CD и автоматизации • Возможность влиять на процессы • Быстрое принятие решений и короткие циклы разработки • Возможно прямое общение с основателями и пользователями • Опыт работы в условиях ограниченных ресурсов и жестких дедлайнов В корпорации вас ждёт: • Структурированные процессы и чёткие стандарты • Глубокая специализация в конкретных областях, но часто более шаблонная работа (например, только тестирование UI) • Менторство от опытных коллег • Стабильность и предсказуемость (включая и финансовую) • Доступ к современным инструментам и технологиям (включая платные) Парадокс в том, что стартап даёт больше свободы, но меньше экспертизы, и очень часто бывает, что в принципе экспертизу в стартапе растить вам нужно самим, потому что помощи просто не от куда взять, а в корпорации наоборот. В стартапе вы можете стать “мастером на все руки”, но рискуете упустить глубину знаний, которую даёт специализация в большой компании. Именно поэтому я всегда склонен говорить, что идеальный путь - это комбинация: начать в корпорации для получения фундаментальных знаний и процессов, а затем попробовать стартап для расширения горизонтов, потому что только сочетание структурированного подхода и предпринимательского мышления даёт максимальную гибкость в карьере тестировщика. А где начинали вы свой путь в QA? Что бы посоветовали новичкам? 👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет! Кто давно читает мой канал, возможно знает, что вот уже больше 3 лет я живу в Черногории с семьей и мы переехали сюда по моей работе. Но сегодня хочу немного отойти от темы тестирования и рассказать про канал моей жены. Это не реклама ради рекламы — это действительно интересный и искренний блог, который заслуживает внимания. Лиза делится своей жизнью в Черногории, привычками, взглядами на системность и самоорганизацию. Несмотря на то что её деятельность далека от ИТ, я сам многому у неё учусь — в том, как она умеет ставить цели, планировать, не теряться и сохранять баланс. Поэтому, если хочется немного разбавить ИТшные каналы и вам интересна тема переезда, адаптации в новой стране, а ещё — как всё успевать и не выгорать (в том числе в учёбе и работе), обязательно загляните на её канал: 👉 @liza_proballet Уверен, вам понравится!

НА ЧТО СТОИТ ОБРАЩАТЬ ВНИМАНИЕ ПРИ ТЕСТИРОВАНИИ РАЗЛИЧНЫХ МЕТОДОВ REST API? Разберем типичные примеры тестов для основных методов: GET: Получение данных по валидному ID; Получение данных по несуществующему ID; Получение данных по невалидному ID (некорректный формат); Проверка пагинации (limit, offset, page); Проверка фильтрации и сортировки данных; Проверка поиска по различным параметрам; Получение данных при валидном/невалидном токене; Проверка кэширования данных. POST: Заполнение/незаполнение обязательных полей; Заполнение данных в различных вариациях (вспоминай классы эквивалентности); Заполнение на граничных значениях по количеству символов; Заполнение полей на недопустимые символы; Отправку пустого JSON; Проверка даты создания объекта; Особое внимание надо уделить передаваемому изображению и его параметрам (если оно есть в запросе); Можно протестировать URL самого запроса и его тип. Что будет, если сделать запрос через http, а не через https? А если изменить POST на GET и т.д; Проверка работы запроса при валидном/невалидном токене. PUT: Полное обновление объекта со всеми обязательными полями; Обновление с пропущенными обязательными полями; Обновление несуществующего объекта; Проверка типов данных во всех полях; Проверка граничных значений для всех полей; Проверка неизменяемости системных полей (ID, timestamps); Проверка работы запроса при валидном/невалидном токене. PATCH: Изменение данных во всех доступных полях согласно ТЗ; Проверку изменения пустого значения на валидное значение; Проверку поля на граничные значения и возникновение ошибок в случае добавления символов больше или меньше разрешенных; Проверку изменения полей на недопустимые символы; Проверку изменения данных в полях на неверные типы данных (там, где числа буквы и т.д.); Неизменяемость данных в полях, где это недоступно; Частичное обновление (когда в твоем JSON присутствуют не все заполненные поля); Проверка работы запроса при валидном/невалидном токене. DELETE: Удаление существующего объекта; Удаление уже удаленного объекта; Удаление по несуществующему ID; Удаление по невалидному ID; Удаление и повторное добавление такой же сущности (если есть уникальные поля); Проверка каскадного удаления связанных объектов; Проверка работы запроса при валидном/невалидном токене. HEAD: Проверка существования ресурса без получения тела ответа; Проверка метаданных ресурса (размер, тип контента); Проверка кэширования заголовков. OPTIONS: Проверка разрешенных методов для конкретного endpoint; Проверка CORS заголовков; Проверка политик безопасности API. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

ТЕСТИРОВЩИК VS ПОЛЬЗОВАТЕЛЬ: КТО ЛУЧШЕ НАЙДЁТ БАГИ? Всем привет! Сегодня я хотел бы поделиться с вами своим мнением касательно встречающейся достаточно часто ситуации, когда пользователи находят критичные баги в первый день после релиза. Почему так происходит? Начать я хочу с того, что тестировщик и пользователь находят баги принципиально по-разному, и каждый подход имеет свои сильные и слабые стороны, которые дополняют друг друга. В итоге, если вы посмотрите внимательно на подход тестировщика и поведение реальных пользователей, то можете заметить, что мы тестируем системно и методично, а пользователи — хаотично и непредсказуемо! Что это значит? Главное, что тестировщики, следуя логике и процессам, по факту ограничивают себя рамками ожидаемого поведения, в то время как пользователи делают то, что мы никогда не предугадаем, а именно, они не читают инструкции, комбинируют действия самым неожиданным образом и используют систему не по назначению. Парадокс в том, что чем лучше мы знаем систему, тем хуже можем её протестировать с точки зрения пользователя, потому что мы "заточены" под тестирование логики, описанной в документации. Пользователи же смотрят на продукт свежим взглядом и находят то, что мы считали невозможным. Именно поэтому я всегда склонен говорить, что хорошее тестирование - это симбиоз профессионального подхода и "наивного" взгляда пользователя (или можно сказать исследовательского тестирования), потому что только сочетание системности и непредсказуемости даёт максимальное покрытие возможных сценариев использования продукта. Согласны или нет с таким подходом?🤔 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет. Два года назад я уже выкладывал подборку инструментов для генерации тестовых данных, но за это время часть инструментов устарели или стали недоступны, поэтому я решил обновить ее. Теперь ниже новая подборка инструментов, которые точно облегчат работу тестировщику в части работы с данными и их генерации. Сохраняй и пользуйся! Pinetools Поддерживает генерацию 50 различных форматов, также дает возможность генерировать файл со своим уникальным форматом. Может генерировать большие файлы в GB. Mockaroo Позволяет создавать до 1 000 строк бесплатно (ограничение фри‑плана) в форматах CSV, JSON, SQL и Excel, при подписке — до миллионов записей. GenerateData Механизм для генерации произвольных данных в любом формате. Работает более чем с 30 типами данных плюс около 32 наборов данных для конкретных стран FillDB Простой бесплатный генератор для MySQL‑баз. Позволяет загрузить ваш schema‑файл или SQL‑дамп, автоматически подбирает типы данных по названию колонок Fakefilegenerator Еще один отличный генератор файлов с нужным весом в байтах. Генерирует такие форматы, как doc, docs, xls, xlsx, MP3, JPEG, PDF, ZIP. Ограничение по весу файла до 10 MB. Blindtextgenerator Простой и понятный генератор текста. Может генерировать текст по количеству слов или символов. Randat Бесплатный онлайн-инструмент, который позволяет сгенерировать таблицу со случайной личной информацией: имя, возраст, профессия, зарплата и т.д. 10minutemail Классный сервис по генерации временной почты для тестирования. Почта действует 10 минут и позволяет Вам получать все сообщения на нее. DeepSeek, ChatGPT, Claude, Gemini и другии LLM модели отлично могут генерировать тестовые данные при правильном промпте и постановке задачи. В моей статье, посвященной промпт инжинирингу для тестировщика, вы найдете примеры промптов для генерации тестовых данных. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний