Ответ
New feature (новая функциональность) — это добавленная или существенно изменённая возможность продукта. Тестирование новой фичи должно подтвердить, что она работает корректно, соответствует требованиям и не нарушает существующий функционал.
Подход к тестированию новой функциональности:
- Позитивное тестирование (Happy Path): Проверка основного сценария использования с валидными данными.
- Негативное тестирование: Проверка обработки невалидных данных, ошибок и граничных условий.
- Интеграционное тестирование: Проверка взаимодействия новой фичи с другими модулями системы.
- Регрессионное тестирование: Убедиться, что существующий функционал не сломан.
- Тестирование отката (Rollback): Проверка возможности безопасного возврата к предыдущей версии.
Пример тест-кейса для кнопки "Сохранить":
def test_new_save_feature():
# 1. Заполняем форму валидными данными
fill_form(name="Test User", email="test@example.com")
# 2. Нажимаем новую кнопку "Сохранить"
click_button("Save")
# 3. Проверяем результат
assert is_displayed("Данные успешно сохранены"), "Отсутствует сообщение об успехе"
assert user_in_database("Test User"), "Данные не появились в БД"Ответ 18+ 🔞
Вот, представляешь, приходит наша команда и такая: «Ребят, у нас тут новая фича, овердохуища какая крутая!». А ты сидишь и думаешь: «Ну, блядь, опять...». Потому что новая фича — это не только «ой, как красиво», а ещё и «ёпта, а что мы сломали на этот раз?».
Новая фича (New feature) — это, по сути, свежая плюшка в продукте. Либо её с нуля прикрутили, либо старую так переделали, что мать родная не узнает. И наша святая обязанность — не просто тыкнуть в неё пальцем и сказать «работает», а удостовериться, что она:
- Делает то, что задумано (а не какую-нибудь хуйню).
- Не превращает остальную систему в тыкву.
- Не начинает материться на пользователя, если он введёт какую-нибудь дичь.
Как мы её, эту фичу, будем мучать:
- Счастливый путь (Happy Path): Берём идеального пользователя, который всё делает правильно. Заполняет поля, жмёт кнопки — и всё летит, как по маслу. Если тут не работает — пиши пропало, дальше можно не смотреть.
- Путь страданий (Негативное тестирование): А вот тут начинается самое интересное. Берём пользователя-распиздяя, который будет вводить буквы в поле для цифр, оставлять всё пустым и жать кнопки по десять раз. Фича должна либо вежливо сказать «иди нахуй», либо молча всё починить. Никаких «ошибок сервера 500»!
- Проверка на дружбу (Интеграционное тестирование): Ну окей, сама кнопка работает. А что там у неё под капотом? Она данные в базу пишет? А старая админка эти данные видит? А отчёт на их основе строится? Сейчас как раз выяснится, кто с кем не дружит.
- Регресс — наше всё: Это святое, блядь. Новая фича — это хорошо, но если из-за неё перестанет работать оплата или пользователи начнут видеть чужие фотки — это пиздец, а не успех. Поэтому бежим по основным сценариям старого функционала. «Волнение ебать», пока не убедишься, что всё на месте.
- План «Б» (Тестирование отката): А представь, что после релиза всё-таки вылезла какая-нибудь жесть? Надо уметь откатиться к старой версии так, чтобы никто и не заметил, что мы тут накосячили. Если откат ломает всё ещё сильнее — это уже не фича, а мина замедленного действия.
Вот, смотри, как это выглядит в коде для какой-нибудь новенькой кнопки «Сохранить»:
def test_new_save_feature():
# 1. Заполняем форму валидными данными
fill_form(name="Test User", email="test@example.com")
# 2. Нажимаем новую кнопку "Сохранить"
click_button("Save")
# 3. Проверяем результат
assert is_displayed("Данные успешно сохранены"), "Отсутствует сообщение об успехе"
assert user_in_database("Test User"), "Данные не появились в БД"Всё просто, да? Но это только первый, приветливый тест. Дальше пойдут тесты, где мы эту кнопку будем жать, когда форма пустая, когда интернет отвалился, когда в поле имени цифры... Короче, доведём её до белого каления, чтобы в бою она не сломалась. Вот так и живём.