← назад к разделу

Баг-репорт «Каталог открывается очень медленно» вернулся с пометкой «не воспроизводится»: разработчик открыл каталог у себя, получил страницу за полсекунды и закрыл задачу. Обе стороны честны — в отчёте не было ни числа, ни условия: сколько ждали, на каком окружении, сколько было товаров и сколько людей пользовалось системой в ту же минуту.

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

одно и то же действие: открыть каталог порог из требований: 2 с 0,4 с1 человек 0,7 с100 человек 1,8 с500 человек 5 спорог пробит1000 человек ответа нет2000 человек 7 % запросов закончились ошибкой — в среднем этого не видно

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

Обязательно

«Медленно» — это не оценка, а число

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

Дальше нужны ориентиры: отклик до 0,1 секунды человек воспринимает как мгновенный, до 1 секунды — как «поток мысли не прервался», после 10 секунд внимание уходит. Это грубые рамки: настоящий порог записан в требованиях, а если его там нет — это находка по требованиям. И последнее — среднее: «в среднем страница открывается за секунду» может означать, что девяносто пять человек из ста получили её за 0,3 секунды, а пятеро ждали по девять. Поэтому пишут процентиль: отсортируйте сто замеров от быстрых к медленным и возьмите девяносто пятый — это p95. Требование целиком: «время ответа не более 2 секунд для 95 % запросов при 500 одновременных пользователях».

Нагрузочная, стрессовая, объёмная: одно действие на разных числахспросят на собеседовании

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

  • Нагрузочная (load) — «держим ли обещанное»: берут ожидаемое число из требований или из статистики пикового дня. Ответ: «при 500 одновременных заказах p95 — 1,6 секунды, ошибок 0,02 %».
  • Стрессовая (stress) — «как именно мы ломаемся»: нагрузку поднимают выше расчётной. Хорошо — плавная деградация: медленнее, лишних не пускаем, заказы не теряем. Плохо — обвал: принятые заказы пропадают, а после спада система сама не поднимается.
  • Объёмная (volume) — меняет не людей, а данные: один пользователь, но таблица на десять миллионов строк или корзина на триста позиций. Симптом: на стенде летает, а у заказчика с историей за три года открывается минуту.
  • Выносливость и масштабируемость узнают по симптому: первая держит обычную нагрузку восемь-двенадцать часов и ловит утечки памяти и растущие очереди («к вечеру тормозит, после перезапуска нормально»), вторая спрашивает, выдержим ли вдвое больше людей на вдвое большем числе серверов — часто нет, всё упирается в одну базу.

Ручной тестировщик такие прогоны обычно не запускает; его работа — заметить симптом, привязать его к числу и условиям и узнать нужный вид в формулировке требования: «выдерживать 500 одновременных заказов» — нагрузочная, «а что при 5000» — стрессовая, «а с историей за пять лет» — объёмная.

Безопасность: что видно без специальных инструментов

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

  • Чужие данные по прямой ссылке. Свой заказ /orders/10234 открыть под другим пользователем: ждём «нет доступа». Открылся чужой заказ с телефоном и адресом доставки — серьёзная находка. Повторить запросом к сервису: интерфейс ссылку не покажет, а запрос отработает.
  • Спрятанная кнопка — не запрет. У роли «наблюдатель» кнопки «Удалить» нет, но запрос остался: скопируйте его из панели «Сеть» («Copy as cURL») и повторите под учётной записью без прав.
  • Время жизни входа. После «Выйти» кнопка «Назад» не показывает личные данные; сессия умирает по сроку; смена пароля в одном браузере выбрасывает второй — иначе она не спасает от кражи учётной записи.
  • Адресная строка. Пароль, токен доступа или номер карты в ссылке — находка сама по себе: ссылки оседают в истории браузера, в журналах сервера и в пересланных сообщениях.
  • Что продукт рассказывает в ошибках. «Неверный пароль для пользователя ivanov» подтверждает постороннему, что такой пользователь есть: формулировка нужна одна на оба случая. Сюда же имя базы и пути к файлам на странице ошибки.
  • Загрузка файлов. Исполняемый файл, переименованный в .jpg, и картинка на сто мегабайт: продукт должен вежливо отказать, а не принять и упасть.

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

Удобство: «работает» и «можно пользоваться» — разные проверкиспросят на собеседовании

Экран может быть безупречен технически и невыносим по существу: кнопки нажимаются, формы отправляются, вёрстка не разъехалась, а дойти до конца невозможно. Проверка интерфейса отвечает «работает ли», проверка удобства — «получится ли у человека». Полноценное исследование — наблюдение за пятью людьми не из команды, которым дали задачу без подсказок, но часть видно каждый день: сколько шагов до цели и сколько лишних; форма из двенадцати полей, очищающаяся целиком из-за неверного индекса; «Ошибка 0x80070005», которая не говорит человеку ничего, против «Не удалось сохранить: файл больше 10 МБ». Пишут такие находки без слова «неудобно», шагами и последствием: не «форма неудобная», а «на шаге 4 из 6 после ошибки в индексе форма очищается полностью — человек вводит двенадцать полей заново» (как это оформить).

