🧭 Глава 5 ISTQB: как не превратить тестирование в поход без карты

Привет, коллеги 👋

Традиционный разбор глав силлабуса ISTQB
Прошлые посты на тему ⬇️
- 1 глава
- 2 глава
- 3 глава
- 4 глава

На очереди глава 5: управление тестированием.

Может показаться, что она посвящена тому, как работает мир менеджеров, созвонов и таблиц, от которых глаз начинает нервно дёргаться. Но глава очень рабочая 🧑‍💻

Представьте, что команда собирается в поход.

Если просто сказать: «Ну, идём куда-нибудь в лес», весело будет первые минут двадцать 😅

Потом выяснится, что:
- карту никто не взял
- палатка у аналитика
- еду должен был купить тестировщик
- тест-менеджер думал, что мы едем на такси

Вот глава 5 как раз про то, чтобы такого не было.

✅ Тест-план отвечает на вопросы: что тестируем, зачем, какими силами, какие есть риски и где границы работы. В ISTQB важно запомнить:

тест-план пишет тест-менеджер, не тестировщик.

✅ Критерии входа говорят, когда можно начинать тестирование.
Например: окружение готово, требования не меняются каждые пять минут, сборка запускается без обряда с бубном.

✅ Критерии выхода говорят, когда можно заканчивать.
Есть нужное покрытие, критичные дефекты закрыты или понятны, команда знает остаточные риски.

Ещё одна ловушка из главы: критичность не равна приоритету.

Критичность это насколько больной дефект.
Приоритет это насколько срочно его чинить.

Иногда баг неприятный, но до релиза терпит. А иногда мелочь в главном сценарии чинится первой, потому что без неё всё горит.

Главная мысль главы простая:

хорошее тестирование начинается не с кнопки «проверить», а с понимания, что мы вообще делаем.

Полный конспект по главе 5 будет в комментарии 📎

А что вам кажется сложнее в этой главе: риски, критерии входа/выхода или квадранты тестирования? 👇

⚡️ Подписаться

#ISTQB

🧠 AI в тестировании: помощник, а не волшебная палочка

Привет, коллеги! 👉

AI сейчас пытаются прикрутить ко всему. Ещё немного, и чайники будут продаваться с приставкой ЭЙ-АЙ 😂

Но в тестировании AI правда может быть полезен. Активно его использую и накидал несколько мыслей на эту тему🤔

Он хорош в автоматизации рутины
• накидать идеи для тест-кейсов;
• быстро объяснить незнакомый лог;
• подсказать варианты негативных проверок;
• помочь переписать баг-репорт понятнее;
• сгенерировать тестовые данные;
• объяснить непонятные требования;
• Переписать агрессивное письмо для разработчика, чтобы не показалось,что вы истеричка 😅

ИИ похож на стажёра, который очень быстро читает документацию, но иногда уверенно несёт чушь. Проверять всё равно придётся вам. 🫵

Где человек пока незаменим?
В понимании КОНТЕКСТА. AI может предложить 20 проверок формы логина, но не всегда поймёт, какая из них реально важна для бизнеса, пользователей и релиза в пятницу вечером.

Ещё AI не чувствует подозрительные мелочи. Например: «Кнопка работает, но как-то странно».

Я отношусь к AI как к усилителю. Он ускоряет подготовку, помогает не забыть очевидное и иногда подкидывает хорошую идею.

Но ответственность за качество всё ещё на человеке. У нейросети лапки, а у QA тест-кейсы. 😀

А где AI уже помогал вам в работе, а где наоборот пришлось перепроверять за ним каждую букву?

⚡️ Подписаться

#AI

🕵️ DevTools Network: куда смотреть новичку

Привет, коллеги! ❤️

Поговорим про вкладку Network в инструментах разработчкика в браузере (это которые кнопкой f12 включаются) 🌐

На первый взгляд, она выглядит как табличка в аэропорту: много строк, цифр и ощущение, что ваш рейс в мир АЙТИ уже улетел 🤨

Но, вообще-то говоря, для QA это один из самых полезных инструментов.

❓ Как открыть:
F12 или правый клик по странице, потом «Просмотреть код», дальше вкладка Network. Обновляем страницу и смотрим, какие запросы полетели.

Что проверять в первую очередь:

• Status. 200 обычно значит «нормально», 404 значит «не нашли», 500 значит «сервер прилёг подумать о жизни».
• Method. GET чаще получает данные, POST чаще отправляет.
• Response. Тут можно увидеть, что реально вернул сервер.
• Payload. Тут видно, что мы отправили.
• Time. Сколько запрос выполнялся.

Пример работы:
На экране ошибка «что-то пошло не так». Очень информативно, спасибо. 🙂‍↕️

А в Network видно, что запрос вернул 403. Значит, проблема может быть в правах доступа, токене или настройках пользователя.

