Меню

Какво е потребителска история и критерии за приемане (примери)

what is user story acceptance criteria

Опитайте Нашия Инструмент За Премахване На Проблемите

Перфектно ръководство за критерии за приемане на потребителска история със сценарии от реалния живот:

В индустрията за разработка на софтуер думата „Изискване“ определя каква е нашата цел, от какво точно се нуждаят клиентите и какво ще накара нашата компания да увеличи своя бизнес.

Независимо дали става дума за продуктова компания, която произвежда софтуерни продукти, или за сервизна компания, която предлага услуги в различни софтуерни области, основната база за всички тях е изискването и успехът се определя от това колко добре са изпълнени изискванията.

Терминът „изискване“ има различни имена в различните проектни методологии.

В Водопад , се нарича „ Документ за изисквания / спецификация ’, В Agile или SCRUM той е посочен като „Epic“, „User Story“.

История на потребителя и критерии за приемане

При модела Waterfall документите за изискване са огромни документи от 200 или повече страници, тъй като целият продукт е реализиран в една фаза. Но това не е така при Agile / SCRUM, тъй като в тези методологии се дават изисквания за малки функционалности или характеристики, тъй като продуктът се подготвя стъпка по стъпка.

В тази статия се опитах с всички сили да споделя целия си 4-годишен опит в работата с потребителски истории и свързаните с тях критерии за приемане, заедно с лесни и прости сценарии от реалния живот за по-добро разбиране.

Нека първо да посетим отново основите.

Какво ще научите:

Какво е потребителска история?

Потребителската история е изискване за всяка функционалност или функция, която е записана в един или два реда и не повече от 5 реда. Потребителската история обикновено е възможно най-простото изискване и се отнася до една и само една функционалност (или една функция).

Най-често използваният стандартен формат за създаване на User Story е посочен по-долу:

Като

Пример:

Като потребител на WhatsApp искам икона на камера в полето за писане в чата, за да заснемам и изпращам снимки, така че да мога да щраквам и да споделям снимките си едновременно с всичките си приятели.

История на потребителя и критерий за приемане

Какво е критерий за приемане?

Критерий за приемане е набор от приети условия или бизнес правила, на които функционалността или характеристиката трябва да отговарят и да отговарят, за да бъдат приети от Собственика на продукта / Заинтересованите страни.

Това е много важна част от завършването на потребителската история и трябва да бъде проучено много внимателно от собственика на продукта и бизнес анализатора, защото липсата на един критерий може да струва много. Това е прост номериран или маркиран списък.

Форматът му е както следва:

' Като се има предвид някаква предпоставка, когато правя някакво действие, тогава очаквам резултата ”.

кой е най-добрият шпионски софтуер за мобилни телефони

Пример (w.r.t до по-горе потребителска история):

  • Нека помислим, че разговарям с приятел и би трябвало да мога да заснема снимка.
  • Когато щракна върху снимка, трябва да мога да добавя надпис към изображението, преди да я изпратя.
  • Ако има някакъв проблем със стартирането на камерата на телефона ми, съобщение за грешка като „Камерата не може да бъде стартирана“. и т.н., трябва да бъдат показани съответно.

Следователно, Потребителската история дефинира изискването за която и да е функционалност или функция, докато Критериите за приемане определят „Определение на готово“ за потребителската история или изискването.

Като QA е много важно да разберете дълбоко историята на потребителя и критериите за приемането му, без дори едно съмнение да остане в „началото на тестването“. Продължавайки напред, нека разберем защо е изключително важно да се задълбочим в историите на потребителите и критериите за приемане.

Разровете се дълбоко в историите на потребителите

Като начало нека първо разберем важността на едно „задълбочено“ изследване на основно и фундаментално нещо, т.е. Потребителски истории.

Следващите случаи са моите реални преживявания.

Дело № 1:

Преди 3 години работех по проект за мобилни приложения и продуктът беше приложение, предназначено за доставчиците.

