Какво наблюдаваш
в браузъра
Как са свързани екранът, запазените данни и крайният резултат. Практически задачи за браузър, списъци, документи, регистър и доказателства.
Съдържание на тази страница
Едно действие има няколко видими резултата
Браузърът показва интерфейса на приложението. При много действия той изпраща заявка към сървър, който обработва данните и връща отговор. Интерфейсът използва отговора, за да покаже новото състояние. Част от действията може да се изпълняват само локално; например упражнението в този пакет няма сървър.
Техническа справка за този общ модел: MDN — How the web works.
За UAT практическото следствие е: въведената стойност, показаното потвърждение и запазеният запис могат да се разминават. Затова след промяна на адреса не спирай при зелено съобщение. Отвори отново заявката и виж какво е запазено. Ако следващата роля използва адреса, провери и нейния изглед.
Разграничавай „действието е прието за обработка“ от „обработката е завършена“. Например генерирането на документ може да е отделна задача. Появата на заявка за генериране още не потвърждава правилен, достъпен файл. Запиши крайната проверка, която бизнесът действително изисква.
Практическа задача
В предоставената тестова система избери разрешен запис. Запиши старата стойност на поле, промени го, запази, отвори отново записа и сравни. Ако процесът включва друга роля, провери същия идентификатор и при нея. Резултатът е кратка последователност „въведено → запазено → видимо за следващия участник“.
Не смесвай акаунти и контекст
Входът установява коя е потребителката; правата определят какво може да вижда и прави. Възможно е един акаунт да има различен обхват според активната организация или роля. Проверявай и тях, когато приложението предлага такъв избор.
Браузърният профил съхранява данни, които могат да поддържат входа. Два раздела в същия профил обикновено не са две независими роли. Ако в единия смениш акаунта, другият може да продължи с променена сесия, въпреки че екранът още показва старото име.
Подготви отделни профили или друг договорен начин за разделяне на участниците. Означи ги ясно, например „UAT автор“ и „UAT преглеждащ“. Не поставяй паролите в имената, бележките или снимките. Преди всяко ролево действие провери кой е активен.
При изтичане на сесията наблюдавай как се възстановява работата: появява ли се разбираемо съобщение, нужен ли е нов вход, какво става с въведеното. Очакванията за запазване на незаписани данни трябва да са договорени. Автоматичното изчезване на формата може да бъде важно, дори след повторен вход всичко друго да работи.
Следи стойностите през целия им път
При форма гледай не само дали полетата приемат текст. Провери кои са задължителни, кои имат стойност по подразбиране и кои зависят от предишен избор. Ако смяната на продукт променя допустимите срокове, старата стойност може вече да не е валидна.
За падащ списък сравни избрания етикет с крайния запис. За дата сравни ден, месец, година и приложимата часова зона. За идентификатор пази водещите нули, ако са значими. При дълъг текст сравни дали е съхранен изцяло, а не само първата видима линия.
Съобщението за грешка трябва да помага за действие: кое поле е проблемно и какво е нужно. Провери и дали вече въведените валидни данни остават според договореното поведение. Връщането на потребителя към празна форма може да създава ненужна работа.
Последователност за една зависимост
Избери продукт А и допустим за него срок. Смени на продукт Б. Уточни предварително дали срокът трябва да се изчисти, да се преизчисли или да се поиска нов избор. Провери съобщението, изпращането и записания резултат. Това е един свързан бизнес случай, а не произволно сменяне на полета.
Търсене, филтър и износ също имат бизнес смисъл
Служителят може да не намери важна заявка заради неправилен филтър, а не защото тя липсва. Подготви малък известен набор: например две „В преглед“, една „За корекция“ и една приключила. Запиши техните ID и очакваните групи.
- Провери началния списък и активните филтри.
- Избери едно състояние и сравни точните записи, които трябва да останат.
- Добави втори филтър, например автор или период, и провери договорената комбинация.
- Премахни филтрите и потвърди възстановения набор.
- Ако има страници, провери прехода между тях и дали филтърът се запазва.
- Ако има износ, сравни обхвата, колоните и стойностите в получения файл.
Изясни дали износът включва текущата страница, всички филтрирани записи или друг обхват. Няма универсален правилен отговор. Същото важи за общата бройка: тя може да е за целия набор или само за показаното. Критерият трябва да е ясен.
При липсващ запис първо потвърди правата, филтъра, периода и състоянието. При сортиране уточни формата: текстов идентификатор и числова стойност могат да се подреждат различно. В отчет записвай точния критерий, по който сравняваш.
Провери полученото, а не само иконата
За прикачен файл сравни име, тип, размер според правилата и възможност да бъде отворен от разрешената роля. При невалиден файл провери съобщението и липсата на недопустимо продължаване. Не използвай произволно големи файлове; подготви размерите, нужни за договорената граница.
За генериран документ свържи файла със заявката и версията. Отвори го и сравни получател, стойности, дати, основание и задължителни текстове по одобрения образец. Правилното име на файла не доказва правилно съдържание.
За известие уточни получател, канал, момент и съдържание. Събитие „известие подготвено“ не е непременно доказателство за получаване. Ако UAT изисква доставен тестов имейл, трябва да има достъпна тестова поща или доказателство от отговорния участник. Ако това е извън обхвата, запиши границата.
При повторно действие провери дали известието или документът се създава повторно според правилото. Дубликатите могат да объркат потребителя, дори основната заявка да е само една.
Подготви общ работен файл
Ако екипът използва Excel или Google Sheets, започни с малка ясна структура. Не са нужни сложни формули, за да има проследимост. Важни са общите имена на статусите, уникалните идентификатори и работещите връзки.
- Създай лист „Сценарии“ с колони: ID, бизнес цел, изискване, риск/приоритет, роли, данни, стъпки, очакване и текущ статус.
- Създай лист „Изпълнения“: RUN ID, сценарий, версия, дата, изпълнител, действително, статус, доказателство и дефект.
- Създай лист „Въпроси“: ID, правило, конкретен въпрос, отговорник, отговор, дата и засегнати сценарии.
- Договори позволените текстови статуси и използвай ги последователно. Цветът е допълнение.
- Добави филтри и фиксирай заглавния ред според възможностите на инструмента.
- Провери достъпа и мястото на файла с координатора, за да не се появят няколко несъгласувани копия.
При сортиране използвай целия диапазон на таблицата, за да останат данните в един ред свързани. В съвместен файл внимавай дали филтърът променя изгледа и за другите. Използвай личен изглед, ако инструментът и правилата на екипа го позволяват.
Справка за конкретни действия в Google Sheets: Sort and filter your data.
При повторна проверка добави нов ред в „Изпълнения“. След успешен резултат обнови текущия статус на сценария, но запази предишния неуспех. Така е ясно как е достигнато заключението.
Събери мрежов детайл за екипа
Когато екипът поиска данни за конкретно действие, Chrome DevTools → Network показва мрежовите заявки. Отвори панела преди повторението. Изчисти списъка, изпълни едно действие и намери свързаната заявка с помощта на екипа. В детайлите има заглавки, изпратени данни и отговор.
Запиши часа, метода, адреса без чувствителни параметри, статуса и несекретен идентификатор за проследяване, ако е наличен. Не изпращай токени и пароли. HTTP 200 не доказва правилни бизнес данни. При липсващ отговор не прави самостоятелно заключение коя услуга е виновна.
Панелът и неговите полета са описани в Chrome — Inspect network activity.
Не е нужно този детайл да присъства във всеки UAT дефект. Точното бизнес описание, версията, ID и стъпките често са достатъчни, за да започне работата. Техническата информация се добавя, когато има конкретна диагностична стойност.
Разграничавай изглед от реално устройство
Стесненият прозорец показва как интерфейсът реагира на малка ширина. Device Mode в Chrome може да симулира допълнителни условия, но не възпроизвежда напълно физически телефон и неговия браузър. Ако приемането включва конкретно мобилно устройство, нужен е договорен тест с него.
Ограничения и възможности: Chrome — Device Mode.
Във всеки резултат напиши реалните условия: „настолен Chrome, прозорец 390 пиксела“, ако това е изпълнено. Не го описвай като тест на iPhone само защото изгледът е тесен. Същото важи за скоростта: симулирана бавна мрежа е конкретно тестово условие, не измерване на всички реални потребители.