Един цял
UAT цикъл
Проследи приемането на процес за служебно оборудване: нужда, обхват, правила, данни, сценарии, проблеми, повторна проверка и заключение.
Съдържание на тази страница
Изцяло учебен казус. Организацията, изискванията, версиите, резултатите и решенията са измислени за обяснение. Таблиците не са отчет от действително тестване на Digi.
Каква промяна се приема
Организацията преминава от заявки по имейл към обща система за служебно оборудване. Служителят избира артикул и адрес за доставка, ръководителят преглежда заявката, а складът изпълнява одобреното. При по-висока стойност е нужно и финансово одобрение.
Бизнес нуждата е да има ясно кой какво е поискал, кой го е одобрил и дали оборудването е предадено. Днешното затруднение е, че корекции по имейл се губят и складът понякога използва стар адрес. Затова правилното предаване на променените данни е важен риск за UAT.
Обхват: създаване, чернова, изпращане, преглед, корекция, отказ, одобряване, предаване от склада и документ за предаване. Използва се учебен каталог с един артикул на заявка.
Извън обхвата: счетоводно осчетоводяване, плащане към доставчик и връщане на вече предадено оборудване. Те не трябва да се подразбират като приети от този UAT.
Участници: служител А, неговият ръководител Р, финансов одобряващ Ф и складов служител С. Бизнес собственикът Б има право да приеме описания обхват. Координаторът организира сесиите и отчета.
Какво предварително е договорено
| ID | Правило на казуса |
|---|---|
| EQ-R01 | Стойността на избрания артикул е от 0,01 до 2 000,00 EUR включително, с два десетични знака. Задължителни са артикул, основание и адрес. |
| EQ-R02 | До 500,00 EUR включително одобрява ръководителят. Над 500,00 EUR след него одобрява и финансовата роля. |
| EQ-R03 | Само назначеният одобряващ действа в своята стъпка. Служителят вижда собствените си заявки; складът вижда разрешените за изпълнение. |
| EQ-R04 | Ръководителят връща за корекция с причина. Авторът променя основание и адрес; при повторно изпращане същият ID и актуалните данни се връщат при същия ръководител. |
| EQ-R05 | Отказът съдържа причина и приключва заявката без задача за склада. |
| EQ-R06 | Складът предава само след всички нужни одобрения. „Изпълнена“ се поставя след записано предаване с дата, получател и идентификатор на артикула. |
| EQ-R07 | Документът за предаване използва актуалните данни на заявката и се свързва с нейния ID. |
| EQ-R08 | Запазена чернова може да се отвори и продължи от автора. Само собствена чернова може да бъде отменена; отменената не се изпраща. |
| EQ-R09 | Повторен опит за изпращане на същата заявка не създава дублирана бизнес заявка или задача. |
| EQ-R10 | Историята пази съществените действия с участник и време според процеса. |
Тези правила са достатъчни за казуса, но не са универсална спецификация за такава система. Например реален проект трябва да уточни каталога, заместванията, отсъствията, валидирането на адреси и организационните ограничения.
Условия за приемане на казуса: всички 12 договорени сценария имат успешен актуален резултат или изрично съгласувано приложимо решение; няма нерешен проблем, който променя данните за доставка, пропуска одобрение или допуска неправомерно предаване. Непроверените зависимости остават видими. Това са условия за примера, не общ стандарт за процент успех.
Подготви данните и последователността
Координаторът получава тестова среда с build EQ-42 и процес V1. Каталогът съдържа учебни артикули на 150,00, 500,00, 500,01 и 750,00 EUR. Подготвени са адреси „Тестова 1“ и „Тестова 2“, отделни акаунти за ролите и документи с тестови данни.
За всяка заявка има собствен ID и начално състояние. Не се използва една приключила заявка за всички варианти. Запазването на чернова, отказът и предаването водят до различни състояния и изискват различна подготовка.
Планира се първо маршрутът до 500,00 EUR, после маршрутът с финансова роля, корекцията и останалите проверки. Складът участва в уговореното време, за да може да се потвърди действителното предаване в тестовия процес.
В началото се открива, че акаунтът на финансовия одобряващ липсва. Координаторът записва блокер ENV-07 и отговорник за предоставянето. Това не пречи на всички проверки, но случаите над 500,00 EUR няма да могат да приключат.
Екипът решава да започне независимите сценарии. В отчета ще се вижда, че целият обхват още не е готов за приемане. Администраторски акаунт не замества финансовата роля в тези проверки.
Дванадесет сценария с различна цел
| ID | Задача и основни данни | Крайно очакване |
|---|---|---|
| EQ-01 | 150,00 EUR; валидна заявка. | Одобрение от Р, предаване от С, правилен документ и „Изпълнена“. |
| EQ-02 | 750,00 EUR. | Последователно одобрение от Р и Ф преди склада; правилен край. |
| EQ-03 | Точно 500,00 EUR. | Маршрутът включва Р и не изисква Ф; правилен край. |
| EQ-04 | 500,01 EUR. | Изисква се Ф след Р; няма предаване преди това. |
| EQ-05 | Отказ от Р с причина. | Авторът вижда отказа; няма задача за склада. |
| EQ-06 | 150,00 EUR; корекция на адрес от „Тестова 1“ на „Тестова 2“. | Актуалният адрес стига до Р, С и документа; същият ID и история. |
| EQ-07 | Липсващ адрес и отделен вариант с липсващо основание. | Ясно съобщение; не се изпраща невалидна заявка. Вариантите се записват отделно. |
| EQ-08 | Чужд служител и неназначен одобряващ. | Няма забранени данни или действие според матрицата на ролите. |
| EQ-09 | Повторен опит за изпращане на валидна заявка. | Един бизнес запис и една приложима задача. |
| EQ-10 | Документ след предаване на заявка за 150,00 EUR. | Точни получател, адрес, артикул, дата и ID. |
| EQ-11 | Запазване на чернова, затваряне и повторно отваряне. | Данните са запазени и авторът може да продължи. |
| EQ-12 | Отмяна на собствена чернова. | „Отменена“, история и невъзможност за изпращане. |
Таблицата е обзор. За изпълнение всеки ред получава точни стъпки и очаквания, както в пълния тестов случай. EQ-07 и EQ-08 съдържат варианти; текущият им общ статус може да е успешен само ако всички договорени варианти са успешни.
Входовете около максимума 2 000,00 EUR и други правила също могат да изискват случаи. За казуса е договорен ограниченият набор по-горе. Той не доказва всеки възможен вариант на EQ-R01; тази граница на покритието трябва да е известна на приемащия.
Как е забелязан проблемът в EQ-06
Автор А изпраща заявка за 150,00 EUR с адрес „Тестова 1“. Ръководител Р я връща с причина за корекция. А вижда задачата, променя адреса на „Тестова 2“ и изпраща отново.
При отваряне Р вижда новия адрес. След одобрение складов служител С обаче вижда стария. Тестерът сравнява ID: става дума за същата заявка. Проверява и документа, когато е безопасно и разрешено в учебния тестов процес: той също съдържа стария адрес.
Проблемът не е формулиран като „някъде не се обновява“. Записва се точното място на разминаването: авторът и Р имат новия адрес, складът и документът — стария. Това стеснява условията за възпроизвеждане, без да се твърди техническа причина.
Създава се EQ-BUG-11, свързан с EQ-06 и EQ-R04/EQ-R07. Въздействието е възможна доставка и документ по неактуални данни. Приемането на корекцията не може да се потвърди. Доказателствата показват стойностите при трите роли и идентификатора на общата заявка.
Какво казват резултатите
| Група | Брой | Основание |
|---|---|---|
| Успешни | 9 | EQ-01, 03, 05, 07, 08, 09, 10, 11, 12 — има доказателства за договорените случаи. |
| Неуспешни | 1 | EQ-06 — EQ-BUG-11, стар адрес при склада и в документа след корекция. |
| Блокирани | 2 | EQ-02 и EQ-04 — липсва финансовият акаунт, ENV-07. |
| Общо | 12 | Един текущ статус за всеки договорен сценарий. |
EQ-10 е успешен за некоригирана заявка. Това не противоречи на дефекта: погрешният документ е наблюдаван след корекция в EQ-06. Условията са различни, затова пазим връзката между сценарий, данни и резултат.
Изпълнени докрай са 10 от 12, успешни са 9 от 12. Това не е основание за приемане на целия обхват: има проблем с актуалния адрес и непотвърден маршрут с финансова роля. Отчетът трябва да каже именно това, вместо да показва само „75% успех“.
Предложение към бизнес собственика
„Обхватът не е готов за приемане. Нужно е отстраняване на EQ-BUG-11 и изпълнение на EQ-02/EQ-04 след осигуряване на роля Ф. До тогава правилната доставка след корекция и маршрутът над 500,00 EUR не са потвърдени.“
Определи какво да повториш
Разработчиците предоставят build EQ-43 с поправка за предаването на актуалния адрес. Акаунт Ф е осигурен. Координаторът проверява разполагането, правата и възможността да се подготвят нови заявки.
Екипът оценява въздействието на промяната. За казуса е потвърдено, че се повтарят EQ-06, EQ-01 и EQ-10: конкретният дефект, обичайното предаване и документът. EQ-02 и EQ-04 се изпълняват до край за първи път, вече с правилната финансова роля.
Останалите седем успешни резултата се запазват като приложими само след изричната оценка, че техните правила, конфигурация и зависимости не са засегнати. При по-широка промяна наборът за повторение би бил по-голям. Не е общо правило винаги да се повтарят само три сценария.
Историята пази EQ-42. Старият неуспех на EQ-06 не се изтрива. Новото изпълнение получава собствен RUN ID и връзка към поправката. По този начин се вижда кое е било грешно и как е потвърдено отстраняването.
Сравни новите доказателства
В учебния втори цикъл и петте планирани изпълнения са успешни. При EQ-06 адрес „Тестова 2“ е видим при автора, Р и С и присъства в крайния документ. При EQ-02 и EQ-04 складът получава задача едва след финансовото одобрение.
Текущият регистър съдържа 12 успешни сценария: 7 приложими предходни резултата и 5 резултата от втория цикъл. Не пишем „17 успешни сценария“. Има 12 сценария и история на повече изпълнения, включително първия неуспех и блокираните опити.
EQ-BUG-11 е потвърден като отстранен в EQ-43 по конкретните доказателства. ENV-07 е решен. Координаторът проверява дали няма отворено друго отклонение, неработещ линк към доказателство или липсващ вариант в общите сценарии.
Как изглежда обосновано приемане
Учебен проект на заключение
Обхват: описаният процес за служебно оборудване, build EQ-43, процес V1, договореният тестов каталог и роли.
Доказателства: 12 сценария с актуален успешен статус; регистърът съдържа кои резултати са от EQ-43 и защо седем от EQ-42 остават приложими. EQ-BUG-11 е повторно проверен; ENV-07 е решен.
Ограничения: счетоводство, плащания и връщане на оборудване не са в обхвата. Не е изследвана всяка възможна комбинация от данни. Приложен е точният договорен набор и неговото покритие.
Предложение: приемане на посочения обхват според изпълнените критерии. Официалното решение и датата се записват от упълномощения бизнес собственик Б.
Следваща стъпка: отговорните участници проверяват отделната готовност за внедряване: конфигурация, поддръжка, инструкции и останалите условия по проекта.
Основанието е връзката между правила, изпълнения, доказателства и риск. Броят зелени редове помага за ориентация, но не е заместител на тази връзка.
Как би се променило решението
Помисли какво би станало, ако финансовата роля още липсва; ако поправката променя всички правила за одобрение; ако е проверен само екранът на склада, но не документът; ако бизнес собственикът иска да приеме само маршрута до 500,00 EUR.
Разбор
При липсваща роля пълният обхват остава непотвърден. При променени правила за одобрение е нужна нова оценка и по-широко повторение. Без проверен документ EQ-06 няма доказан целия очакван резултат.
По-тесен обхват може да бъде обсъден, но трябва да има ясно решение, приложими критерии и контрол какво действително ще бъде достъпно. Непровереният маршрут не изчезва от отчета. Самото изтриване на двата блокирани реда не променя продукта или риска.