Бихте могли да видите доставчик, който идва при вас за доставка. И те имат мобилен телефон, на който те молят да дадете подписа си след доставката. Този подпис се отразява на портала на доставчиците на куриерски услуги като DTDC, FedEx и др.

Нека си представим, че мобилното приложение току-що е стартирано и техните портали вече съществуват и са по-нови.

Проблем: За Sprint собственикът на вашия продукт има потребителска история за това мобилно приложение, което „Като администратор на портала трябва да мога да видя подписа, взет от доставчика по време на доставката“ . Тук порталът (уеб приложението) се променя и актуализира съответно, за да отрази подписа.

Като QA трябва да проверите дали подписът, заснет в мобилното приложение, отразява, както се очаква в портала.

Ако погледнете тази потребителска история, тя изглежда проста, но тук има скрито изискване „За исторически доставки не е имало функционалност за отразяване на подписи, така че какво трябва да се случи, ако момчетата от портала гледат исторически доставки?“ Трябва ли да се изтрият исторически данни? Трябва ли да допускаме сривове или грешки за такива данни?

Разбира се, изобщо не, с това трябва да се работи любезно.

Решение: Когато съответните DB таблици се актуализират, за да се добави нова колона за местоположението на подпис, старите данни трябва да имат стойност NULL или 0, която трябва да се провери и да се покаже съобщение, в което се казва „Няма подпис“.

Това може да се нарече пропуск от собственика на продукта или бизнес анализатора, но това трябва да се направи. Прилагането на една функция успешно, но счупването на нещо заедно с нея не е желателно от клиентите. Това трябва да се направи заедно със същата потребителска история и в същия спринт.

Дело №2

Преди 6 години работех по заявление за финансиране на пенсионно планиране (без BA), което беше глобално приложение, при което хора на финанси като CA, Finance Advisors можеха да го използват за различни валути за проектиране на инвестиционни планове, спестявания и т.н., в продължение на голям период за своите клиенти.

Проблем: Собственикът на продукта ви предоставя потребителска история, която „Като съветник искам да видя отчета на моя клиент въз основа на предоставените финансови подробности“.

Тук имаше 2 скрити изисквания и бих го нарекъл като непълна история, защото:

да се] Отчетите трябва да вземат предвид дневния курс за конвертиране на валута, а не историческия, както в последния прегледан отчет и

б] Ако валутата е променена след предоставяне на финансовите данни на клиента, отчетите трябва да се показват в променената валута.

Решение: Повдигнах тази загриженост директно на нашия собственик на продукта и го осъзнах, че и двете трябва да бъдат направени възможно най-скоро. Той се съгласи с мен и създаде 2 различни истории за предстоящите спринтове с приоритет.

За вкъщи: Те бяха уловени, защото всички ние бяхме много добре запознати с продуктите, техния дизайн, структура и т.н. Такива познания могат да бъдат постигнати само чрез пълно разбиране на продукта, чрез разбиране на оперативната съвместимост на модулите и чрез внимателно изучаване на потребителската история, дори ако това е така 2 подплата.

Правете бележки, за да улесните нещата, и обсъдете с BA's и разработчиците за тяхното мислене.

Поглед в дълбочина на критериите за приемане

Разбирането на критериите за приемане и на всички други условия и правила е изчерпателно дори по-важно от разбирането на потребителска история. Защото, ако дадено изискване е непълно или неясно, то може да бъде използвано в следващия спринт, но ако критерият за приемане е пропуснат, тогава самата история на потребителя не може да бъде пусната.

Предполагам, че в даден момент всички бихме използвали мрежово банкиране и повечето от нас го използват всеки ден и много изтеглям историческите си изявления. Ако го наблюдавате внимателно, има някои специфични опции за изтеглянето им.

Има опция за избор на тип файл за изтегляне на вашето извлечение. Има възможност да изберете дали искате да изтеглите само Кредити / Дебит / и двете.

Сега си представете, че Собственикът на продукта Ви дава тази потребителска история „Като клиент искам да изтегля извлечението си за акаунт, за да мога да видя всичките си транзакции, извършени за определен период“.

