КАКИЕ ВОПРОСЫ ДОЛЖЕН ЗАДАВАТЬ ТЕСТИРОВЩИК НА ЭТАПЕ АНАЛИЗА ТРЕБОВАНИЙ?

Сегодня хочу вам немного рассказать про то, какие вопросы можно и нужно задавать при анализе требований. Почему это важно? Чем раньше найдена неопределённость — тем дешевле она обходится. Поэтому анализ требований — это не просто “почитал и понял”, а активная работа, где вопросы важнее ответов.

Поэтому я подготовил список основных вопросов, которые помогут не просто читать требования, а реально понимать систему:

Что должен делать пользователь?
Какие основные сценарии? Какие исключения? Что будет, если пользователь сделает что-то не так?

Какой бизнес-результат должен быть достигнут?
Важно понять не только “что должно работать”, но и зачем это вообще нужно.

Какие ограничения есть?
По ролям, данным, времени, количеству попыток? Часто ограничения указаны вскользь или подразумеваются “по умолчанию”.

Что должно произойти, если что-то пошло не так?
Ошибки, валидации, откаты — всё это нужно тестировать. А для этого нужно знать, какое поведение считается корректным в случае сбоя.

Какие есть нефункциональные требования?
Производительность, безопасность, кроссбраузерность, доступность. Это не “бонусы”, а полноценные части системы.

Какие данные предполагаются в системе по умолчанию?
Какие значения валидны? Какие обязательны? Какие поля можно оставить пустыми?

Есть ли зависимости от других компонентов или систем?
Интеграции, API, внешние сервисы — если от них что-то зависит, это обязательно должно быть учтено в тестировании.

Что НЕ входит в рамки фичи?
Иногда полезнее узнать, что делать не надо, чтобы не тратить ресурсы на проверку того, что “в эту итерацию не входит”.


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

Не бойтесь быть “дотошным” — это профессионализм, а не занудство.


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет!

Хочу поделиться отличной новостью, первая часть моего плана, по изменениям на платформе TestGrow (о которых я писал тут) наконец-то закончена.

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

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

И в связи с этим небольшое предложение! Если у кого-то есть желание и время позаниматься переводом платформы (с ChatGPT или другим ИИ) за небольшое финансовое вознаграждение, пишите мне в личку! Готов рассмотреть кандидатов от уровня B2 и выше.


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

#Интересныезадачи

Всем привет!

Сегодня у меня новая для вас задачка на анализ ошибок и поиск причин их возникновения.

Условия:
Вы вручную добавляете товар в корзину на сайте. После обновления страницы товар исчезает. Повторная попытка — та же история.

Почему товар не сохраняется в корзине? Какие возможные причины?

Делитесь своими идеями по решению данной задачи в комментариях 👇

Время — одна из тех вещей, которые в интерфейсе всегда кажутся очевидными… пока не начинает вести себя странно при работе приложения в распределенных таймзонах.

Поэтому, если в проекте есть функционал на базе даты и времени, стоит заранее проверить такие вещи:

1. Локальное время пользователя. Убедитесь, что пользователь видит время в своей зоне, а не серверное. Особенно важно для календарей, встреч, задач, заказов.

2. Корректное преобразование временных зон. Создали событие в МСК — как оно отображается у пользователя с GMT или EST?

3. Переход на летнее и зимнее время. Да, в РФ время не переводят, но если ваш проект выходит за рамки РФ, то нужно проверить, что произойдет с событиями, запланированными на переход времени.

4. Формат хранения и отображения. Обычно хранится в UTC, показывается локально. Смешивание этих логик — частый источник багов.

5. Форматы времени. 24h vs. 12h, AM/PM, локальные представления даты. Иногда баги не в логике, а в формате.

6. Пограничные кейсы. Оформление заказа в 23:59 по местному времени может отображаться как следующий день — это важно для заказов и различных отчетов.

7. Фильтрация и сортировка. Особенно при работе с журналами событий, логами, отчётами — таймзоны могут “ломать” сортировку по дате.

Проверяйте это особенно внимательно, если работаете:
– с международным проектом
– с событиями и календарями
– c уведомлениям или действиями по времени (например, доставка)
– с логами или отчетностью

Полезные инструменты:
– DevTools → Sensors → Timezone override в Chrome DevTools
– ручная смена региона в настройках ОС
– подмена времени на уровне API при помощи Postman (например, в headers)
– простые онлайн-конвертеры часовых поясов

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


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет!

Хочу поделиться с вами очень полезным гайдом — конспектом книги Ли Копленда “Практическое руководство по тест-дизайну”, который подготовила Ирина в рамках своего канала по тестированию. В оригинальной книге более 300 страниц, но автор смог выжать максимально нужную информацию для тестировщика и уместить ее всего на 50 страниц!

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

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

