Все статьи

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

Большинство джуниоров считают severity и priority одним и тем же — вот почему это неправильно и как понимание разницы меняет отношение всей команды к вашей работе.

Тестировать всё поровну — не тщательность, а гарантия пропустить то, что важно. Практический фреймворк расстановки приоритетов по рискам.

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

Если QA подключается к спринту на девятый день, вы запускаете Waterfall с двухнедельными часами. Вот как QA реально вписывается в каждую церемонию и фазу Agile.

Отправить баг-репорт. Это только начало. Вот что означает каждый статус от New до Closed, кто владеет каждым переходом и как не дать багам тихо исчезать.

Большинство команд пишут слишком много E2E-тестов и недостаточно юнит-тестов. Пирамида тестирования даёт ментальную модель для правильного распределения и объясняет, почему форма важна.

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

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

TDD описывают с точки зрения разработчика. Вот что это означает для QA, где вы вписываетесь в TDD-команду, что такое ATDD и как BDD расширяет паттерн на всю команду.

Дымовое и регрессионное тестирование часто путают. Они отвечают на разные вопросы, запускаются в разное время и имеют разный охват. Вот чёткое объяснение.

Протестировать всё невозможно — но можно протестировать правильные вещи. Классы эквивалентности и граничные значения помогают выбрать минимум тестов с максимальным покрытием.

Команды используют эти термины по-разному, и путаница реальна. Тест-сценарий — это вопрос, тест-кейс — полная процедура ответа на него. Когда использовать каждый?

"Правильно ли мы создаём продукт?" vs "Правильный ли продукт мы создаём?" — это классическое различие описывает два принципиально разных подхода к тестированию.

Если вы тестировали приложение без чтения кода — вы делали black-box. Если смотрели на код чтобы понять, что тестировать — white-box. Когда применяется каждый подход?

Тест-план отвечает на один вопрос: как мы собираемся это тестировать? Не просто "запустим Selenium тесты" — а конкретно что, кто, когда, с какими данными и что значит "готово".

Приёмочное тестирование — это финальная проверка перед выпуском ПО. Оно отвечает на вопрос: делает ли это ПО то, что нужно бизнесу?

В TDD тесты пишутся до кода. Для QA инженеров понимание TDD важно для сотрудничества с разработчиками и применения аналогичного подхода к приёмочному и интеграционному тестированию.

"Как вы знаете, что ваше тестирование эффективно?" Если вы не можете ответить на этот вопрос, вы тестируете на ощупь. Метрики дают данные для улучшения процесса и обоснования ресурсов.

Ваше приложение отлично работает с 1 пользователем. А с 1000? Нагрузочное тестирование отвечает на вопросы, на которые функциональное не может: насколько быстро, сколько пользователей выдержит.

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

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