7118
Присоединяйтесь к нашему каналу и погрузитесь в мир тестирования Связь: @devmangx
Где набраться практики начинающему тестировщику: от учебных полигонов до open source
Начать карьеру в тестировании — задача не из простых, особенно когда за плечами только теория и пройденные курсы, а в портфолио нет ни одного реального проекта.
👉 Перейти к статье
👉 @QAPortal
HackerRank
Десятки челленджей в виде SQL-запросов по разным уровням сложности и темам: базовые или продвинутые запросы, выборки на агрегацию или с применением JOIN
https://www.hackerrank.com/domains/sql
👉 @QAPortal
Как и зачем искать UI-элементы в Console, DevTools?
Начнем с того, что к элементу в Console можно обращаться как к переменной. Достаточно кликнуть на этот элемент во вкладке Elements, после чего к нему можно будет обращаться вот так: $0.
— Какие полезные методы можно применять к $0?
🔹$0 — отобразит элемент, выбранный во вкладке Elements;
🔹$0.innerText — выведет текст, содержащийся в этом элементе;
🔹$0.classList — покажет список CSS-классов, назначенных элементу;
🔹$0.id — вернет значение атрибута id элемента;
🔹$0.parentElement — вернет родительский элемент.
— Как искать элементы?
🔹$('.class_name') — отобразит элементы с указанным классом.
Как указать несколько классов? Через точку вместо пробелов.
Например: "example class name" → $('.example.class.name')
🔹$$('html_tag').filter(s => s.innerText.trim() === 'Text') — таким способом я ищу элементы по тексту.$$ в начале команды возвращает элементы в формате NodeList.
🔹$('span.class_name.class_name') — если нужно найти элемент по тегу и классам.
👉 @QAPortal
JWT, или JSON Web Token
JWT — это открытый стандарт RFC 7519, который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде JSON-объекта. Эта информация может быть проверена и заслуживает доверия, так как подписана цифровой подписью. JWT может использовать либо общий секрет (через алгоритм HMAC), либо пару открытого и закрытого ключей с использованием RSA или ECDSA.
sub — идентификатор пользователяiat — время выдачи токенаexp — время истечения срока действия токенаrole — роль пользователя (например, "admin"){
"sub": "1234567890",
"name": "John Doe",
"admin": true,
"iat": 1516239022
}signature = hashing_algorithm(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)
<base64Url(header)>.<base64Url(payload)>.<base64Url(signature)>
localStorage или в cookies).Authorization. Сервер проверяет его подлинность, подпись и срок действия (по iat/exp), пока токен действителен.header и payload.exp. Если токен истёк, пользователь может получить новый токен с помощью refresh-токена (обычно это происходит автоматически).
Проджект: срочно нужно провести регрессию!
QA: А зачем?
Проджект:
👉 @QAPortal
Что такое 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 апреля. Участие бесплатное , но нужно выполнить тестовое задание.
Хочешь погрузиться в автоматизацию, но везде только и предлагают пройти обучения? 🫥
Скорее всего тебе хочется узнать больше про автоматизацию, но из-за огромного количества обучений и попыток их тебе продать, ты уже не уверен, что тебе это надо.
Роман Цакунов – QA Lead с опытом в IT больше 8 лет – запустил бот, который будет бесплатно отправлять тебе только полезную информацию. Никаких продаж и курсов.
Подписывайся сразу, чтобы не потерять – t.me/rvtsakunovbot
Авторизация через VK: что под капотом и как это тестировать
Авторизация в приложениях через сторонние сервисы уже давно стала привычной. Это и правда удобно. Не нужно запоминать, как именно ты вписал свой юзернейм — Va$ya или Vassssya? — и какой пароль выбрал — 123 или 321? Нажимаешь волшебную кнопку «Войти с помощью….» и попадаешь в личный кабинет. И раз эта фича появилась, значит, это кому-нибудь нужно (и кто-то это тестирует :)
Платформы — великое благо и великое зло
В данной статье автор собрал все плюсы и минусы, которые заметил за время своей работы, чтобы понять, насколько платформы полезны и когда их стоит внедрять.
👉 Перейти к статье
👉 @QAPortal
Чек-лист ревьюера тест кейсов
Статья — это чек-лист для QA-инженеров по ревью тест-кейсов: как правильно оформлять, что обязательно указывать (результаты, коды, покрытие, связи с задачами), чего избегать (лишние детали), и как повысить качество и автоматизацию тестов
👉 Читать
👉 @QAPortal
Позвоните бабушке: как тестируют функцию CSFB, которая связывает поколения
"Статья будет полезна тем, кто хочет узнать о разработке и тестировании многокомпонентных решений в телекоме. К тому же подход можно применить и к другим модульным системам с внешними зависимостями"
👉 Читать
👉 @QAPortal
Куда расти 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 - обучение работе с командной строкой