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

Новичок обычно живёт в первой группе и забывает про вторую. А зря: «работает, но открывается 30 секунд» — это тоже проблема, за которую пользователь уйдёт.

Функциональное тестирование: делает ли то, что нужно

Это проверка функций — конкретных действий, которые продукт должен уметь. Каждая проверка сводится к «нажал — получил ожидаемое».

Примеры для интернет-магазина:

  • Можно ли зарегистрироваться с правильными данными?
  • Появляется ли ошибка при занятом e-mail?
  • Считается ли сумма корзины верно?
  • Приходит ли письмо после заказа?

Функциональное тестирование — основа работы ручного тестировщика и то, с чего начинают. Именно на него пишут тест-кейсы: «при таких-то шагах должно получиться то-то». Всё остальное в программе обучения во многом крутится вокруг него.

Нефункциональное тестирование: насколько хорошо

Здесь функция может работать правильно, но всё равно быть проблема — в скорости, удобстве, надёжности. Основные направления:

  • Производительность (скорость). Быстро ли грузятся страницы, выдержит ли система наплыв покупателей в чёрную пятницу. Проверку под нагрузкой называют нагрузочным тестированием — и обычно её автоматизируют, потому что руками тысячу пользователей не изобразишь.
  • Удобство (юзабилити). Понятно ли пользоваться, не запутаешься ли, видно ли ошибки. Это как раз то, что хорошо ловит живой человек и совсем не ловит автотест.
  • Безопасность. Нельзя ли увидеть чужой заказ, подобрать пароль, влезть куда не следует.
  • Совместимость. Одинаково ли работает в разных браузерах и на разных телефонах — про это отдельная статья про кроссбраузерное тестирование.
  • Надёжность и восстановление. Что будет, если пропадёт интернет посреди оплаты; не потеряются ли данные.

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

Позитивное и негативное тестирование

Ещё одно важное деление, которое пронизывает всё функциональное тестирование.

  • Позитивное: проверяем, что при правильных действиях всё работает. Ввели верный логин и пароль — вошли.
  • Негативное: проверяем, что при неправильных действиях программа ведёт себя достойно — не ломается, а понятно сообщает об ошибке. Ввели пароль из одного символа, оставили поле пустым, вписали текст вместо числа, загрузили файл в 2 гигабайта.

Запомните главное правило новичка: большинство багов живёт в негативных сценариях. «Счастливый путь», где всё вводят правильно, разработчик обычно проверяет сам. А вот что будет при ошибке пользователя — часто не продумано. Именно там вы найдёте больше всего проблем.

Где это применяется

На практике вы редко говорите «сейчас проведу нефункциональное тестирование». Вы просто, проверяя функцию, держите в голове несколько вопросов: работает ли она (функционально), при ошибках ведёт ли себя достойно (негативно), быстро ли, удобно ли, безопасно ли. Чем больше этих углов вы держите, тем меньше пропустите.

Где спотыкаются начинающие:

  • Проверяют только позитив. «Ввёл всё правильно — работает» — и на этом успокаиваются. А баги ждут в негативных сценариях.
  • Забывают про удобство и скорость. Функция формально работает, но пользоваться невозможно — это тоже стоит завести как проблему.
  • Пытаются лезть в нагрузку и безопасность руками без понимания. Это отдельные специализации; на старте достаточно уметь про них рассказать и заметить очевидное.

Что учить дальше. Разберитесь с чёрным, белым и серым ящиком и терминами прогонов (smoke, регресс, sanity), а затем переходите к практике — как писать тест-кейсы.