📚 Глава 2 ISTQB: 4 способа тестировать, о которых ты не знал

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

Случайно запостил черновую версию поста - ну, теперь вы знаете, что у меня есть черновики 🙈

Продолжаем разбор силлабуса ISTQB. На очереди:
2 глава «Тестирование в SDLC». Входит в 12% экзамена — примерно 5 вопросов из 40.

⛔ Разбор первой главы был тут

❓Что внутри:
— Уровни тестирования (кто тестирует когда)
— Типы тестирования (что проверяем)
— Shift-left и DevOps (как ломают правила в хорошем смысле)
— и много чего еще (глава довольно большая)

Уровни тестирования
1. Модульное — разработчик сам тестирует функцию. Баг здесь стоит условно ВАН ДОЛЛАР 💲
2. Интеграционное (бывает для модулей и для систем) — модули (или системы) общаются. Тут уже стоимость будет : ДЕСЯТЬ ДОЛЛАРС 💲
3. Системное — всё вместе. Работает ли вся машина? Стоимость: ВАН ХАНДРЕД ДОЛЛАРС 💲
4. Приёмочное — бизнес проверяет. Найден баг? Точно лишишься годовой премии. 😬

Правило: чем позже найдём баг, тем дороже чинить.

Типы тестирования:
✅Функциональное — кнопка нажимается? ✅
✅ Нефункциональное — кнопка отзывается за 50 мс? А если 1000 человек? На медленном интернете? На луне? Производительность, безопасность, юзабилити, совместимость — это нефункциональное. Разница между «работает ли автомобиль» и «работает ли в пустыне, ночью, под дождём». 🏜
✅ Белый ящик - тестирование по внутренней структуре (код, архитектура)
✅ Черный ящик- тестирование по поведению и документации

Все 4 типа применяются на всех уровнях! Но цели на каждом уровне разные

Идея раннего тестирования (Shift-left)
- Раньше: разработка → интеграция → тестирование → продакшн (медленно)
- Теперь: требования → разработка (параллельно тестирование) → DevOps (автомат) → продакшн (быстро)

Главная идея: не жди весь код, начни тестировать требования сейчас.

Полный конспект по Главе 2 приложу в комментариях 📎

Вы знали, что уровни и типы тестирования - это разные штуки? Я знаю, часто путают приёмочное с системным. Пишите в комментариях, что думаете 👇

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

#ISTQB

📚 Глава 3 ISTQB: как находить баги, даже не запуская код?

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

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

А потом приходит глава 3 ISTQB и говорит:

нет, баги можно ловить ещё раньше 😅

Глава 3 посвящена СТАТИЧЕСКОМУ ТЕСТИРОВАНИЮ
Статическое тестирование это когда мы проверяем рабочие продукты без выполнения кода.

Представьте стройку. Если вы заметили ошибку в чертеже до заливки фундамента, вы красавчик.
Здесь та же логика.

📄 Статически мы можем проверять:
• требования
• дизайн
• код
• тест-кейсы
• документацию

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

🤔 Чем оно отличается от динамического?
Динамическое тестирование это когда система уже работает и мы проверяем её в действии.

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

И вот в этом главная польза главы.

Отдельно в экзамене ISTQB есть вопросы про процесс рецензирования: какие там роли, какие бывают виды review и от чего зависит его успех.
Глава небольшая, но очень практичная. Эту тему и остальные я описал в своем конспекте, приложу в комментариях к этому посту

Если упростить главу до одной мысли:

лучший баг, это тот, который нашли до запуска.

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

#ISTQB

📚 ИИ заставил меня читать

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

В какой-то момент поймал себя на мысли, что почти не читаю книги системно. И дело даже не только во времени.

Проблема в другом: открываешь список вроде

«100 книг, которые должен прочитать КАЖДЫЙ»,

и сразу перегруз. Слишком много вариантов, слишком мало понимания, с чего начать и зачем именно с этого.

Поэтому я решил использовать AI исследователя. Дал ему задачу:

1. собрать сильные источники
2. отфильтровать шум
3. разбить книги по категориям
4. выставить приоритеты
5. предложить понятную точку входа

На выходе получилась дорожная карта на несколько лет (с моей усидчивостью - лет на 10 👨‍🦯)

👆 Например, в стартовую пятёрку он поставил:
- «Космос» Карла Сагана
- «Наедине с собой» Марка Аврелия
- Sapiens Харари
- Чехова
- «Думай медленно... решай быстро» Канемана

А весь список разложил по направлениям: философия, история, наука, психология, экономика, русская и западная классика.

💕 В таком сценарии мистер ИИ мне нравится намного больше. Когда помогает собрать сложную тему в понятную структуру.

Если хотите повторить подход, вот промпт:

"Я хочу стать образованным и начитанным человеком. В школе я почти не читал, сейчас тоже читаю мало — хочу это исправить с нуля.
Составь для меня структурированный список литературы, прочитав который я получу широкую эрудицию и смогу считаться образованным человеком. Учитывай следующее:
Критерии подбора книг:
Книги должны охватывать разные области: философия, история, наука, классическая художественная литература, экономика, психология
Включи как западную, так и русскую классику
Список должен быть реалистичным — не 200 книг, а ~40–60 ключевых произведений
Раздели список на уровни: «обязательно прочитать в первую очередь», «второй приоритет», «для углублённого чтения»
Формат ответа:
Разбей по тематическим категориям
Для каждой книги укажи: автор, название, 1–2 предложения почему она важна и чему учит
Отдельно порекомендуй, с каких 5 книг лучше всего начать человеку, который давно не читал
Ориентируйся на список, который признали бы разумным образованные люди разных культур — не только западная академическая традиция."