Если коротко, я считаю, что это must-have, который можно распечатать и повесить рядом с рабочим столом.
Плюс — сам конспект удобный и структурированный, можно перечитывать точечно по нужной теме.

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

Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет!

Сегодня подготовил вам небольшой тест из 3-х вопросов по теме “Виды взаимодействия веб приложений”.

Смотрите ниже 👇

Всем привет!

Сегодня хочу поделиться с вами отличным тренажёром для тестировщиков, который недавно зарелизил мой знакомый Алексей (можно подписаться на его канал). Тренажер отлично подходит как для новичков, так и для тех, кто хочет немного освежить скиллы. Можно даже использовать как часть подготовки к собеседованию — особенно если хочется потренироваться в “тестировании с нуля по требованиям”.

Что это такое?
Это небольшое веб-приложение “Библиотека”, где реализованы:
– поиск книг,
– фильтры,
– карточки,
– категории,
– работа с запросами и множеством UI-элементов.

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

Что можно вам делать?
– Составить чек-лист или набор тест-кейсов
– Проверить граничные значения
– Найти логические или UI-баги
– Отточить работу с тестовой документацией
– Протестировать разные пользовательские сценарии

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

Ссылка на тренажер тут


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет!

Сегодня подготовил для вас новую статью, где подробно разобрал особенности тестирования сложных форм и валидации на веб-приложениях.

В статье я постарался описать ключевые моменты, на которые стоит обращать внимание:

• Какие типы веб-форм встречаются в проектах и нюансы работы с ними;
• Как правильно анализировать требования и планировать тестирование форм;
• Какие проверки обязательно включать: позитивные, негативные, UX, безопасность;
• И немного практических советов, которые помогут улучшить качество тестирования веб-приложений.

Статья уже доступна в моем блоге на платформе TestGrow:

📖 Ссылка на статью


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Эта тема часто всплывает, когда я общаюсь с тестировщиками, когда я вижу, что у многих нет системного подхода к наглядной декомпозии задач на тестирование. Поэтому я решил вам немного рассказать о том, как MindMap (или ментальная карта) может помочь систематизировать процесс анализа фичи и ее тестирования.

Что делаем:
1. Определяем, что тестируем. В центр карты ставим ключевой объект: функциональность, фичу или модуль. Это будет отправная точка.

2. Раскидываем основные блоки. Какие части функциональности есть? Какие модули? Какие роли пользователей? У каждой из этих веток потом появятся свои «подветки» — сценарии, проверки, особенности.

3. Добавляем вариативность. Что может пойти не так? Какие негативные сценарии? Где граничные условия? Какие данные нужно учитывать? На этом этапе подключаются тест-дизайн техники, но уже в визуальной форме.

4. Цвета и акценты. Например, если вы уже начали тестирование по mindmap, то красным можно помечать баги, синим — идеи для автоматизации, зелёным — то, что уже протестировано. Визуально это упрощает навигацию по карте.

5. Уточняем детали. Карта — это не статичный документ. Это рабочий инструмент, который живёт вместе с фичей. Появился новый сценарий — добавили.

6. Используем в команде. Отличный способ показать, что именно вы тестируете. Можно обсудить с разработчиком, продом или другим тестировщиком. Часто это помогает найти слепые зоны.

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

Рисовать MindMap можно тут:
• XMind
• MindMeister
• Miro
• Draw.io

В чём удобство? Mind Map помогает “разложить” фичу в голове. Ты видишь сразу все: от базы до крайних случаев. А ещё — это быстро, понятно и наглядно. Особенно спасает, когда сроки горят, а документации — как всегда — нет.


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

#реклама

Хочешь погрузиться в автоматизацию, но везде только и предлагают пройти обучения? 🫥

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

Роман Цакунов – QA Lead с опытом в IT больше 8 лет – запустил бот, который будет бесплатно отправлять тебе только полезную информацию. Никаких продаж, никаких курсов, только польза.

Подписывайся сразу, чтобы не потерять – t.me/rvtsakunovbot

КАКОЙ ОН — ИДЕАЛЬНЫЙ РАБОЧИЙ ДЕНЬ ТЕСТИРОВЩИКА?

Если честно — такого универсального дня не существует. Но если мечтать… то на мой взгляд идеальный день выглядит примерно так:

☕️ Утро начинается не с аврала, а с кофе и спокойного просмотра задач. Я понимаю, что мне нужно сделать сегодня, ничего не горит, всё прозрачно.

🧩 Есть время вникнуть в требования, задать вопросы, если что-то непонятно. Не в чат в 23:47, а нормально, по-людски — на встрече или в обсуждении с командой.

✅ Задачи приходят не “пожалуйста протестируй за час”, а с нормальными сроками, понятными критериями и, в идеале, с моками или тестовыми данными.

