Продолжаю разбираться в видах тестирования. Сегодня я изучил два интересных направления: тестирование по знанию системы и подходы по тому, как вообще строится тестирование. Рассказываю простыми словами, как сам это понял.
Тестирование по знанию системы
Здесь всё делится на три подхода: чёрный ящик, белый ящик и серый ящик. Сначала эти названия звучали странно, но как только разобрался — всё стало логично.
1. Тестирование "чёрного ящика" (Black-box testing)
Это когда тестировщик не знает, как работает система внутри, и проверяет поведение приложения снаружи, по требованиям.
Пример:
Я открываю калькулятор, ввожу 2 + 2 и жду, что будет 4. Как программа это считает — неважно, главное, чтобы результат был правильный.
Применяется:
- при проверке интерфейса
- при ручном тестировании по требованиям
- когда нет доступа к коду
2. Тестирование "белого ящика" (White-box testing)
Тут всё наоборот — знание внутренней логики системы обязательно, мы проверяем, как она устроена, как написан код, какие есть условия и ветвления.
Пример:
Я знаю, что функция деления не должна допускать деления на 0, и проверяю, есть ли в коде эта проверка и как она работает.
Используется:
- разработчиками
- автоматизаторами
- на уровне юнит-тестов
3. Тестирование "серого ящика" (Gray-box testing)
Комбинация двух подходов: я что-то знаю о системе внутри, но всё ещё тестирую её больше как пользователь.
Пример:
Я знаю, что при регистрации пользователь должен сохраниться в базе, и иду проверить — записались ли данные в БД, но код не смотрю.
Подходы к тестированию: сценарное, исследовательское и ad hoc
Чем дальше погружаюсь в тестирование, тем интереснее становится наблюдать, насколько по-разному можно подходить к самой проверке приложения. Я выделил для себя три подхода, каждый из которых интересен по-своему.
1. Сценарное тестирование (Scenario-based testing)
Здесь тестировщик следует заранее продуманному сценарию. Это не строгое пошаговое руководство, как в тест-кейсах, но и не полная импровизация. Мы думаем как пользователь, и проверяем логичный путь выполнения задачи.
Пример:
Пользователь хочет купить товар:
- Заходит на сайт
- Ищет нужный товар
- Добавляет в корзину
- Оформляет заказ
- Получает подтверждение
Плюсы:
- ближе к реальному поведению
- помогает протестировать end-to-end сценарии
- часто используется при регрессе
Минусы:
- не охватывает отдельные мелкие проверки
- возможен субъективный подход
2. Исследовательское тестирование (Exploratory testing)
Это когда я исследую продукт без заранее прописанного плана — изучаю интерфейс, взаимодействую с системой и пытаюсь найти уязвимости, ошибки, нестандартные ситуации.
Пример:
Я запускаю приложение, жму на все подряд, меняю язык, перехожу в разные разделы, пробую ввести странные символы — и смотрю, что произойдёт.
Плюсы:
- можно найти неожиданные баги
- идеально подходит, когда нет документации
- помогает развивать креативное мышление
Минусы:
- сложно воспроизводить баги, если не записывал шаги
- требует опыта
- плохо подходит для повторного тестирования
3. Ad hoc тестирование
На первый взгляд похоже на исследовательское, но отличается тем, что здесь вообще нет подготовки и даже логической структуры — просто "побродить по системе" и попробовать всё подряд.
Пример:
Зашёл в админку, добавил случайный товар, удалил его, перешёл на другой раздел, быстро нажал три кнопки подряд — и проверяю, не сломалось ли что-то.
Плюсы:
- очень быстрый способ что-то проверить
- помогает найти очевидные баги
- не требует времени на подготовку
Минусы:
- нет документации по шагам
- нельзя использовать повторно
- нельзя точно сказать, что протестировано
Вывод
Чем больше я изучаю, тем сильнее понимаю, что всё зависит от задачи. Где-то нужен чёткий сценарий, где-то свобода действий, а иногда полезно просто "потыкать" и посмотреть, как система себя поведёт.
Дальше буду разбираться с тем, что такое тест-кейсы, чек-листы и баг-репорты, как их составлять и зачем вообще это всё нужно. Как всегда, делюсь с вами своими шагами на этом пути!