⚛️Потенциальные баги, связанные с токенами 🤪

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

1️⃣Долгий срок жизни
Риск: Если токен скомпрометирован, злоумышленник может долго его использовать.

2️⃣Отсутствие отзыва токена (No token revocation)
Вы выходите из системы, меняете пароль, блокируете аккаунт, а токен остается активным.
Риск: Пользователь "вышел", но его сессия всё ещё действительна.

3️⃣Хранение токена в небезопасном месте
Это когда токены хранятся в localStorage, sessionStorage или в переменных JavaScript.
Риск: Уязвимость к XSS — атакующий может украсть токен.

4️⃣Refresh-токен не одноразовый
Когда один и тот же refresh-токен можно использовать много раз.
Риск: Если токен перехвачен, злоумышленник может получать новые access-токены.

5️⃣Использование слабых алгоритмов (HS256 с общим ключом)
Когда используется алгоритм проверки подлинности токена HS256, но ключ стал известен.
Риск: Если злоумышленник узнает ключ, то сможет подписать любой токен.

6️⃣Отсутствие привязки к устройству или IP
Когда токен действует с любого устройства, геолокации или браузера.
Риск: Перехват токена = полный доступ.

7️⃣Ошибка валидации токена в микросервисах
Когда один из микросервисов доверяет токену без проверки.
Риск: Прямой доступ к внутреннему API.


❓Если есть что добавить- пишите в комментариях.

#токен
@testorest

⚛️Технические навыки открывают дверь. Soft skills — решают, как далеко ты зайдёшь.

Последнее время ловлю себя на мысли, что технически можно научиться чему угодно.

Hard skills можно выучить за месяцы при практической работе.

Soft skills — формируются годами, и именно они определяют, насколько ты:
- предсказуем в работе;
- вызываешь доверие;
- способствуешь здоровой командной динамике;
- способен влиять на процессы, а не просто выполнять их.

Рассмотрим Soft skills , которые позволяют вам становиться более ответственным и полезным членом команды.

❇️Ответственность.

Нашёл — значит, ты за это отвечаешь.

Ситуация:
Найден баг или замечание, которые кажутся спорными. Не ясно является ли это багом.

На самом деле ни одно замечание не является «не багом». Это проблема, с которой нужно разобраться до конца.
Возможно вы обнаружите серьезное отклонение.
Как минимум баг нужно завести в системе, чтобы вернуться к нему чуть позже и провести исследования.
Когда заказчик найдет точно такой же вам будет, где брать информацию.

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

❇️Думать о будущем.

Ситуация:
Как часто вы возвращались к багам прошлых спринтов пытаясь понять, что имелось ввиду и что нужно сделать?
Было бы проще, если бы были важные комментарии в задаче и более подробное описание.
Т.е. ,стоит описывать баг так, чтобы вы сами могли понять о чем речь через месяц.

Так ты сэкономишь команде и себе часы.

❇️Приоритизация и Продумывание рисков.

Ситуация:
Что будет, если не починить этот баг прямо сейчас? Иногда можно сэкономить время отложив незначительные баги на следующую итерацию.
А порой баг нужно чинить немедленно, иначе с вашей системой будет не удобно работать.

К рискам так же относится:

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

Умение приоритизировать — ключевой навык. Он позволяет не просто кричать "всё сломано!», а спокойно отделять критичное от косметических замечаний.

❇️Вовлеченность и инициатива

Ситуация:
Тут про то, что касается зоны вашей ответственности. Нашли проблему - разберитесь до необходимого уровня, заведите задачу по ней.
У других членов команды тоже много работы, вряд ли они кинутся решать очередную 1001 проблему, с которой вы пришли.
Обычно от коллег ожидаются ответы на вопросы, помощь в направлении по проблеме и то, что в зоне их ответственности.

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

Ты не обязан решать всё сам.
Но ты обязан запустить процесс, а не ждать, пока кто-то заметит проблему.

❇️Коммуникация и эмпатия

Не все баги — "ошибка разработчика".
Иногда — это недопонимание требований, недостаток документации, пробел в бизнес-логике.
Лучшая подача бага не как "ты сломал", а как "вот что я вижу, давайте разберёмся".
Здесь важно умение вести диалог:
- без обвинений;
- с уважением к чужой работе;
- с фокусом на решении.

Это строит доверие, а не конфликты.
---
Конечно и я не всегда следовала данным принципам, но с опытом это то, на что стараюсь ориентироваться.

❓А какие качества выделили бы вы для работе в команде?
Пишите в комментариях.

#qa_изжизни #мнение_автора
@testorest

⚛️Что делать, если чувствуешь застой в профессии?

Шаги:

1️⃣Выбери направление:
- Автоматизация (Web, API, Mobile)
- Тестирование производительности
- Безопасность
- QA-аналитика(глубже в тест-дизайн)
- Управление процессами тестирования

2️⃣Начни с малого:
- Пройди бесплатный курс
- Напиши 1 автотест
- Научись писать SQL-запросы к БД
- Попробуй Postman для API

3️⃣Делай заметки:
Веди блог (можно только для себя), чтобы структурировать знания.

4️⃣Попроси фидбек у коллег или руководителя:
"Как ты думаешь, в каком направлении мне развиваться? Что я могу улучшить?"

5️⃣Найди ментора или сообщество:
- Telegram-каналы, форумы.
- Участвуй в обсуждениях.