💬 Разработчики рядом. В смысле не буквально, а ментально. Можно обсудить поведение системы, быстро уточнить нюансы, не чувствовать, что ты “пришёл сломать их работу”.

🔍 В баг-репортах не надо объяснять, что “тестировщик — не враг”. Все понимают, что мы не придираемся, а реально помогаем сделать лучше.

📚 Есть возможность учиться. Час-полтора в день на что-то новое: курс, статья, эксперимент с автотестами, изучение нового инструмента. Не “в свободное время”, а прям по плану.

🤝 В конце дня нет чувства, что ты тушил пожары и просто выжил. А есть ощущение — “я сделал классную работу, помог команде, продвинул продукт вперёд”.

А какой для тебя идеальный день тестировщика? Делись в комментариях — интересно собрать картину из разных реальностей 👇


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

ОБУЧЕНИЕ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ JAVA НА РЕАЛЬНОМ ПРОЕКТЕ!

Всем привет!

Я хочу вам напомнить сегодня, что совместно с @kornyshev_e мы создали уникальную практическую программу обучения, которая по факту является мощной альтернативой менторству. Это не просто теория — вы будете работать с полноценным микросервисным приложением, развернутым в Docker, с использованием современных технологий:

🔧 Технический стек проекта:
- Язык и фреймворки: Java, JUnit 5, Selenium 4, RestAssured, Maven, Lombok и др.
- Инфраструктура: Docker-контейнеры, микросервисная архитектура, PostgreSQL БД
- Мониторинг и логи: ELK-стек (Elasticsearch + Logstash + Kibana)
- Очереди сообщений: Kafka для тестирования асинхронных процессов
- CI/CD: Настройка автотестов в Jenkins, генерация Allure-отчетов
- TMS: TestIT для управления тест-кейсами

📌 Что вы получите в подписке?
1. 50+ часов практических видео, где мы с нуля разрабатываем:
- Фреймворк для UI-тестов на Selenium
- Интеграционные тесты для REST API
- Работу с БД и кешированием (включая Redis)
- Настройку CI/CD пайплайна

2. Доступ к реальному проекту с:
- Полной Confluence-документацией
- Тест-кейсами в TestIT
- Баг-трекинговой системой

3. Персональную обратную связь:
- Чат для оперативных вопросов
- Еженедельные Zoom-разборы с анализом вашего кода

🎯 Ключевые преимущества:
- Нет необходимости в глубоких знаниях Java на старте, все рекомендации, материалы и лекции любых уровней прилагаются
- Практика на сложном проекте максимально приближенном к реальным промышленным решениям
- Эффективная альтернатива менторству с персональной обратной связью
- Дополнительные учебные материалы по всем аспектам автоматизации

💰 Стоимость:
- Комбо (ручное тестирование + автоматизация) — 5500₽/мес
- Только автоматизация — 3500₽/мес

🔗 Как начать обучение:
- Посмотреть вводную информацию по практике ручное + автоматизированное тестирование
Ссылка на то, как начать
- Начать сразу с автоматизации тестирования
Ссылка на то, как начать

Видео, в котором можно детальнее познакомиться с подпиской, проделанной работой и планами:
Ссылка на YouTube видео

🔮 В ближайших планах:
- BDD-подход с Cucumber
- Работа с Kafka
- Интеграция Spring-фреймворка
- Знакомство с Kubernetes (также на практике)

Лучшее время для старта в автоматизации — сейчас! Присоединяйтесь к нашему проекту!

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

Поэтому решил немного рассказать вам в целом про подход к тому, как это сделать:

1. Читаем внимательно. Не просто “пробегаем глазами”, а реально вникаем — что должно работать и для кого. Часто в требованиях между строк больше смысла, чем в прямом тексте.
2. Выделяем бизнес-логику. Что самое важное? Что обязательно должно работать? Без чего продукт просто “сломается” для пользователя?
3. Думаем про пользовательские сценарии. Кто, что и как будет делать в системе? Здесь помогает техника “user story” или просто здоровое любопытство: а что будет, если…?
4. Подключаем техники тест-дизайна. Классы эквивалентности, граничные значения, таблицы принятия решений, попарное тестирование — всё это помогает не просто тестировать “наугад”, а структурировать проверки и охватить больше с меньшими усилиями.
5. Формируем позитивные и негативные кейсы. Позитив — это “как должно быть”. Негатив — “как может пойти не так”. И вот тут начинается магия настоящего тестирования.
6. Уточняем всё, что вызывает сомнения. Не бойтесь задавать вопросы. Хороший тестировщик не тот, кто знает всё, а тот, кто не боится спросить.
7. Пишем тест-кейсы (или чек-листы). Основанные не на “догадках”, а на понимании. Если ты можешь объяснить, зачем ты пишешь этот тест — значит, ты на правильном пути.