Ещё полезно фильтровать запросы по Fetch/XHR. Так проще найти общение фронта с бэком, а не картинки, шрифты и прочую мишуру.

ИТОГО
Network помогает не гадать, а смотреть факты и понять, что случилось и на чьей стороне проблема 💡

Пользуетесь Network в проверках или пока открываете DevTools только чтобы выглядеть серьёзно?

⚡️ Подписаться

#Инструмент

📊 Перцентили: почему среднее время ответа может обмануть

Привет, коллеги! 👋

Представьте кафе. Девять человек получили кофе за 1 минуту, а десятый ждал 10 минут, потому что бариста ушёл искать смысл жизни. ☕️

Среднее время вроде нормальное. Но тот десятый человек уже пишет гневный отзыв.

В нагрузочном тестировании похожая история.

Среднее время ответа показывает «температуру по больнице». Оно может выглядеть красиво, даже если часть пользователей страдает. 😔

Чтобы отсечь такие аномальные ситуации используют перцентили.

Перцентиль показывает, какая ДОЛЯ запросов уложилась в определённое время.

Например, 95-й перцентиль, (он же p95), означает: 95% запросов были быстрее определенного значения, а 5% медленнее (их в расчет не берём)

Если p95 = 800 мс, значит, 95 из 100 запросов уложились в 800 мс. Остальные 5 могли быть медленнее (опять-таки, не важно на сколько)

👀 Часто смотрят несколько перцентилей:
• 50-й перцентиль, p50, показывает время ответа у половины запросов;
• 95-й перцентиль, p95, помогает увидеть медленные запросы, которые уже заметны пользователям;
• 99-й перцентиль, p99, показывает совсем тяжёлый хвост.

На практике чаще всего смотрят именно p95: он уже показывает проблемы, но не так сильно зависит от единичных странных выбросов, как p99.

Зачем это в тестировании?
Потому что пользователю всё равно, что «в среднем нормально», если именно его запрос открывался 100500 секунд 🤬

Среднее не бесполезно. Просто оно часто слишком вежливое и скрывает драму. 🫣

А вы уже сталкивались с перцентилями?

⚡️ Подписаться

#Метрика

🗂 Итоги недели: что было в Канале

Коллеги, привет! 👋

Если что-то пропустили, вот короткая навигация 👇

1. 5 глава силлабуса ISTQB
Разобрали очередную главу самой главной книжечки любого тестировщика

2. AI в тестировании
Немного подушнил на тему ИИ - где AI реально помогает QA:

3. DevTools Network
Прошлись по вкладке Network для новичков: Status, Method, Response, Payload, Time, фильтр Fetch/XHR и вот это все

4. Перцентили и p95
Разобрали, почему среднее время ответа может обмануть. p50, p95 и p99 помогают увидеть хвост медленных запросов,

Какой пост за неделю был самым полезным для вас? 👇

⚡️ Подписаться

#ИтогиНедели

🧰 Глава 6 ISTQB: инструменты не тестируют за нас

Привет, коллеги 👋

Ну что, вот мы и дошли до финала. Это последний пост по силлабусу ISTQB, и глава 6 посвящена инструментам тестирования.

Инструменты это как чемодан для ремонта. Там может быть дрель, молоток, отвёртка и даже штука, название которой никто не знает. Но если не понимать, что делаешь, дрель просто сделает новую дырку в стене.

В тестировании так же.
- Jira не управляет качеством сама.
- TestRail не пишет хорошие тест-кейсы за нас.
- Selenium не спасает плохую проверку.
- JMeter не объяснит, почему сервис лёг от 100 пользователей.

Глава 6 как раз про то, какие инструменты бывают и где они помогают:
• управление тестами, требованиями и дефектами
• статический анализ и ревью
• автотесты, покрытие и CI/CD
• нагрузка, безопасность, производительность
• совместная работа команды

🚨 Даже Excel может быть инструментом тестирования, если вы используете его для тестирования.

Главная мысль по автоматизации простая:

Купить инструмент ≠ внедрить инструмент.

Автоматизация реально помогает:
• убирает рутину
• снижает человеческие ошибки
• даёт быстрый фидбек
• освобождает время для нормального анализа

Но есть риски:
• ждать от инструмента магии
• недооценить поддержку автотестов
• автоматизировать ради автоматизации
• слепо верить зелёному прогону

Короче, инструмент усиливает тестировщика. Но не заменяет голову.

В комментариях будет файл с конспектом по шестой главе 📎

А ещё, получается, мы прошли весь силлабус 💪

Ссылки на предыдущие главы
- 1 глава
- 2 глава
- 3 глава
- 4 глава
- 5 глава

Какой инструмент вам сильнее всего помог в тестировании, а какой только усложнил жизнь? 👇

⚡️ Подписаться

#ISTQB

🔐Роли и права: как тестировать доступ

Привет, коллеги 👨‍🦯

