Приемното тестване с бизнеса

Накратко: Приемното тестване пита друго: не „прави ли системата написаното“, а „мога ли да си свърша работата с нея“. Правят го хората от бизнеса, с истински задачи и правдоподобни данни, а QA подготвя, наблюдава и записва. Находките са дефекти, заявки за промяна или въпроси. Колкото по-късно се чуе „не е това“, толкова по-скъпо е; затова демото и прототипът показват посоката по-рано.

Проблем

Работи, но не е това, което ни трябва

Промо кодовете минаха всички тестове: 10 %, не важат за намалени продукти, една платена поръчка, срок. Сценариите са зелени, тестовете в CI също.

На приемното тестване счетоводителката прави това, което прави всеки месец: сверява отстъпките. Отваря поръчка и вижда „Отстъпка: 2,00 €“. С кой код? Не пише. Няма как да сравни отстъпките с кампаниите. „Всичко работи, но аз не мога да си свърша работата.“ До пускането остават три дни.

Идеята

Потребителското приемно тестване

Всички тестове досега питаха „прави ли системата написаното“. Това е верификация. Потребителското приемно тестване (user acceptance testing, UAT) пита друго: мога ли да си свърша работата с тази система? Това е валидиране.

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

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

Идеята

Как минава едно приемане

Подготовка. Кои хора, кои работни процеси, коя среда, какви данни. И входните условия: системните тестове са минали, няма отворени критични дефекти. Хората от бизнеса имат малко време, и не бива да го харчат за грешки, които по-ниските нива трябваше да хванат.

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

Находки. Те са три вида, и всеки върви по свой път:

• дефект: системата не прави договореното. Докладва се и се поправя;
• заявка за промяна: системата прави договореното, но договореното не стига. Тя минава през управлението на промените: оценка, приоритет, решение;
• въпрос: нещо, което никой не е решил. Записва се, и има кой да отговори.

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

По-точно, за любопитните

ISTQB CTFL v4.0.1 описва приемното тестване като едно от нивата и дава основните му форми: потребителско, експлоатационно, по договор, по регулации, алфа и бета тестване (модулът „Нива, видове и процес“). ISTQB има и отделен сертификат за приемното тестване, Certified Tester Acceptance Testing (CT-AcT). Той е за сътрудничеството между собствениците на продукта, бизнес анализаторите и тестерите: как критериите за приемане и приемните тестове се пишат заедно с бизнеса и как се провежда приемането.

Пробвай

Какво е тази находка?

1. Счетоводителката прилага ЕСЕН10 към тениска за 20,00 € и вижда 17,00 €. Критерият казва 18,00 €.

Не е проблемДефект: системата не прави договоренотоЗаявка за промяна

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

Въпрос към програмистаЗаявка за промяна: системата прави договореното, но договореното не стигаДефект

3. Служителят по маркетинга пита дали код може да се спре преди края на срока.

Нищо, той не е от бизнесаДефектВъпрос: отговорът е или в изискванията, или е ново решение на собственика

4. Средата за приемане е бавна: всяка страница се зарежда 20 секунди. На истинския сайт е под секунда.

Заявка за промянаПроблем на средата: записва се, но не е дефект в продуктаДефект с висока тежест

Провери

Идеята

Защо „не е това“ идва толкова късно

Историята със счетоводителката е класическа. Изискванията бяха верни и пълни за отстъпката. Никой не беше попитал счетоводството какво прави с отстъпките после. Заинтересованата страна, която никой не пита, се появява на приемането.

Причините обикновено са същите:

• изискването е записано като решение („поле за код в количката“), а не като нужда;
• хората, които ще работят със системата, не са били на срещите;
• никой не е гледал работния процес, само е питал за него;
• първата обратна връзка от бизнеса е чак при готовата система.

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

Идеята

Демото и прототипът

Решението е обратната връзка да дойде по-рано, докато промяната е евтина:

• прототип: скица или страница, по която се щрака, без истинска логика. Счетоводителката вижда екрана на поръчката преди първия ред код и казва: „къде ми е кодът?“ Струва час;
• демо: в края на всеки спринт екипът показва работещата част на хората, които ще я ползват. Най-добре не само да гледат, а сами да опитат истинска задача;
• ранен достъп: малка група от бизнеса работи с готовите части, докато другите се правят.

Демото и прототипът не заменят приемането. Те правят така, че на приемането да няма изненади, а само потвърждение. Това е същата идея като shift-left: проверката се мести по-рано, защото там е по-евтина.

По-точно, за любопитните

В Scrum демото се случва в прегледа на спринта (sprint review): екипът показва резултатите на ключовите заинтересовани страни и заедно обсъждат какво да се прави нататък. Scrum Guide нарича прегледа работна среща, която не бива да се свежда до представление.

Пробвай

От най-евтината до най-скъпата обратна връзка

Подреди местата, където бизнесът може да каже „не е това“, от най-евтиното до най-скъпото.

1. Прототип, по който се щрака, без истински код↑↓
2. Приемно тестване с истинска работа преди пускането↑↓
3. Скица на хартия на дъската със сторито↑↓
4. Демо на работеща част в края на спринта↑↓
5. Оплакване на клиент след пускането↑↓

Провери

Упражнение

Приемане на промо кодовете

1. Планът. Промо кодовете са готови за приемане.

1. Кой трябва да прави приемното тестване на промо кодовете?

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

2. Какво е добро входно условие за приемното тестване?

Програмистът казва, че е готовоСистемните тестове са минали и няма отворени критични дефектиИма дата в календара

3. Какви задачи получава счетоводителката?

Истинската ѝ работа: месечната сверка на отстъпките по код, с правдоподобни данни за месецСписъка с тестови случаи на QAСвободно разглеждане без задача

4. Приемането завърши с две заявки за промяна и един дефект с ниска тежест. Какво е разумното решение?

Отхвърлено, докато всичко не е перфектноПрието, и нищо не се записваПрието с условия: дефектът се поправя преди пускането, а промените отиват в следващата версия по приоритет

Провери

Тест

Провери се

1. Какъв въпрос задава приемното тестване?

Колко бърза е системата?Мога ли да си свърша работата с тази система?Прави ли системата точно написаното?

2. Каква е ролята на QA в потребителското приемно тестване?

Подготвя средата, данните и задачите, наблюдава и записва находкитеПрави тестовете вместо потребителитеНяма роля

3. Каква е разликата между дефект и заявка за промяна, намерени при приемането?

Няма разликаЗаявката е по-малко важнаДефектът е отклонение от договореното; заявката за промяна е, когато договореното не стига или е грешно

4. Защо демото в края на всеки спринт е по-евтино от „не е това“ при приемането?

Не е по-евтиноЗащото демото е без тестовеОбратната връзка идва след седмици работа, а не след месеци

Провери

Започни урока отначало

Свързани уроци

• Нужно отпреди: Промяна на изискване · Нивата на тестване · Тестването в жизнения цикъл · План и тестване по риск
• Продължава в: Мерене след пускането · Промо кодове: от заявката до пускането
• Задачи по темата: Валидиране с клиента