„Имейлът пристигна“ не е достатъчен резултат от теста.
Съобщение за регистрация може да стигне до пощенската кутия с грешен получател, изтекла връзка, счупен мобилен изглед, продукционен хостнейм или тема, която няма смисъл на друг език. Доброто тестване на имейли следва целия потребителски път и оставя достатъчно доказателства за диагностициране на провал.
Временните пощенски кутии са полезни тук, защото всяко изпълнение може да започне с чист адрес. Кутията трябва да е еднократна; резултатът от теста – не.
Създайте малка, умишлена матрица
- потвърждение на нов акаунт;
- нулиране на парола;
- покана за екип или работно пространство;
- потвърждение за промяна на имейл;
- връзка за вход или еднократен код;
- сигурностно известие след чувствително действие.
За всеки поток тествайте щастливия път, едно изтекло или повторно използвано удостоверение и една грешка от страна на получателя. Това улавя повече реални дефекти, отколкото изпращането на десетки идентични съобщения по щастливия път.
Използвайте един пощенски кутия за всеки сценарий
Повторното използване на един адрес създава двусмислие. Старо съобщение за нулиране може да се бърка с най-новото, а паралелните тестове могат да консумират връзките един на друг.
Генерирайте уникален адрес за всеки тестов случай или изпълнение. Запишете го заедно с номера на билд, средата, локала и сценария. Ако тестът се провали, адресът става част от доказателствата и може да се прегледа, преди да изтече срокът за съхранение.
Не използвайте реални клиентски адреси в staging. Това носи риск от нежелани съобщения, замърсява аналитиката и усложнява автоматичното почистване.
Утвърждавайте обвивката преди съдържанието
Преди да кликнете върху нещо, проверете:
- Съобщението е изпратено до точното адрес, създаден за този тест.
- Домейнът на подателя е очакваният за средата.
- Темата идентифицира действието, без да разкрива чувствителни данни.
- Пристигна само предвиденият брой съобщения.
- Времевият маркер е след действието, което го е задействало.
Тези проверки улавят проблеми с маршрутизацията и дублирането, преди парсерът на съдържанието да ги скрие.
Тествайте съдържанието така, както го вижда потребителят
Отворете съобщението както в тесен, така и в широк изглед. Проверете дали основното действие е видимо, дали текстовата алтернатива е разбираема и дали дълги адреси или URL‑ове не счупват оформлението.
За поток, базиран на код, проверете, че най‑новият код работи веднъж и се проваля след употреба. За поток, базиран на връзка, потвърдете хоста и средата преди да я отворите. Съобщение в staging, което сочи към продукция, е блокиращо за пускане, дори ако технически връзката работи.
Проверете и по‑маловажните детайли: поведението на reply‑to, контакт за поддръжка, формулировка за изтичане, локализация и името на акаунта или работното пространство, показано в съобщението.
Негативни случаи, които заслужават внимание
Полезни негативни тестове включват:
- искане на втори код и потвърждаване, че първият е анулиран;
- отваряне на изтекла връзка;
- отваряне на същата връзка два пъти;
- промяна на състоянието на акаунта преди използване на съобщението;
- покана на адрес, който вече принадлежи на член;
- въвеждане на неподдържан или неправилно форматиран адрес;
- забавяне на доставката достатъчно дълго, за да премине границата на изтичане.
Тези тестове разкриват състезателни условия и подвеждащи съобщения за грешка, които простата проверка на пощенската кутия никога няма да открие.
Разделете продуктова грешка от забавяне в доставката
Когато съобщението липсва, запазете времеви маркери за потребителското действие, поставянето в опашка от приложението, предаването към доставчика и пристигането в кутията, когато тези сигнали са налични. Снимка на празна кутия доказва само, че съобщението не е било видимо в този момент.
Използвайте диагностичната последователност в Имейлът за потвърждение не пристига: Намерете повредената стъпка преди да подадете неясен проблем „имейлът е счупен“.
Какво да автоматизираме
Автоматизирайте стабилните договори:
- генериране на уникален адрес;
- задействане на продуктово действие;
- периодично проверяване с ограничено време за изчакване и увеличаване на интервала;
- съответствие с очаквания подател и тема;
- четене на най‑новото съвпадащо съобщение;
- валидация на кода или връзката спрямо продукта;
- записване на полезни доказателства за провал;
- почистване.
Запазете визуалния преглед, качеството на копието и необичайното поведение на клиента в фокусиран ръчен етап. Автоматизацията е добра за повторение, не за вкус.
Надеждна автоматизация на API за временни кутии обхваща страната на API‑то, включително проверяване и почистване.
Полезен доклад за провал
Доклад, върху който разработчиците могат да действат, съдържа сценарий, среда, адрес, време на задействане, очакван подател, наблюдавани съобщения, време на последното проверяване, статус на отговора и снимка или санитирано откъс от тялото. Никога не прикачвайте живи тайни или многократни проверяващи връзки към публичен проблем.
Целта не е да докажем, че имейлът е ненадежден. Целта е да идентифицираме кой договор е провален и да оставим възпроизводим път към поправката.