❇️Самопроверочный чек-лист: "Не застрял ли я?"

За последние 3 месяца я:

- Изучил хотя бы один новый инструмент или технологию
- Применил что-то новое в работе
- Прочитал статью/книгу или прошёл курс
- Поделился знаниями с коллегами
- Задавал вопросы по требованиям или архитектуре
- Понял, как работает система, а не только интерфейс
- Поставил себе профессиональную цель


Если меньше 4 галочек — пора запускать "режим развития".

#саморазвитие
@testorest

⚛️Острые и актуальные темы в тестировании к сентябрю 2025

1️⃣Тестирование в условиях AI разработки, когда часть кода генерируется ИИ.

Вопросы(на которые еще предстоит ответить):

🌀Есть ли особенности в тестировании ИИ кода?
🌀Если автоматизированные тесты пишет ИИ, то как им доверять?
🌀Возможно ли с юридической точки зрения использовать ИИ в тестировании на вашем проекте?
---

2️⃣Безопасность как неотъемлемая часть тестирования.
QA всё чаще участвует в security testing.

Навыки, которые здесь пригодятся:
🌀Понимание OWASP Top 10.
🌀Проведение базовых проверок: SQL-инъекции, XSS, неправильная аутентификация.
🌀Работа с DAST/SAST-инструментами (например, OWASP ZAP, Burp Suite).

Ожидания от QA: не быть экспертом по безопасности, но уметь "заметить красный флаг".
---

3️⃣Рост важности soft skills.
QA всё чаще:
🌀Транслируют информацию о рисках команде, заказчику.
🌀Обучаются основам DevOps, чтобы понимать pipeline.
🌀Пишут документацию, проводят воркшопы для коллег.
🌀Выступают как "голос пользователя" в команде.

Как результат одним из ключевых навыков становится системное мышление — видеть продукт целиком, а не только тест-кейсы.
---

❓Какие бы острые, актуальные темы добавили?
(пишите в комментариях к данному посту)

#мнение_автора
@testorest

С днем тестировщика!🥳

Сегодня день тех, кто умеет воспроизвести баг, описав не только шаги, но и фазу луны на момент клика🌚😁

Всем легких релизов!🫶🫶🫶

@testorest

⚛️Метод ускорения тестирования в 5-6 раз.

Сегодня о новостях мира тестирования.

Ученые из Владивостока разработали метод Targeted Test Selection (T‑TS) в основе которого лежит использование ИИ.
В результате прогон тестов ускоряется в 5,6 раз, при этом ловит более 95% багов, запуская всего 15% тестов от всего набора.

Как это работает?
Представьте, что у вас тысячи тестов. T-TS смотрит на историю изменений кода — какие файлы часто ломались, какие тесты ловили ошибки раньше — и умно выбирает, что запускать сейчас. Как спам-фильтр, но для тестов.

В статье сообщается, что метод:

🔹 Работает с любым языком программирования
🔹 Не требует тонкой настройки под проект
🔹 Уже протестирован на инфраструктуре Т-Банка — результаты подтвердились
🔹 Исходники открыты — можно забрать и внедрить самим


Ссылка на статью: https://clck.ru/3P95CP

❓Как считаете, применимо ли такое у вас на проекте?
Как вы ускоряете процесс тестирования релиза?

#ai #automation #qa_новости

@testorest

⚛️Проблемы в тестировании космического ПО

Вы думали, что вам тяжело тестировать свой продукт для ретейла, госсектора, финтеха или игровой индустрии?
Давайте посмотрим, с чем сталкиваются QA в космической отрасли.

Возможно, после этого вам станет легче(но не обязательно😁)


1️⃣Невозможность исправления ошибок после запуска

Ошибка в ПО космического аппарата часто приводит к полной потере миссии, поскольку обновления или исправления невозможны.
Яркий пример — Mars Climate Orbiter (1998), потерянный из-за ошибки в единицах измерения: одна команда использовала метрическую систему, другая — имперскую.


2️⃣Сложность воспроизведения космической среды

Особенно сложно моделировать воздействие космической радиации, вызывающей single-event upsets (SEU) — спонтанные сбои в памяти или логике процессора. Такие события могут привести к неправильному выполнению команд или отказу систем.

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


3️⃣Ограниченные вычислительные ресурсы

Бортовые компьютеры часто используют устаревшие, но радиационно-стойкие процессоры (например, RAD750 или LEON), которые:

- Медленные по современным меркам
- Имеют ограниченную память
- Не поддерживают современные ОС

Это усложняет:

- Отладку
- Логирование
- Запуск сложных тестовых фреймворков


4️⃣Высокая стоимость и длительность тестовых циклов

Hardware-in-the-loop (HIL) — ключевой метод тестирования, но он требует сложной инфраструктуры и дорогостоящего оборудования. Особенно это проблематично для малых компаний и новых участников рынка.

Кроме того, HIL-тестирование часто ограничено из-за нехватки времени и ресурсов на создание полноразмерных макетов.


5️⃣Требования к полной прослеживаемости (traceability)

В космической отрасли требуется полная прослеживаемость от каждого требования до тест-кейса и строки кода. Это регулируется стандартами вроде:

-ECSS-E-ST-40C (ESA)
-NASA NPR 7150.2

Нарушение traceability может привести к отказу в сертификации ПО.

#проблемы_qa
@testorest