Доступность: клавиатура, контраст и подписи

Доступность слышится как «для слепых, а у нас таких пользователей нет», но в этой группе оказываются почти все по очереди: человек со сломанной рукой, неделю работающий одной клавиатурой, или телефон на ярком солнце, где бледно-серый текст не читается. Во многих странах это ещё и требование закона: в мире опираются на WCAG, в России есть ГОСТ Р 52872. Четыре проверки делаются за пятнадцать минут без единого инструмента.

  • Уберите мышь и пройдите сценарий клавишей Tab: до всех ли элементов можно добраться и видно ли, где сейчас фокус, — если рамку «убрали, потому что некрасиво», человек без мыши слепнет.
  • Померьте контраст текста к фону: порог WCAG — 4,5:1 для обычного текста и 3:1 для крупного. Не на глаз: в инструментах разработчика при выборе цвета показано готовое соотношение.
  • Проверьте подписи. Подпись, живущая только подсказкой внутри поля, исчезает, как только человек начинает печатать, а для читалки её нет вовсе. Сюда же «смысл не передают одним цветом»: красная рамка без текста ошибки ничего не сообщает тому, кто не различает красный.
  • Послушайте продукт. VoiceOver на macOS включается сочетанием Cmd+F5, на Windows ставят бесплатную NVDA, на Android есть TalkBack: если вместо «Имя, поле ввода» читалка говорит «поле ввода, поле ввода, кнопка», подписей нет.

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

Совместимость: браузеры, экраны, версии — и установкаспросят на собеседовании

«У нас работает» почти всегда означает «работает в одном браузере на одном ноутбуке с одним размером окна». Проверяют не по логотипам, а по движкам — Chrome и Edge собраны на Chromium, Safari на WebKit, Firefox на Gecko, а на iPhone любой браузер внутри Safari, — и по краям: окно от 320 точек, повёрнутый телефон, системное увеличение 125 % или 150 %, медленная сеть, автоматический перевод, меняющий длину подписей. Как собрать набор по статистике своих пользователей и что на нём проходить — в статье про кроссбраузерное и мобильное тестирование.

Рядом живёт инсталляционная проверка — установка, обновление и удаление: ставится ли продукт на чистую систему, обновляется ли со старой версии без потери данных, что остаётся после удаления. Отдельно проверяют обновление через версию, с 1.0 сразу на 3.0: именно там теряется корзина или сохранённые настройки, потому что данные переносились по шагам, а шаг пропустили.

Альфа, бета и гамма: продукт отдают чужим рукамспросят на собеседовании

Через месяц работы над одним продуктом команда перестаёт его видеть: все ходят одним маршрутом и не замечают, что кнопку «Оплатить» видно только после прокрутки. Лекарство — люди со стороны, и по тому, насколько они посторонние, этапы и называются. Альфа — внутри компании: соседние отделы и дружественные пользователи, продукт ещё сырой. Бета — снаружи: настоящие пользователи берут почти готовый продукт и сообщают о проблемах. Гамма — финальная шлифовка по последним отзывам. Ценность в чужих руках: другие устройства, другой интернет, сценарии, до которых внутри не додумались бы. Работа тестировщика здесь — не проводить бету, а разбирать поток сообщений: превращать «у меня всё сломалось» в воспроизводимые находки и отделять единичные случаи от массовых.

Дополнительно: при первом чтении можно пропустить

Глубже: A/B-тест это не вид тестированиярасширенное

Слово «тест» в A/B-тесте обманывает: это эксперимент продукта, а не проверка качества. Пользователей делят на группы, одной показывают старую кнопку, другой новую, и сравнивают, где больше покупок. Решает продакт по метрикам, а не тестировщик по чек-листу.

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

Коротко

  • Нефункциональная проверка отвечает числом при записанных условиях: без числа, окружения и объёма данных находка о скорости не воспроизводится.
  • Время смотрят в панели «Сеть», там же видно, ждал сервер или рисовал браузер. Ориентиры — 0,1 секунды как мгновенно, 1 секунда как без разрыва, 10 секунд как потеря внимания.
  • В требованиях пишут процентиль, а не среднее: p95 — время, в которое уложился самый медленный из двадцати запросов.
  • Нагрузочная спрашивает «держим ли ожидаемое», стрессовая — «как ломаемся и поднимаемся ли сами», объёмная меняет количество данных.
  • Шесть проверок безопасности делаются без спецсредств: чужие данные по прямой ссылке, повтор запроса под ролью без прав, жизнь сессии после выхода и смены пароля, секреты в адресной строке, болтливые ошибки, загрузка не той картинки — и только на тестовом окружении.
  • Удобство пишут шагами и последствием, а не словом «неудобно»; доступность проверяется за пятнадцать минут (клавиатура с видимым фокусом, контраст 4,5:1, настоящие подписи, читалка); совместимость считают по движкам браузеров, а установку — обновлением через версию.
  • A/B-тест это эксперимент продукта, а не проверка качества; тестируют сам механизм: деление на группы, стабильность варианта, подсчёт метрик, выключение.

Что почитать дальше