Вы оплатили заказ в приложении доставки, и деньги списались дважды. Почти всегда такое можно заметить раньше: кто-то должен пройти тот же сценарий до вас и сказать «стоп, тут неправильно».
Тестирование — это проверка, что программа делает то, чего от неё ждут, и не делает того, чего не должна.
Тестирование — это одно сравнение: эталон из требований против того, что произошло на самом деле. Совпало — проверка пройдена, не совпало — баг.
Что значит «проверить»
Нажали кнопку, что-то произошло. Правильно это или нет, экран не подскажет: верную сумму и неверную приложение показывает одинаково спокойно. Ответ получают одним способом: сравнивают фактический результат с эталоном, с тем «как должно быть». Совпало — проверка пройдена, не совпало — находка для команды. По эталону занятый адрес почты в форме регистрации даёт ошибку «такой адрес уже есть»; форма зависла или завела второй аккаунт — это баг.
Откуда берётся эталон, если никто ничего толком не написал? Его ищут по лестнице, спускаясь на ступеньку ниже только тогда, когда на текущей ответа нет: описание задачи и критерии приёмки → макет дизайнера → как функция работает на продукте сейчас → соседний похожий экран → здравый смысл (приложение не падает, деньги не исчезают) → вопрос аналитику. Нет ответа и на последней — это находка: дыра в требованиях, найденная раньше, чем разработчик угадал за всех. Худшее решение — придумать эталон самому и сравнить продукт с собственной фантазией.
Проверка не заканчивается на экране: одно действие оставляет след в нескольких местах — сообщение, запись в базе, письмо, ответ сервиса. Экран говорит «заказ создан», а записи в базе нет: такой баг глазами не поймать, для этого дальше есть инструменты разработчика, SQL и запросы к сервису. Проверки бывают позитивные (всё вводят правильно) и негативные — пустое поле, буквы вместо цифр; багов больше во вторых, и придумывать их учат тест-кейсы.
Почему программы ломаются
Чаще всего ломается не код, а понимание. Аналитик написал «скидка 10 % применяется к заказу», имея в виду заказ вместе с доставкой: так договорились на встрече, но в строку это не попало. Разработчик посчитал скидку от суммы товаров — доставка ведь не товар. Код без единой ошибки, проверка по той же строке проходит, а клиент с заказом на 3000 рублей и доставкой 400 получает скидку 300 вместо 340.
Остальное проще: человек ошибается (перепутал знак, забыл пустое поле); продукт меняется — починили одно, задели соседнее; реальный мир непредсказуем — медленный интернет, имя с апострофом, двойное нажатие «Оплатить». Баги — норма, а не ЧП: вопрос не «есть ли они», а «найдём ли раньше пользователя». Цепочку «ошибка человека → дефект → сбой» разбирает статья что такое баг.
Проверить всё нельзя
Форма заказа: три поля (имя, телефон, адрес) по пять осмысленных значений каждое — нормальное, пустое, длинное, со спецсимволами, с пробелами по краям — дают 5 × 5 × 5 = 125 сочетаний. Добавьте дату доставки на тридцать дней вперёд и четыре способа оплаты: 125 × 30 × 4 = 15 000. По минуте на проверку это 250 часов, больше месяца без выходных, на одну форму. А в поле «комментарий» вариантов бесконечно.
Отсюда главное в профессии: тестирование — это выбор, что проверить первым, а не попытка перебрать всё. Выбирают не наугад: есть техники тест-дизайна, сжимающие тысячи сочетаний до десятка, и таблицы решений с попарным перебором, когда варианты влияют друг на друга.
Помогают две особенности. Баги кучкуются там, где логика сложная, где недавно меняли код, где работал новичок: нашли три бага в оформлении заказа — ищите там же четвёртый. Набор проверок стареет: старый чек-лист ловит всё меньше, найденное по нему починили, а новые ошибки прячутся там, куда он не заглядывает. Это парадокс пестицида (насекомые привыкают к одному средству); лечится обновлением набора и исследовательским тестированием.
Цена бага растёт со временем
Та же скидка стоит команде разных денег, смотря на каком этапе её заметили.
- Требования. Вопрос «скидка считается до доставки или после?» стоит пяти минут и правки одной строки: бага не существует вовсе.
- Разработка. Стенд показал не ту сумму, разработчик правит формулу в коде, который писал вчера: час работы, за пределами команды никто не заметил.
- Перед релизом. Кроме формулы перепроверяют всё рядом: корзину, чеки, отчёты бухгалтерии, письма клиентам; релиз сдвигается на день-два.
- После релиза. Ночное исправление, ручная сверка созданных заказов, возврат разницы переплатившим, ответы в поддержке.
Дорожает потому, что чем позже, тем больше построено поверх ошибки: на неверную формулу опираются соседние функции, по ней написаны проверки и документация, ею пользуется поддержка. Добавляются испорченные данные: база наполнилась заказами с неправильной скидкой, и исправленный код их не вылечит — старые чинят отдельным заходом. А часть клиентов ошибку уже увидела, и эта строка счёта кодом не чинится.
Тестирование — это не отладка
Тестировщик находит проблему и описывает её так, чтобы её повторили: при таких шагах вместо A получается B. Отладка — то, что делает дальше разработчик: лезет в код, ищет причину, чинит. Знать, в какой строке ошибка, тестировщику не нужно, нужно уметь показать, что она есть. И он не ломает продукт, а показывает, что тот уже сломан при определённых условиях: баг существовал и до него, просто его никто не встретил.
Что считать качеством
Ноля багов не бывает, даже одну форму нельзя проверить целиком. Качество — это отсутствие серьёзных проблем на важных сценариях: криво выровненная подпись в настройках переживётся, ошибка на оплате — никогда. Насколько проблема серьёзна, зависит от продукта: в банковском переводе неверная копейка катастрофа, а игре простят подтормаживание анимации.
Верификация — «сделали ли мы то, что написано в требованиях», валидация — «а тот ли продукт мы сделали». Формулу написали ровно по требованию, проверки сошлись — верификация пройдена; но клиент ждал скидку на весь заказ — валидация провалена.
Семь принципов тестирования
Всё, что выше, разбросано по разделам, а в отрасли эти наблюдения давно сведены в семь пунктов с именами — на них ссылаются, когда спорят, сколько ещё проверять и что значит зелёный прогон.
- Тестирование показывает наличие дефектов, а не их отсутствие. Зелёный прогон говорит только о самих этих проверках.
- Исчерпывающее тестирование невозможно. 15 000 сочетаний на одной форме — отсюда и выбор, что проверять первым.
- Раннее тестирование. Вопрос к требованиям стоит пяти минут, та же ошибка после выпуска — ночного исправления и возвратов.
- Скопление дефектов. Нашли три бага в оформлении заказа — ищите там же четвёртый.
- Парадокс пестицида. Один и тот же набор проверок со временем перестаёт находить новое.
- Тестирование зависит от контекста. Банковский перевод и игру проверяют по-разному: цена ошибки разная.
- Заблуждение об отсутствии ошибок. Продукт без единого бага, но не тот, который нужен людям, не помог никому.
Рядом стоит ещё одно деление — по тому, работает ли программа во время проверки. Читать требования, макет или код глазами, не запуская её, — статическое тестирование; всё, где приложение запущено и с ним что-то делают, — динамическое. Статическое возможно, когда кода ещё нет, и потому даёт самые дешёвые находки — ровно те, о которых третий принцип.
Коротко
- Тестирование — одно сравнение: как должно быть против того, что произошло; не совпало — баг. И сравнивают не только экран: письмо, запись в базе, ответ сервиса — та же проверка.
- Эталон ищут по лестнице: задача, макет, текущее поведение, соседний экран, здравый смысл, вопрос аналитику. Нет ответа нигде — это находка, а не повод придумать его самому.
- Все сочетания не перебрать даже на одной форме: 15 000 вариантов по минуте = 250 часов. Работа — выбор, что проверить первым.
- Чем позже найден баг, тем дороже: поверх ошибки построены код и документация, а в базе испорченные данные.
- Качество — не ноль багов, а отсутствие серьёзных проблем на важных сценариях; зелёный прогон доказывает лишь то, что прошли эти проверки, — первый из семи принципов.
Что почитать дальше
- Кто такой тестировщик и его роль в команде — рабочий день и чем QA отличается от тестирования.
- Ручное и автоматизированное тестирование — что проверяет человек, а что берёт на себя код.
- Жизненный цикл ПО и место тестирования — где появляются ранние и дешёвые находки.
- Техники тест-дизайна — как из тысяч сочетаний оставить десяток осмысленных.