Что такое тестирование

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

Во frontend это хорошо видно. Компонент может выглядеть правильно на макете, но ломаться при медленной сети, не показывать ошибку API, отправлять форму дважды или быть недоступным с клавиатуры. Поэтому вы проверяете не только то, работает ли кнопка. Важно проверить, что происходит вокруг нее.

Хорошая короткая формулировка может звучать так:

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

Эту фразу можно адаптировать под свой опыт. Если вы писали автотесты, добавьте конкретный уровень: unit, integration или e2e. Если не писали, честно скажите, что участвовали в ручной проверке сценариев и понимаете, какие кейсы важно покрывать.

Виды тестирования удобно объяснять через вопрос: какой риск вы закрываете. Функциональные проверки отвечают, выполняется ли нужное действие. Например, пользователь ввел email и пароль, нажал кнопку и получил понятный результат.

Нефункциональные проверки отвечают, насколько хорошо это работает. Страница может логинить пользователя, но делать это слишком медленно, ломать фокус, не показывать ошибку screen reader или неправильно вести себя на мобильном устройстве. Еще один frontend-риск - небезопасная работа с данными из API или CMS. Если вывести внешний HTML напрямую, можно получить XSS. Это тоже качество продукта, а не второстепенная деталь.

Допустим, у вас есть форма подписки. Слабая проверка ограничится тем, что после ввода корректного email появляется сообщение об успехе. Это полезно, но недостаточно.

// Плохой тестовый фокус: проверен только идеальный сценарий
await user.type(screen.getByLabelText(/email/i), "user@example.com");
await user.click(screen.getByRole("button", { name: /subscribe/i }));
expect(await screen.findByText(/success/i)).toBeInTheDocument();

Что может остаться незамеченным: кнопка не блокируется при повторном клике, ошибка API стирает введенный email, пользователь не понимает причину отказа, а состояние загрузки не отображается. Может появиться лишний запрос или двойная подписка. Безопаснее проверять не только успех. Проверьте блокировку submit на время запроса, понятную ошибку, сохранность введенных данных и возможность повторить действие после сбоя.

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

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

Если вопрос звучит просто, от вас обычно ждут не энциклопедию, а зрелую рамку. Начните с определения, затем покажите цель, виды проверок и frontend-пример. Обязательно добавьте ограничение: тесты снижают риск, но не гарантируют отсутствие всех дефектов.

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