Тридцатилетний ты задремал на работе. Коллеги зумеры:

⚠️ Если компания предлагает вам «разойтись по-хорошему» — не торопитесь подписывать документы.

Созвон на 15 минут без повестки, «ну что, определился?» от HR, допсоглашение до пятницы — так обычно начинаются сокращения в IT.

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

Команда «5оффер» уже несколько лет помогает IT-специалистам любых грейдов и направлений:
▪️ добиваться выгодных условий при увольнении;
▪️ сохранять работу;
▪️ решать другие трудовые вопросы.

Наши юристы специализируются на трудовом праве и знают специфику IT.

✍️ Сохрани контакт «5оффер», чтобы он был под рукой в сложной ситуации.

Телеграм-канал

🎁 По промокоду 3KONS первичная консультация — 5000 3 000 ₽.

Записаться на консультацию — @Fiveoffer_bot

Реклама. ИП Кузнецова Ирина Сергеевна. ИНН:745111070021. erid: 2W5zFJ5tGzd

📌 ТОП инструментов и подходов для тестирования авторизации и токенов

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

Собрали инструменты и практики, которые помогают QA эффективно тестировать auth-флоу:

▫️ Postman
— Проверка login/logout
— Работа с JWT, access / refresh tokens
— Подмена токенов, проверка сроков жизни
— Удобно для ручных и автотестов
🔗 https://www.postman.com

▫️ JWT.io
— Декодирование и анализ JWT
— Проверка payload, exp, iss, aud
— Удобно для быстрой ручной валидации токенов
🔗 https://jwt.io

▫️ Chrome DevTools (Application / Network)
— Просмотр cookies, localStorage, sessionStorage
— Анализ Authorization headers
— Проверка обновления токенов и ошибок 401/403
🔗 https://developer.chrome.com/docs/devtools

▫️ HTTPBin / Webhook.site
— Проверка передачи headers
— Эксперименты с токенами и cookies
— Отладка auth-запросов
🔗 https://httpbin.org
🔗 https://webhook.site

▫️ Burp Suite (Community Edition)
— Перехват и модификация auth-запросов
— Проверка уязвимостей сессий
— Повторные запросы с разными токенами
🔗 https://portswigger.net/burp/communitydownload

▫️ OWASP Juice Shop
— Практика тестирования авторизации и сессий
— Реальные уязвимости: broken auth, IDOR, token reuse
— Отлично подходит для обучения
🔗 https://owasp.org/www-project-juice-shop

▫️ Checklist для QA (что проверять)
— Истечение срока действия токена
— Обновление refresh-token
— Доступ по ролям
— Поведение при logout
— Повторное использование старого токена
— Работа в нескольких вкладках

Эти инструменты и проверки помогают находить критичные баги ещё до продакшена и повышать уровень безопасности продукта.

✉️ ТОП бесплатных инструментов для тестирования email-рассылок

Тестирование email-рассылок может включать проверку SMTP, верстки, заголовков, доставки.
Подготовили подборку бесплатных инструментов, которые будут полезны QA.

▫️Mailtrap (Free Sandbox)
Перехватывает тестовые письма в изолированную среду, позволяет проверять HTML, заголовки, вложения и работать через API.
🔗 https://mailtrap.io/email-sandbox/

▫️MailHog
Open-source локальный SMTP-сервер, который собирает все исходящие письма и позволяет просматривать их через веб-интерфейс.
🔗 https://github.com/mailhog/MailHog

▫️Swaks
CLI-инструмент для тестирования SMTP: авторизация, TLS, кастомные заголовки, тестовые письма.
🔗 https://github.com/jetmore/swaks

▫️Mail-in-a-Box
Open-source локальный почтовый сервер для локального. Позволяет тестировать реальные SMTP/IMAP-флоу.
🔗 https://mailinabox.email

▫️Mailcare
Бесплатный sandbox-SMTP: перехватывает тестовые письма, показывает HTML/текст, анализирует заголовки и spam-score. Есть свой API.
🔗 https://mailcare.io

Почему именно эти инструменты?
— безопасное тестирование рассылок без риска отправить письма реальным пользователям
— автоматизация через API — можно покрывать email-флоу тестами
— проверка SMTP-конфигураций, аутентификации, работы с вложениями
— собственная локальная инфраструктура для тестов — нет зависимости от внешних сервисов
— интеграция с CI/CD, чтобы «email-тесты» стали частью автоматизации

Какое неожиданное наблюдение. Всем хороших выходных!

📌 Готовые базы данных для практики SQL

Если хотите улучшить навыки работы с SQL и ищете открытые базы данных для практики на реальных кейсах — ловите отличную подборку.

Все эти базы можно использовать в MySQL, PostgreSQL, SQLite, SQL Server или Oracle.