Със следните критерии за приемане:

  • Като се има предвид, че съм на страницата за изтегляне на историческа декларация, трябва да избера периода, за който искам да изтегля изявлението.
  • Като се има предвид, че съм на страницата за изтегляне на историческа декларация, трябва да избера акаунта, за който искам да изтегля извлечението.
  • Като се има предвид, че се намирам на страницата за изтегляне на историческа декларация, не трябва да ми бъде позволено да изтегля декларацията за бъдеща дата „До“.
  • Като се има предвид, че се намирам на страницата за изтегляне на историческа декларация, не трябва да ми бъде позволено да избирам дата „От“ след 10 години в миналото.
  • Като се има предвид, че изтеглям изявлението си, трябва да мога да видя изтегления файл.
  • Като се има предвид, че се намирам на страницата за изтегляне на историческа декларация, бих могъл да изтегля изявлението си във формати doc, excel и pdf.

Ако преминете през това приемане, тук липсват 3 неща:

  • Име и формат на името на файла, който ще бъде изтеглен.
  • Каква информация (имена на колони) трябва да се покаже във файла.
  • Списъкът с опции, за да изберете какъв вид транзакция иска клиентът, т.е. само дебити или само кредити или и двете.

Такива случаи могат да се случват от време на време, но все пак проучете добре всеки критерий за приемане и се опитайте да го визуализирате с препратка към историята на потребителя. Колкото повече изучавате задълбочено условията и бизнес правилата, толкова повече ще бъдат вашите познания за функцията.

Откритите в началния етап грешки не струват нищо в сравнение с това, което може да струва на етапа на „тестване“.

Критерии за приемане

Важността на откриването на несъответствия в потребителската история / критериите за приемане

Винаги е важно да се задълбочите в потребителските истории и критериите за приемане на ранен етап, дори преди да започне разработването или тестването.

Защото включва:

# 1) Губене на време:

Ако несъответствията или грешките в историята на потребителя / критериите за приемане са открити, когато тече разработка или тестване, тогава може да се наложи да се извърши много преработка през оставащото време за спринт.

Не се случва дори собственикът на продукта да е пропуснал няколко неща, да премести историята на потребителя в предстоящия спринт. 95% шансове са да помолят екипа да извърши необходимото изпълнение и да го пусне в същия спринт.

Следователно това се превръща в кошмар за екипа, тъй като трябва да прекарват допълнително време, да идват през уикендите или да работят късно вечер. Това може да бъде избегнато чрез изучаване и обсъждане на историята на потребителя / критериите за приемане на възможно най-ранния етап.

# 2) Пропиляване на усилията:

Разработчиците и QA трябва да преразгледат внедрения код и да тестват случаи отново. Актуализирането, добавянето и премахването според изискванията не е лесна задача. Става твърде болезнено, тъй като вече има натиск да се изпълни навреме.

В такава ситуация има шанс за грешки на етапа на разработване или тестване. Ако срещнете подобна ситуация, изберете „DevQA Pairing“. Като черешка на тортата може да не получите компенсация за допълнителната работа.

Несъответствия между потребителската история и критериите за приемане

Заключение

Дълбокото разбиране на потребителската история и критериите за приемане може да бъде постигнато само чрез прекарване на огромно време за нейното изучаване.

На пазара няма наличен конкретен инструмент или курс, който да направи това вместо вас, тъй като всичко е свързано с логическо мислене, опит и познания за продукта.

Активното участие в предварително планирана среща, разговор с бакалавра, самостоятелно обучение могат само да ви помогнат да постигнете това. Колкото повече усилия полагате, толкова повече научавате и растете.

Независимо дали става въпрос за QA или разработчици, всички трябва да бъдат на една и съща страница за потребителските истории и техните критерии за приемане, само тогава очакванията на клиента могат да бъдат постигнати успешно.

Имате ли нещо ново, което да споделите с нас относно вашия опит в работата с потребителски истории? Моля, изразете мислите си по-долу !!

Препоръчително четене

^