7118
Присоединяйтесь к нашему каналу и погрузитесь в мир тестирования Связь: @devmangx
Куда расти QA-инженеру на каждом грейде: подробный гид
Статья Максима Белопросова на Хабре — это подробный гид по карьерному росту QA-инженера на каждом уровне: от стажёра до синьора
👉 Читать
👉 @QAPortal
JetBrains закрывает IDE Aqua для тестировщиков
Публичный выпуск IDE состоялся в мае 2024 года, но инструмент оказался невостребованным
Aqua больше не будет развиваться как отдельный продукт, её функциональность сохранится в виде плагина Test Automation, совместимого с другими IDE от JetBrains
👉 @QAPortal
Не всегда вопросы на интервью по базам данных ограничиваются только селектами и джоинами.
Рекомендую следующий материал, чтобы разобраться с более тонкими материями по SQL.
👉 @QAPortal
Если вы готовитесь к интервью на английском языке или просто изучаете тестирование на нем, то на данном сайте вы сможете найти большое количество материалов для самопроверки
https://www.guru99.com/v-model-software-testing.html
👉 @QAPortal
Тестирование на примере молотка и гвоздя
👉 @QAPortal
Нашел для вас одну из самых детальных шпаргалок по SQL.
В комплекте: диаграммы соединений, команды, фразы с примерами и более углубленные темы SQL.
👉 @QAPortal
Регрессия против Sanity — или, может, вообще Smoke?
В целом, всё вроде бы понятно: Smoke — это Smoke, Regression — это Regression, а что же тогда Sanity?
Или, возможно, не всё так однозначно? Ведь знать определения — это одно, а эффективно применять их в разных ситуациях — совсем другое.
Быстро пробежимся по терминологии:
🔹 Smoke Testing — это поверхностная проверка основных (критически важных) функций продукта.
🔹 Regression Testing — это проверка того, что новый функционал или исправления багов не сломали уже существующий функционал. Это не всегда полное тестирование всего продукта — можно ограничиться только теми частями, которые потенциально могли быть затронуты изменениями.
🔹 Sanity Testing — это проверка конкретного модуля после изменений, чтобы убедиться, что именно эта часть работает как ожидается.
🔹 Re-test — это повторное тестирование конкретного бага или тикета после его исправления.
Теперь разберёмся, когда всё-таки нужно делать регрессию, а когда достаточно Sanity?
Представим, что у нас следующая иерархия тестовых сред:
dev → staging → prod
Сценарий 1: Новая фича затрагивает много функционала на сайте
🔹 Staging: проводим полную или частичную регрессию в зависимости от масштаба изменений
🔹 Prod: smoke + поверхностная проверка новой фичи на проде
Сценарий 2: Новая фича полностью изолирована от остального функционала
🔹 Staging: smoke + проверка новой фичи
🔹 Prod: smoke + проверка новой фичи на проде
Сценарий 3: Выкатываем изменения в уже задеплоенную фичу, изолированную от остального функционала
🔹 Staging: здесь идеально подходит Sanity Testing
🔹 Prod: smoke — этого достаточно
Конечно, у всех этих сценариев есть множество «но».
Если у вас релизы проходят стабильно и почти не бывает инцидентов — можно обойтись даже без smoke.
Если наоборот — часто что-то ломается, без полной регрессии лучше не рисковать.
Есть автотесты? Тестируйте вручную только то, что они не покрывают.
Главная мысль:
Регрессия — не универсальный ответ на всё. Не всегда нужно тратить дни на проверку всего продукта, если изменения точечные. Но и излишнее доверие к smoke может сыграть злую шутку — особенно если ты не до конца понимаешь, что именно проверяешь.
Золотая середина — это понимание контекста изменений и выбор подходящего типа тестирования.
Итог:
🔹 Smoke → Работает ли продукт вообще?
🔹 Regression → Не сломался ли старый функционал после изменений?
🔹 Sanity → Работает ли конкретная часть после изменений?
🔹 Re-test → Исправлен ли конкретный баг?
👉 @QAPortal
Освой сети и командную строку с лучшими обучающими каналами
🤩 Network Admin - обучающий канал по сетевым технологиям
🤩 Network Admin | Guides - канал, где рассказывают полезную информацию про Windows/Linux
📱 BashTex - обучение работе с командной строкой
100 тест-кейсов для страницы регистрации
Страница регистрации – это не просто форма для создания учетной записи пользователя. Это тщательно продуманный процесс, который обеспечивает защиту бекэнда, соответствие стандартам конфиденциальности и безопасности, а также проводит проверку пользователей перед предоставлением определенных прав доступа к сервисам.
👉 Читать
👉 @QAPortal | #cтатья
Многопоточность в мобильных приложениях: руководство для QA-инженеров
В этой статье о том, как приложение работает «под капотом», что такое многопоточность, какие потоки бывают, и какие ошибки, связанные с реализацией многопоточности, могут возникать в приложении.
👉 Читать
👉 @QAPortal | #cтатья
И все это за 5 минут до релиза
👉 @QAPortal
Топ-9 инструментов для тестирования REST API
🔹 Postman — универсальный инструмент для разработки и тестирования API. Поддерживает автоматизацию, создание коллекций запросов и работу с окружениями.
🔹 Insomnia — легковесный инструмент с простым UI для тестирования REST API. Поддерживает скрипты, окружения и автоматизацию.
🔹 Swagger — инструмент для документирования и тестирования API на основе OpenAPI спецификаций. Позволяет генерировать запросы и выполнять их напрямую из интерфейса.
🔹 SoapUI — решение для функционального и автоматизированного тестирования REST и SOAP API. Подходит для сложных сценариев.
🔹 Katalon Studio — мощный фреймворк для автоматизированного тестирования API с поддержкой CI/CD и широкими возможностями по работе с запросами и валидацией ответов.
🔹 JMeter — инструмент для нагрузочного тестирования, также поддерживает функциональное тестирование REST API.
🔹 Rest Assured — Java-библиотека для написания автотестов REST API. Используется совместно с тестовыми фреймворками (JUnit, TestNG).
🔹 Hoppscotch — лёгкий веб-клиент с открытым исходным кодом для тестирования REST API, акцент на скорость и удобство.
🔹 HTTPie — CLI-инструмент для интерактивного тестирования API. Упрощает выполнение HTTP-запросов и визуализацию ответов.
👉 @QAPortal
Измерение покрытия API тестами на основе Swagger для Python
В этой статье автор расскажет про инструмент swagger-coverage-tool — решение для автоматического измерения покрытия API автотестами на Python.
👉 Читать
👉 @QAPortal | #cтатья
Что такое CIDR-блок
Для начала нужно вспомнить, что такое IP-адрес и из чего он состоит.
🔹IP-адреса — это уникальные адреса устройств в сети, как адреса домов в городе
Каждый IP-адрес (IPv4) состоит из 4 октетов, разделённых точками.
Один октет = 8 бит. В сумме IP-адрес IPv4 содержит 32 бита.
Пример: 192.168.1.0
1-й октет — 192
2-й октет — 168
3-й октет — 1
4-й октет — 0
192.168.1.0 до 192.168.1.255.192.168.1.0/24.192.168.1.0 до 192.168.1.255 принадлежат одной сети, и мы используем одну запись (192.168.1.0/24), чтобы описать весь диапазон.192.168.1.50 и маска подсети 255.255.255.0, то первые три октета (192.168.1) указывают на сеть, а последний октет (50) — на конкретное устройство в этой сети (хост).255.255.255.0
Это — самая распространённая маска, соответствующая CIDR-обозначению /24.
192.168.1.0/24), и проверка блокировки доступа с IP вне этого диапазона.X-Forwarded-For в Postman для симуляции разных IP-адресов.
Краткая шпаргалка по запросам REST API на русском языке.
Внутри: GET/POST/PUT/PATCH/DELETE, заголовки запросов, коды ответов сервера с обозначением и другие полезные вещи.
👉 @QAPortal
Принципы тестирования с примерами
"Чтобы среди множества проверок, которые приходят нам в голову, выбрать самые критичные, составить грамотную стратегию тестирования, не упустить важные аспекты программы и избежать ненужных проверок нужно ориентироваться на 7 принципов тестирования"
Хороший тест, но не повторяйте дома
👉 @QAPortal
ИИ — не конец тестированию, а лишь начало нового этапа
Все мы с интересом наблюдаем, куда приведёт нас эпоха ИИ. И мнения здесь сильно расходятся: кто-то считает, что ИИ "сдуется" или его вообще прикроют, другие — что он оставит нас без работы.
Сегодня делюсь экспертным мнением Filip Hric, за которым я давно слежу
Что изменится?
🔹Тестирование станет встроенной частью разработки ПО
Генерируется код — вместе с ним генерируются и тесты. И только когда все тесты "зелёные", код считается готовым. Мы всё чаще будем видеть AI-решения, которые вместе с автогенерируемым кодом будут сразу добавлять автотесты, запускать их в фоне и передавать результаты обратно в LLM (например, Nut.new или Replay.io).
🔹Ручное тестирование не исчезнет, а эволюционирует
Фокус сместится на проверку только нового функционала. Регрессионное тестирование — за автоматизацией.
🔹Качественное тест-дизайн мышление останется крайне ценным
Недостаточно просто написать автотесты на Playwright — важно понимать риски, грамотно работать с тестовыми данными и следовать best practices. Даже если тесты пишет ИИ, за их качество отвечает опытный QA, который управляет процессом и делает ревью.
🔹Отладка приложений и тестов — следующий вызов для ИИ
Trace-view, как в Playwright, уже становится стандартом, но подобной прозрачности часто не хватает в рантайме самого приложения. ИИ-модели до сих пор слабо умеют дебажить код — даже лучшие из них. Моё мнение: именно инструменты для observability станут ключом к действительно надёжному коду от ИИ.
👉 Ссылка на оригинальную статью
👉 @QAPortal
Яндекс впервые открывает набор в новую Летнюю школу тестировщиков
Школа поможет начинающим тестировщикам, которые хотят прокачаться в обеспечении качества с помощью инструментов автоматизации. От будущих участников ждут базовых знаний SQL, понимания теории тестирования и владения основами любого языка программирования.
Начинающие спецы смогут не только систематизировать знания и освоить необходимый инструментарий тестировщика, но и поработать с топовыми экспертами над реальными задачами. Те, кто отлично проявит себя, получат возможность пройти стажировку или получить оффер в штат компании. А еще поработать с топовыми экспертами и получить возможность попасть на стажировку!
Приём заявок открыт до 27 апреля. Участие бесплатное , но нужно выполнить тестовое задание.
Я устала писать документацию — и научила AI делать это за меня
Тимлид из KODE устала писать тестовую документацию вручную и начала использовать AI (DeepSeek), чтобы генерировать чек-листы и тест-кейсы. Загружает скриншоты или описания — и AI помогает всё оформить. Процесс требует немного доработки, но в итоге работает в 3–5 раз быстрее.
👉 Читать
👉 @QAPortal | #cтатья
Формошлёп — сотни хаков для фронтендеров в одном месте
Никакой скучной теории, воды и прочей шляпы, только практические примеры, которые работают.
👉 Подписывайся на @frontbox — стань тем, кто знает, как решить проблему, пока остальные ищут ответ на Stack Overflow.
Типичные будни тестировщиков
👉 @QAPortal
На Хабре вышла интересная статья «Топ-3 расширения Chrome для автотестов». Если вкратце:
1. SelectorsHub — быстро ищет и строит XPath и CSS-селекторы с умными подсказками. Можно генерить локаторы вручную или автоматически.
2. Automize — сам находит элементы в DOM и выдает готовый скрипт для Playwright, Puppeteer, Cypress, Selenium или чистого JS
3. Page Modeller — мгновенно собирает все локаторы на странице или в отдельном блоке
👉 Читать полностью
👉 @QAPortal | #cтатья
Ночное-полезное: Сайт с задачами по SQL — SQL-EX
Пишем запросы, тренируем JOIN, подзапросы, оконные функции и кайфуем от прогресса ✌️
И да, всё на русском
👉 @QAPortal
Записываем секрет успеха
P.S. Хороших выходных ❤️
👉 @QAPortal
Процесс тестирования выглядит буквально так.
Когда-то и меня вела дорога приключений, но потом мне прострелили колено.
👉 @QAPortal