Чек-лист тестировщика: что проверить, прежде чем сказать «всё работает»

Что такое чек-лист в тестировании?

Чек-лист — это список того, что нужно проверить.

Например, для формы регистрации:

• корректный email;

• неправильный email;

• пустой пароль;

• слишком короткий пароль;

• повторная регистрация;

• двойное нажатие на кнопку;

• отображение ошибок;

• работа на мобильном устройстве.

Не нужно каждый раз вспоминать:

«Так... пустое поле я проверял? А пробелы? А если два раза нажать?»

Открываешь список — проходишься по нему. Просто. Но спасает релизы удивительно часто.

1. Сначала проверь нормальный сценарий ✅

Это так называемый happy path.

Пользователь делает всё правильно:

1. открывает форму;

2. вводит нормальные данные;

3. нажимает кнопку;

4. получает ожидаемый результат.

Например:

Регистрация → письмо подтверждения → вход в аккаунт.

Это самая базовая проверка.

Но если после неё сказать:

«Ну вроде всё работает»

— где-то в мире начинает грустить один QA Lead.

Потому что настоящие баги часто начинаются именно после happy path.

2. Теперь попробуй сломать всё 😈

Следующий этап — негативные сценарии.

Если поле просит email, не ограничивайся:

test@gmail.com

Попробуй:

test
test@
@gmail.com
пробел
пустое значение
очень длинный адрес
два @@

Если поле принимает возраст от 18 до 100, проверь:

17
18
19
99
100
101
-1

Это и есть важный принцип тестирования:

проверяй не только то, что пользователь должен сделать, но и всё то странное, что он вполне способен сделать.

А способен пользователь практически на всё.

3. Всегда проверяй границы

Баги обожают жить на значениях:

минимум, максимум, минимум − 1, максимум + 1.

Например, пароль должен содержать минимум 8 символов.

Проверяем:

• 7 символов;

• 8 символов;

• 9 символов.

Файл разрешён до 10 МБ:

• 9,9 МБ;

• 10 МБ;

• 10,1 МБ.

Почему это важно?

Потому что разработчик мог написать:

length > 8

вместо:

length >= 8

И всё.

Один символ — один баг.

4. Проверь пустоту

Очень недооценённая категория.

Команды обычно любят тестировать интерфейс, когда в нём всё красиво заполнено.

Есть товары. Есть уведомления. Есть сообщения. Есть проекты.

Но новый пользователь может открыть приложение и увидеть...

ничего.

Поэтому обязательно проверяй:

• пустую корзину;

• пустой список;

• отсутствие результатов поиска;

• новый аккаунт;

• отсутствие уведомлений;

• страницу без данных.

Вместо хорошего empty state пользователь не должен получить загадочный белый экран.

Или ещё лучше:

undefined is not iterable

Очень атмосферно, но не очень удобно.

5. Жми кнопки так, будто тебе пять лет

Особенно важное правило.

Есть кнопка:

«Создать заказ»

Обычный тестировщик нажмёт один раз.

Пользователь:

клик-клик-клик-клик-клик

Проверяй:

• двойное нажатие;

• быстрое многократное нажатие;

• кнопку во время загрузки;

• повторную отправку формы.

Иначе вместо одного заказа можно неожиданно получить пять.

И пять уведомлений.

И пять писем.

И одного очень удивлённого пользователя.

6. Проверь длинные данные

Макеты любят пользователей по имени:

Анна

Реальность любит:

Александр-Константин Владиславович

Поэтому тестируй:

• длинные имена;

• длинные заголовки;

• длинные описания;

• длинные email;

• огромные числа.

Смотри, не:

• ломается ли вёрстка;

• уезжают ли кнопки;

• вылезает ли текст за контейнер;

• превращается ли карточка в небоскрёб.

7. Проверь кнопку «Назад», обновление и прямые ссылки

Приложение идеально работает, пока пользователь движется по сценарию разработчика.

Но потом появляется:

← Назад

И начинается DLC.

Проверь:

• обновление страницы;

• возвращение назад;

• переход вперёд;

• открытие ссылки напрямую;

• новую вкладку;

• повторный вход на страницу после выхода из аккаунта.

Особенно важно для авторизации, оформления заказов, личных кабинетов и многошаговых форм.

8. Проверь мобильную версию 📱

Фраза:

«На моём мониторе всё нормально»

не должна закрывать задачу.

Минимально проверь:

• большой экран;

• небольшой ноутбук;

• смартфон;

• вертикальную ориентацию;

• горизонтальную ориентацию.

Обрати внимание на кнопки, модальные окна, формы, меню и длинные тексты.

Самые весёлые баги часто появляются именно там.

9. Посмотри, что будет при ошибке

Сервер не отвечает.

Интернет пропал.

Запрос идёт 20 секунд.

Что видит пользователь?

Проверь:

• loader;

• сообщение об ошибке;

• возможность повторить действие;

• исчезновение загрузки после ошибки;

• сохранение введённых данных.

Плохой вариант:

вечный спиннер.

Пользователь не знает, работает ли приложение, умерло ли приложение или ему просто дают время подумать над своими решениями.

10. Проверь права доступа 🔐

Если в системе есть роли, обязательно попробуй получить доступ туда, куда нельзя.

Например:

администратор может удалять пользователей;

обычный пользователь — нет.

Проверяй не только отсутствие кнопки.

Попробуй открыть страницу напрямую по URL.

Потому что:

«мы спрятали кнопку» ≠ «мы закрыли доступ».

Как прокачивать тестирование быстрее 🚀

Теорию QA можно читать бесконечно, но тестирование лучше всего запоминается через практику.

В Кодике можно изучать программирование и IT-направления, проходить короткие уроки и сразу закреплять материал упражнениями. Такой формат помогает не просто прочитать термин, а реально разобраться, как всё работает.

А ещё у Кодика есть Telegram-сообщество, где регулярно выходят полезные посты про разработку, тестирование и IT. Это удобный способ возвращаться к темам, которые уже изучал, и постепенно закреплять знания без многочасовых лекций.

Пять минут полезного поста иногда дают больше, чем видео:

«QA с нуля за 11 часов»

которое ты открыл на второй вкладке и больше никогда не видел.