Если у пользователя, не обладающего нужными правами, нет кнопки «Удалить», значит, всё безопасно, так ведь? 😗

Не совсем 😅

Пользователь может открыть прямую ссылку, отправить запрос через DevTools или найти старую вкладку. И вот тут-то и нужно проверять доступы.

Представьте офис с пропусками.

- Гость может пройти на ресепшен.
- Сотрудник в рабочую зону.
- Бухгалтер в бухгалтерию. -Админ почти везде.

Но если стажёр смог открыть сейф с договорами и драгоценностями, у нас проблемы 🤦‍♀

В сервисах логика такая же:

• роль = кто пользователь: админ, менеджер, клиент, гость

• права = что ему можно: смотреть, создавать, редактировать, удалять, экспортировать

Это относится к авторизации.

Что проверять тестировщику:
• Видит ли роль нужные разделы, кнопки и данные
• Не видит ли лишнего
• Что будет, если открыть запрещённый раздел по прямой ссылке
• Что будет, если отправить API-запрос руками
• Можно ли увидеть чужие данные: заказ, профиль, счёт, документ
• Можно ли создать, изменить или удалить то, что нельзя
• Что происходит после смены роли
• Работает ли старая сессия после понижения прав
• Возвращается ли корректная ошибка о недоступности (401 или 403)
• Не даёт ли функция экспорт скачать больше, чем нужно

Удобный способ: сделать мини-матрицу.

роль × действие × объект.

Например:

☑️ менеджер + удалить + чужой заказ = нельзя.

☑️ админ + изменить + настройки = можно.

☑️ гость + открыть + личный кабинет = нельзя.

Главная мысль простая: проверяйте не только интерфейс. Проверяйте, что действие РЕАЛЬНО запрещено на сервере.

А вы уже ловили баги, где кнопки нет, а действие всё равно выполняется? 👇

⚡️ Подписаться

#Практика

👨‍💻 Новичков стали нанимать реже. Всё, джунам конец?

Привет, коллеги 👋

Вышла неприятная новость:

в России доля вакансий для кандидатов без опыта в I квартале 2026 года упала на 24% год к году.

Звучит как «закрываем ноутбук и идём в баристы». (Ничего плохого в этом не вижу, если что). Но я бы не спешил паниковать 😅

Главное, что нужно понять - изменилось правило входа.

Раньше бизнес чаще был готов взять человека «с нуля» и учить прямо на месте.

Сейчас, к сожалению, фраза «я прошёл курс» уже слабый аргумент. Она звучит примерно как «я посмотрел Рататуй, возьмите меня поваром». 🤩

Для начинающего QA теперь важнее приходить не просто с желанием, а с доказательствами навыков:

• тест-дизайн: классы эквивалентности, границы, чек-листы
• API: можешь отправить запрос и понять ответ
• SQL: умеешь достать данные
• баг-репорт: описываешь проблему так, чтобы её можно было воспроизвести
• портфолио: есть что открыть и посмотреть

В статье называют несколько причин: ИИ, рост требований к эффективности и нежелание компаний тратить ресурсы на обучение совсем с нуля.

Главная мысль такая.

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

Новичок всё ещё может зайти. Просто теперь нужно собрать не только резюме, но и маленькую папку доказательств: вот что я проверял, вот какие баги нашёл, вот как работал с API, вот мои тест-кейсы.

Да, вход стал сложнее. Но он все еще не является магическим порталом только для избранных с 5 годами опыта и фамилией Сеньоров 👨‍💻

🔗 Источник: https://iz.ru/2088132/mariia-stroiteleva/kompanii-rezko-sokratili-naem-sotrudnikov-bez-opyta

Что вам сейчас кажется самым сложным для входа: найти вакансии, собрать портфолио или понять, что учить? 👇

⚡️ Подписаться

#Новости

🗂 Итоги недели: дайджест канала перед длинными выходными

Коллеги, привет 👋

Собрал все посты за неделю, чтобы было удобнее дочитать пропущенное.

Посты недели ⬇️

✔️ Сериализация и десериализация
Разобрали, как данные упаковываются в формат для передачи между системами, а потом собираются обратно.

✔️ Глава 6 ISTQB
Финальный пост по силлабусу. Поговорили про инструменты тестирования

✔️ Тестирование ролей и прав
Разобрались, как тестировать доступы не только глазами в интерфейсе, но и НОРМАЛЬНО с примером

✔️ Найм без опыта стал сложнее
Обсудили новость про сокращение вакансий без опыта

...ну, и обложку канала освежил - зацените 😊

Такая получилась неделя)

Спасибо, что читаете 🙌

Какой пост за неделю был самым полезным? Или что оставили дочитать на выходные? 👇

⚡️ Подписаться

#ИтогиНедели

Ну, и пятничные #Хиханьки в догонку, всех с пятницей 🥳

⚡️ Подписаться