🤩 Полный документ исследования приложу в комментариях.

А вы для какой темы хотели бы собрать себе такую дорожную карту?

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

#AI

🧰 JMeter всё ещё живее всех живых

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

Бывает такой момент: нужно быстро дать нагрузку на API или сервис, а времени на изучение нового модного инструмента примерно столько же, сколько у бэкенда на «быстрый фикс» 😅

Вот тут часто и вспоминают про старый добрый ДЖИМЕТР.

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

У JMeter внутри не только HTTP-запросы. Он умеет работать с API, JDBC, JMS, SMTP, FTP, TCP (это все разные протоколы) и не только. Плюс есть графический интерфейс, возможность запускать через командную строку, HTML-отчёты, плагины и скрипты 🤩

Да, последний стабильный релиз 5.6.3 вышел не вчера. Но репозиторий проекта обновлялся и в апреле 2026, у него около 9.3k звёзд на GitHub, 2.2k форков и больше 20 тысяч вопросов на Stack Overflow.

Отдельный плюс, что у JMeter живая экосистема плагинов. Есть Plugins Manager, который умеет ставить, обновлять и удалять плагины.

И самое важное: JMeter полезен не только нагрузочникам.

Им пользуются, когда нужно:
• разработчику быстро проверить, как API ведёт себя под параллельными запросами
• QA или AQA устроить сервису базовый стресс и поймать первые ошибки
• backend или DevOps-команде быстро получить первичную картину до более глубокого разбора

Это не реклама (было бы неплохо, если бы создатели джиметра связались со мной 😅), просто накопилось и захотелось напомнить обществу про старичка - JMeter выбирают не за хайп, а за зрелость, универсальность и ощущение, того что все работает из коробки 😘

А вы пользовались JMeter только для нагрузки (если пользовались) или ещё для каких-то задач?

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

#Инструмент

🧪 Глава 4 ISTQB: как перестать тыкать тесты на удачу

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

Продолжаю разбирать главы силлабуса. Прошлые посты на тему ⬇️
- 1 глава
- 2 глава
- 3 глава

🤔 Если честно, у меня глава 4 ощущается, как самая главная глава во всей книге - здесь все знакомые вам понятия, вот они слева-направо:
- классы эквивалентности
- граничные значения
- черный и белый ящики
- исследовательское тестирование
- и много другой базовой базы

Потому что анализ и проектирование тестов это не про 200 тест-кейсов на одну кнопку.
Это про выбор нормальной техники под нормальную задачу. 🤌

🏘 Представьте, что вы проверяете квартиру перед покупкой:
- Можно смотреть снаружи: закрываются ли окна, течет ли кран, включается ли свет. Это похоже на черный ящик.
- Можно полезть глубже и посмотреть, что там с проводкой и автоматами. Это уже белый ящик.
- А можно зайти и через 5 минут сказать: «Что-то тут подозрительно, я этот запах дешевого ремонта уже видел». Это тестирование на основе опыта.

И вот вся глава 4 как раз про такие подходы.

❓Что тут самое полезное:
Из методов черного ящика:
• Эквивалентное разбиение. Не тестируем все числа подряд. Делим данные на классы и берем представителей.
• Граничные значения. Баги обожают сидеть на границах. Там, где 0, 1, 999, 1000 и начинается веселье.
• Таблицы решений. Спасают, когда бизнес-правила уже выглядят как семейная драма на 12 серий.
• Таблицы переходов. Очень нужны там, где у объекта есть статусы и состояния.

Из белого ящика важно запомнить одну экзаменационную подлянку:

покрытие ветвей сильнее покрытия операторов.

То есть 100% ветвей даст 100% операторов. Но 100% операторов не спасет от пропущенной ветки.

А в конце главы идет описание того, как тестировщик внедряется в процесс создания продукта уже на этапе обсуждения.
То есть качество обсуждаем еще до разработки, а не в стиле «ну вот вам готовая фича, удачи там».

Короче, главная мысль простая:

тест-дизайн учит тестировать умнее, а не больше.

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

А как вам глава 4? С чем-то уже встречались? 👇

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

#ISTQB

🎨 Нейросеть, похоже, научили нормально писать текст на картинках

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

У генераторов картинок давно была одна проблема. Просишь нарисовать картинку с текстом "Привет, мир!" а в ответ прилетает что-то вроде "Привет, мяу!". Картинка красивая, а текст будто собирали в пятницу вечером 😅

С GPT-Image-2, стало лучше.

OpenAI сейчас тихо выкатили новую модель в ChatGPT

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

Ну что ж, ребята из ЧАТ ДЖИПИТИ сделали нейрослоп снова великим 😗

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

В комментарии приложу ещё несколько работ новой модельки (там Канье Уэст залетел на сельскую дискотеку 🪩)

А вы бы где такое применили первым делом: в контенте, в тестах или просто ради мемов с нормально написанным текстом? 👀

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

#AI

Ну вот и пятница, коллеги 👍

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

#Хиханьки

🧭 Глава 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)
• Не даёт ли функция экспорт скачать больше, чем нужно

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

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

Например:

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

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

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

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

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

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

#Практика