Приведи примеры смок тестов для Telegram

Что проверяют

Понимаете ли вы, зачем нужен смок, и умеете ли отделять критический путь от остальной функциональности. Список из тридцати проверок здесь неверный ответ: смок отвечает на единственный вопрос, имеет ли смысл вообще тестировать эту сборку.

Как отвечать

Сначала рамка: смок проверяет, что основные сценарии живы, прогоняется на каждой сборке, укладывается в минуты и даёт бинарный результат. Упал смок, сборка уходит обратно разработчику, дальше её никто не тестирует.

Для мессенджера критический путь короткий:

• вход по номеру и коду, повторный запуск без новой авторизации;
• список чатов открылся, история подгружается;
• текстовое сообщение уходит и появляется у получателя, отправитель видит признак доставки;
• входящее приходит при свёрнутом приложении и даёт уведомление;
• вложение отправляется и открывается на втором устройстве;
• групповой чат создаётся, сообщение в нём видят участники.

Каждая проверка обязана быть быстрой, однозначной и не зависеть от данных конкретного аккаунта. Уместно добавить, что смок автоматизируют первым: он повторяется каждый день, а объём у него маленький.

Назовите и соседей: регресс идёт после смока и проверяет то, что раньше работало, санитарная проверка точечно смотрит один починенный участок.

Где спотыкаются

Тащат в смок настройки приватности, оформление, поиск по каналам, двухфакторную аутентификацию. Проверки нужные, но не здесь: набор перестаёт укладываться в окно сборки и теряет смысл быстрого фильтра.

Второе: проверяют только отправку и забывают про доставку. Сообщение, ушедшее в никуда, в интерфейсе отправителя выглядит как успех, поэтому в сценарии обязателен второй участник или второе устройство.

Третье: путают смок с регрессом и санитарной проверкой. Ответ «это одно и то же» закрывает тему сразу: цели у них разные, как и объём с моментом запуска.