Хорошие требования — это половина успеха и значительно может облегчить вам жизнь, но даже если их нет — не повод сдаваться. Это повод стать ещё внимательнее и скурпулезнее к пониманию логики работы системы, которую вам требуется протестировать.

Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

🧘‍♂️ Немного пятничного размышления:

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

🔍 “Нужно ли тестировщику техническое образование?”

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

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

👀 Как вы считаете:
— Даёт ли техническое образование заметное преимущество в тестировании?
— Можно ли спокойно обойтись без него, если есть желание и практика?
— И если всё-таки чего-то не хватает — что стоит подтянуть в первую очередь?

Буду рад вашим мыслям в комментариях — пятница отличный повод порассуждать 🙌

КУРС ПО АВТО ТЕСТИРОВАНИЮ ПОДОЙДЁТ ДЛЯ ПОЛНЫХ НУЛЕЙ В ТЕСТИРОВАНИИ?
⠀
Мое мнение по этому поводу — не стоит идти в автоматизацию, если ты совсем с нуля и не имеешь базовых знаний в тестировании.
⠀
Автоматизация тестирования — это не просто “написать автотест”. Это про понимание, что и зачем ты тестируешь. Без базовых знаний — как работают тест-кейсы 🧾, что такое баг-репорт 🐞, как устроен жизненный цикл ПО — ты будешь просто копировать чужой код, не понимая сути автотестирования.
⠀
Но хочу добавить важный момент!
Есть курсы, где базовый блок по ручному тестированию включён в программу. Он короткий, по делу и даёт тот самый фундамент, который нужен, чтобы перейти к автотестам осознанно, а не “потому что модно”.
⠀
📌 Поэтому, если смотрите курсы чисто на автоматизацию тестирования с нуля, то обязательно обращайте внимание, чтобы вам также дали основы по ручному тестированию.
⠀
Ещё момент, который часто упускают: вакансий чисто под автоматизацию становится всё меньше. Всё чаще ищут full-stack тестировщиков — тех, кто умеет и руками проверить, и автотест написать, и умеет работать с документацией и писать обычные тесты.
⠀
Так что если ты идёшь в автоматизацию просто потому, что “ручное — это не серьёзно” или “автотестерам платят больше” 💸 — то стоит обязательно подумать, точно ли ты найдешь вакансии по чистую автоматизацию.
⠀
💬 А у вас был опыт захода сразу в автоматизацию тестирования с нуля без обучения мануальному тестированию?
Делитесь своим опытом в комментариях 👇

Если у вас есть вопросы или темы, на которые вы хотели бы получить мой ответ, оставляйте их в форме ниже
https://forms.gle/pXhGLYzhAU2B2WJa6


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет!

Наконец-то после болезни голос восстановился и я смог записать новое видео на тему, о которой многие тут уже несколько раз спрашивали - Что нужно знать начинающему тестировщику?

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

Видео как обычно доступно на двух платформах:

Ссылка на youtube

Ссылка на VK


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

КАК СИСТЕМАТИЗИРОВАТЬ ПОЗИТИВНЫЕ И НЕГАТИВНЫЕ ПРОВЕРКИ В ТЕСТ-КЕЙСАХ?

🎉 Всем привет!

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

🧐 Вопрос звучал примерно так:
«Как систематизировать позитивные и негативные проверки в тест-кейсах?»

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

✅ Позитивные проверки

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

❌ Негативные проверки

С негативными тестами всё немного сложнее 😅
В зависимости от бизнес-логики:
• В одних случаях можно комбинировать проверки в рамках одного теста.
• В других — лучше разносить их по отдельным кейсам.

🔍 Чем я обычно руководствуюсь?
Главное правило: последовательность шагов в тестовом сценарии не должна нарушать бизнес-логику.

Что это значит?

📌 Пример:
Если после негативной проверки приложение (или веб-форма) меняет своё состояние — и вы не можете повторить ту же проверку без возврата к исходной точке, то такую проверку лучше выносить в отдельный тест.

Например:
Вы тестируете веб-приложение, где страница доступна только администратору. Если вы заходите под обычным пользователем, вас перекидывает на главную страницу.
➡️ Это значит, что состояние системы изменилось — и следующий шаг сценария уже не сработает корректно.

📎 А если состояние не меняется, и после ввода некорректных данных система просто показывает сообщение об ошибке, но вы остаетесь на той же странице — тогда можно объединить такие негативные шаги в один тест.

Пример:
🚫 Ввод недопустимых символов в поле логина → сообщение об ошибке → вы остаетесь на странице логина → можно продолжать ввод других значений в рамках одного теста.

Вот такой логикой я часто пользуюсь, чтобы оформлять тестовые сценарии в наиболее оптимальный и компактный вид 🧠📋

А как вы оформляете позитивные и негативные тесты? 🤔
Делитесь в комментариях 👇


Все мои проекты:Все мои проекты:
Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний