Любая программа — это набор правил, которые кто-то написал, спеша и держа в голове ограниченный кусочек картины. Поэтому программы ошибаются: кнопка не нажимается, деньги списываются дважды, форма пропускает пустое имя. Тестирование — это то, что ловит такие ошибки до того, как их увидит пользователь.
Если совсем просто: тестирование — это проверка, что программа делает то, что от неё ждут, и не делает того, чего не должна. Тестировщик заранее придумывает, как программой будут пользоваться (и правильно, и неправильно), проходит эти сценарии и сравнивает, что получилось, с тем, что ожидалось.
Почему программы ломаются
Ошибку в программе называют багом (bug — «жучок»). Баги появляются не потому, что разработчики плохие, а потому, что софт сложный. Типичные причины:
- Человек ошибается. Перепутал знак, забыл проверить пустое поле, не учёл, что пользователь введёт текст вместо числа.
- Требования поняли по-разному. Аналитик имел в виду одно, разработчик прочитал другое — и оба уверены, что правы.
- Всё меняется. Починили одно — задели соседнее. Добавили новую функцию — сломали старую.
- Реальный мир непредсказуем. Медленный интернет, старый телефон, странные данные, два действия одновременно.
Вывод простой: баги — это норма, а не исключение. Вопрос не «есть ли они», а «найдём ли мы их раньше пользователя».
Проверяем ожидаемое против фактического
В основе всего тестирования лежит одно сравнение: ожидаемый результат против фактического.
Например, форма регистрации. Ожидаемо: если ввести уже занятый e-mail, появится понятная ошибка «такой адрес уже есть». Тестировщик вводит занятый адрес и смотрит, что произошло на самом деле. Совпало с ожиданием — проверка пройдена. Не совпало (форма молча зависла, или создала второго пользователя) — это баг.
Ожидаемый результат берётся не из головы, а из требований: описания задачи, макета, здравого смысла. Поэтому тестировщик всегда должен понимать, «как должно быть» — иначе не с чем сравнивать.
Цена бага растёт со временем
Главный аргумент «зачем всё это» — деньги. Один и тот же баг стоит по-разному в зависимости от того, когда его нашли:
- На этапе требований — почти бесплатно: поправить строчку в документе.
- Во время разработки — дёшево: разработчик меняет код, который ещё свежий в голове.
- Перед релизом — дороже: нужно всё перепроверить, релиз откладывается.
- У пользователя — дорого: недовольные клиенты, срочные исправления по ночам, испорченная репутация, а иногда и прямые убытки (списанные деньги, утёкшие данные).
Поэтому тестирование стараются начинать как можно раньше. Чем раньше поймали — тем дешевле починить.
Тестирование — это не отладка и не «сломать всё»
Два частых недопонимания у новичков.
Тестирование ≠ отладка. Тестировщик находит и описывает проблему («при таких-то шагах вместо A получается B»). Отладка (debugging) — это когда разработчик ищет в коде причину и чинит. Это разные роли и разная работа.
Тестировщик не «ломает» программу. Он показывает, что она уже сломана при определённых условиях. Баг существовал и до тестировщика — просто его никто не заметил. Хороший тестировщик не самоутверждается за счёт разработчиков, а помогает команде выпустить продукт, которым не стыдно пользоваться.
Ещё полезное различие: качество — это не «ноль багов». Идеального софта не бывает. Качество — это когда продукт решает задачу пользователя и в нём нет серьёзных проблем на важных сценариях. Мелкий баг в редкой настройке можно пережить; падение при оплате — нет.
Где это применяется
Проверка «ожидаемое против фактического» — это то, чем тестировщик занимается каждый день, на любой задаче: от новой кнопки до сложного платёжного сценария. Всё остальное в этой программе — про то, как делать эту проверку системно: как придумывать сценарии (тест-кейсы), как ничего не забыть (техники тест-дизайна), как понятно описать найденное (баг-репорт).
Где спотыкаются начинающие:
- Проверяют только «счастливый путь» — когда всё вводят правильно. А большинство багов живёт там, где пользователь ошибается: пустые поля, лишние пробелы, слишком длинный текст.
- Не знают, «как должно быть», и потому не понимают, баг перед ними или нет. Всегда сверяйтесь с требованиями.
- Считают своей задачей «сломать» продукт и спорят с разработчиками. Задача — выпустить хороший продукт вместе.
Что учить дальше. Разберитесь, кто такой тестировщик и что он делает каждый день, чем ручное тестирование отличается от автоматизированного и как устроен жизненный цикл продукта, чтобы понять, где в нём ваше место.