1. Введение в тестирование: основы и виды
Введение в тестирование: основы и виды
Представьте, что вы переводите 50 000 рублей другу через мобильное приложение. Вы вводите номер, нажимаете «Отправить», деньги списываются с вашего счета, но другу не приходят. Они просто исчезли.
Для пользователя это катастрофа. Для банка — репутационный риск и судебные иски. А для IT-команды — это пропущенный баг (ошибка).
Тестирование — это не просто «тыканье кнопок» в надежде что-то сломать. Это инженерный процесс проверки того, соответствует ли фактическое поведение программы ожидаемому.
В этой статье мы разберем фундамент профессии, без которого невозможно пройти ни одно собеседование на позицию Junior QA.
QA, QC и Тестирование: в чем разница?
На собеседованиях это самый популярный вопрос для новичков. Многие путают эти понятия, но между ними есть строгая иерархия.
!Иерархия понятий: QA включает в себя QC, а QC включает в себя Тестирование
> «QA — это про процесс, QC — про продукт, а Тестирование — про конкретные действия».
Почему баги нужно искать рано?
Существует правило: чем позже найден баг, тем дороже его исправить. Если ошибку нашли на этапе требований, её исправление стоит копейки (переписать текст). Если ошибку нашли пользователи в продакшене (боевой версии), это стоит огромных денег (хотфиксы, простой системы, отток клиентов).
Экономическую целесообразность тестирования можно описать упрощенной моделью роста стоимости ошибки:
где — итоговая стоимость исправления ошибки, — базовая стоимость времени разработчика (например, 1 час работы), — коэффициент этапа обнаружения (например, 1 на этапе требований, 10 на этапе разработки, 100 на этапе релиза).
Если час работы стоит 1000 рублей, то исправление бага в требованиях стоит рублей. Тот же баг, найденный пользователем, обойдется компании в рублей.
Основные виды тестирования
Классификаций тестирования десятки, но для старта карьеры критически важно понимать следующие четыре группы.
1. По доступу к коду (Коробки)
* Black Box (Черный ящик): Вы не видите код и не знаете, как устроена система внутри. Вы действуете как обычный пользователь: нажимаете кнопки, заполняете формы и смотрите на результат. Пример:* Вы вводите логин и пароль на сайте ru.hexlet.io. Вы не знаете, какой SQL-запрос идет в базу данных, вам важно лишь, вошли вы в систему или нет. * White Box (Белый ящик): У вас есть доступ к коду. Вы проверяете логику работы функций, циклов и условий. Этим чаще занимаются разработчики или автотестировщики. * Grey Box (Серый ящик): Комбинация. Вы видите часть «внутренностей» (например, базу данных или логи сервера), но тестируете через интерфейс.
2. По цели (Функциональное vs Нефункциональное)
Это разделение отвечает на вопросы «Что делает система?» и «Как она это делает?».
Функциональное тестирование проверяет бизнес-логику. Вопрос:* Работает ли функция оплаты? Пример:* При нажатии кнопки «Купить» товар добавляется в корзину.
Нефункциональное тестирование проверяет свойства системы. Вопрос:* Как быстро проходит оплата? Удобно ли нажимать кнопку? Безопасно ли это? Виды:* * Тестирование производительности (Performance): выдержит ли сайт 1000 пользователей одновременно? * Тестирование удобства (Usability): понятно ли пользователю, куда нажимать? * Тестирование безопасности (Security): можно ли украсть данные?
3. По позитивности сценариев
Позитивное тестирование: Проверка того, что программа работает правильно при корректных* данных. Это «Happy Path» (счастливый путь) — основной сценарий использования. Пример:* В поле «Возраст» вводим «25». Ожидание: система приняла данные. Негативное тестирование: Проверка того, как программа реагирует на некорректные* данные или нестандартные действия. Система не должна падать, она должна выдавать понятную ошибку. Пример:* В поле «Возраст» вводим «-5» или «двадцать». Ожидание: сообщение «Введите корректный возраст», приложение не закрылось аварийно.
4. По уровню автоматизации
* Ручное тестирование (Manual): Человек сам проходит сценарии, кликает мышкой и глазами сверяет результат. * Автоматизированное тестирование (Automation): Специальный скрипт (код) выполняет действия за человека и сравнивает результат. Используется для рутинных и повторяющихся задач.
Практический пример: Тестирование формы регистрации
Представим, что нам нужно протестировать простую форму регистрации с полями «Email» и «Пароль». Как применить полученные знания?
| Вид тестирования | Сценарий проверки |
| :--- | :--- |
| Функциональное | Можно ли зарегистрироваться с валидным email и паролем? |
| Нефункциональное (UI) | Видны ли поля ввода? Красная ли кнопка «Войти»? |
| Позитивное | Ввод test@mail.ru и пароля 123456. |
| Негативное | Ввод email без @ (например, testmail.ru). |
| Черный ящик | Проверка через браузер, без просмотра базы данных. |
| Серый ящик | Регистрация пользователя и проверка через SQL-запрос, что запись действительно появилась в таблице users. |
Уровни тестирования (Пирамида)
Тестирование происходит слоями, от мелких деталей к целой системе. Это часто изображают в виде пирамиды.
!Пирамида тестирования: от модульных тестов к приемочным
Более подробно про пирамиду и место тестирования в разработке можно почитать в материалах ru.hexlet.io.