💎 Стандартные тестовые базы
Подходят для обучения и тестирования SQL-запросов:

▫️Sakila Database — база данных видеопроката (MySQL)
🔗 https://dev.mysql.com/doc/sakila/en/

▫️Northwind Database — классическая база для бизнес-аналитики (SQLite, SQL Server)
🔗 https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/linq/downloading-sample-databases

▫️AdventureWorks — тестовая база для SQL Server
🔗 https://github.com/Microsoft/sql-server-samples/tree/master/samples/databases/adventure-works

▫️Chinook Database — база музыкального магазина (PostgreSQL, MySQL, SQLite)
🔗 https://learn.microsoft.com/en-us/sql/samples/adventureworks-install-configure?view=sql-server-ver17&tabs=ssms

💎 Крупные открытые базы для аналитики
Реальные данные для SQL-задач, машинного обучения и BI-инструментов:

▫️IMDb Dataset — данные о фильмах, актёрах и рейтингах
🔗 https://www.imdb.com/interfaces

▫️Kaggle Open Data — тысячи открытых наборов данных
🔗 https://www.kaggle.com/datasets

▫️Google BigQuery Public Datasets — открытые публичные базы в облаке
🔗 https://cloud.google.com/bigquery/public-data

▫️European Soccer Database — футбольная статистика и результаты матчей
🔗 https://www.kaggle.com/datasets/hugomathien/soccer

💎 Тематические базы для практики на реальных кейсах

▫️COVID-19 Open Data — данные о пандемии
🔗 https://health.google.com/covid-19/open-data/raw-data

▫️Airbnb Open Data — информация о жилье, ценах и заселениях по всему миру
🔗 http://insideairbnb.com

▫️Spotify Dataset — данные о треках, жанрах и рейтингах
🔗 https://www.kaggle.com/datasets/maharshipandya/-spotify-tracks-dataset

▫️Wikipedia Clickstream — данные о переходах пользователей внутри Wikipedia
🔗 https://dumps.wikimedia.org/other/clickstream/readme.html

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

🔥 Приглашаем на бесплатный открытый вебинар курса «Go-разработчик. Базовый уровень»:
«Тесты в Go без боли: ловим баги раньше пользователей»

🗓 Когда: 5 ноября, 20:00 (мск)


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

- Зачем нужны тесты, если программа «и так работает»: находим ошибку на граничном случае
- Первый тест в Go: файл _test.go, функция TestXxx, команда go test
- Никаких сторонних фреймворков — всё уже есть в языке
- Табличные тесты: как проверить десятки случаев, не копируя код
- Подтесты t.Run: у каждого случая своё имя, и сразу видно, какой сломался
- Понятные сообщения об ошибках без запуска отладчика
- Покрытие кода (go test -cover): находим непроверенные ветки

В результате вебинара вы:

- Научитесь писать тест к своей функции и запускать его одной командой
- Освоите табличные тесты — основной стиль тестирования в Go-проектах
- Поймёте, как тесты экономят время и помогают ловить баги раньше пользователей
- Привыкнете проверять граничные случаи (пустые строки, ноль, отрицательные числа)

Кому будет полезно:

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

👉 Зарегистрируйтесь https://vk.cc/d3kw3R

Открытый урок проходит в рамках курса «Go-разработчик. Базовый уровень», на котором вы освоите язык Go с нуля до уверенной разработки приложений.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

В вечер четверга также ощущается, если честно.

Системный аналитик: что это за роль и зачем ее смотреть

Если коротко — тот, кто превращает «бизнес хочет вот это» в «разработка знает, что сделать». Собирает требования, рисует схемы, описывает поведение системы и ставит задачи разработке. Это соседняя роль к QA — часть работы пересекается, часть новая. Из текста вакансий или описания курсов понять, стоит ли туда смотреть, тяжело: нужен один проект изнутри.

Один такой проект разберут 5 ноября в 18:00 мск на бесплатном вебинаре karpovꓸcourses «Системный аналитик в 2026: как войти в профессию, когда код пишет ИИ».

Ведет Екатерина Комиссарова, архитектор решений в Лемана ПРО, 5+ лет в системной аналитике. На эфире разберет один проект по шагам, границу между БА, СА, проджектом и архитектором и место ИИ в этой работе: что он уже забирает и почему системам с ИИ-ассистентами по-прежнему нужен человек.

Примерьте профессию на себя: https://clc.to/erid_2W5zFGyuuHL  
Всем участникам придет запись после эфира.

Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFGyuuHL

📌 ТОП инструментов для тестирования file upload / download

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

Собрали инструменты и подходы, которые помогут QA качественно проверять upload/download-флоу:

▫️ Postman
— Тестирование upload через form-data
— Проверка Content-Type и размера файла
— Валидация ответа сервера
🔗 https://www.postman.com

▫️ HTTPBin
— Проверка отправки multipart/form-data
— Анализ headers и payload
— Удобно для экспериментов с API
🔗 https://httpbin.org

▫️ Chrome DevTools (Network)
— Проверка статуса ответа
— Анализ Content-Disposition и Content-Type
— Проверка размера файла и времени загрузки
🔗 https://developer.chrome.com/docs/devtools/network

▫️ cURL (CLI)
— Загрузка файлов через терминал
— Проверка API без UI
— Полезно для негативных сценариев
🔗 https://curl.se

▫️ OWASP File Upload Cheat Sheet
— Рекомендации по безопасной загрузке файлов
— Проверка MIME-type, расширений, размера
— Полезно для security-тестирования
🔗 https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html

▫️ Checklist для QA (что проверять)
— Ограничение размера файла
— Разрешённые / запрещённые форматы
— Переименование файла на сервере
— Обработка одинаковых имён
— Проверка вирусов (если предусмотрено)
— Доступ к скачиванию по ролям
— Поведение при обрыве соединения

Файловый функционал кажется простым, но часто содержит критичные баги.

Железо до релиза: экскурсии по лабораториям YADRO в Санкт-Петербурге и Москве

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

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

📍 Санкт-Петербург — 12 ноября и 1 декабря
📍 Москва — 17 ноября и 8 декабря
Сбор гостей в 18:30, старт в 19:00.

Возраст участников — от 18 лет. Экскурсии проходят по вечерам, а участие бесплатное — нужно зарегистрироваться и дождаться подтверждения от организаторов.

👉 Зарегистрироваться

Реклама. ООО "КНС ГРУПП". ИНН 7701411241. erid: 2W5zFGRLrZ8

Выбор языка для автотестов.
Автор: Ксения Райковская, QA Automation Lead в Plata

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

Всё, что написано ниже - моё личное мнение, во многом совпадающее с мнением Alex Pshe и ряда других источников, которые я читала и смотрела.

Способы выбора языка автотестов:

1. По языку backend.
Часто используемая стратегия. Позволяет переиспользовать модели, классы работы с базой, API-контракты. Обычно тесты фронта в таком случае тоже пишут на этом языке, особенно если он достаточно универсален.

2. По языку фронта.
Когда в фокусе UI-часть, в игру вступают JS/TS. Плюсы: можно задействовать фронтов, больше специалистов с таким стеком, сами языки проще. В таком случае и бэк часто тестируется на этом же языке.

3. Разные языки для тестов фронта и бэка.
Иногда UI и API тестируются разными людьми или даже командами. Тогда каждый пишет на «своём» языке. Это рабочий вариант, но если QA-команда одна - жизнь усложняется, падает переиспользуемость, возрастают усилия на поддержку.

4. Язык, не используемый в разработке.
Моё любимое. Исторически сложилось - взяли QA, который писал, скажем, на Python - продолжаем писать на Python, хотя бэк на Go. Бывает, что тесты начинали писать разработчики, выбрали «удобный» фреймворк, который не имеет никакого отношения к тому на чём написан проект, а теперь нанимают QA для поддержки. Ещё причина - рынок - Python и Java QA найти проще и дешевле, чем C# или Go. Иногда уже есть свой фреймворк и обучение в компании - на всех проектах используется один язык - проще перевести людей между проектами и масштабировать best practice и подходы.

5. Низкоуровневые или визуальные инструменты (Katalon, TestComplete и т.п.)
Часто - от руководства. Иногда - это способ перевести ручников в автотестирование. Слышала на собесе историю, где купили дорогущий Katalon «инструмент простой, тестировщики справятся».

Что выбрать?
Универсального ответа нет. Мне ближе первый подход. Но всё зависит от ситуации. Иногда четвёртый - лучшее, что можно придумать, когда нет доступа к коду, когда нужно снизить косты, и повысить ROI.

А что говорить на собеседовании?

Первое - задать встречные вопросы:
• Что уже используется?
• На чём написаны бэк и фронт, есть ли вообще доступ у тестировщиков к коду?
• Планируется ли автоматизация мобилки?
• Что первично - UI или backend?
• Насколько часто меняется код?
• Сколько человек в QA-команде или планируется?

Если всё только начинается - уточни, какой функционал будет покрываться в первую очередь. Если бэк стабилен - его тестировать дешевле и быстрее.

Если стек проекта редкий и проект не очень большой, лучше не настаивать на языке бэка. Можно честно сказать: «у меня есть экспертиза в таких-то стеках. Учитывая, что ваш язык редкий, я бы выбрала <X> - это ускорит запуск и упростит найм».