Съдържание
- Демо и умрете!
- Стъпка в обувките на потребителите
- Кратка история на UAT
- UAT ви казва колко използваема е системата
- Кой може да изпълнява UAT?
- Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви
- Успехът и провалът текат
- Ползи от UAT
Източник: Lightcome / iStockphoto
За вкъщи:
След като софтуерът преминава през тестване на модули, интеграция и система, необходимостта от тестване за приемане може да изглежда излишна. Защо тестът за приемане от потребители (UAT) все още е важен? Тук добре научете предимствата на UAT и защо е уникален.
Демо и умрете!
Предавали ли сте някога презентация или обучение на клиента и нещо прекъсва по средата? Или някога сте дали на някого набор от инструкции и сте разбрали, че сте пропуснали нещо, или това не се получи, както се надявахте? По време на всеки от тези случаи приемате перспективата на крайния потребител и работите със софтуера в тази персона. Вероятно е, че сте направили нещо по-различно, защото сте мислили като потребител, а не като програмист.
Стъпка в обувките на потребителите
Уникалният ъгъл на тестване за приемане от потребители (UAT) е да се тества софтуер като краен потребител. Софтуерът е създаден, за да даде на потребителите осезаеми резултати. Например сайтовете за електронна търговия позволяват на клиентите да купуват продукти. Когато клиент направи поръчка, софтуерът за сайтове за електронна търговия уведомява администратора на магазина, така че избраният артикул да може да бъде изтеглен и опакован за доставка. Възможно е да има различни видове потребители на софтуер, така че този етап на тестване позволява на екипа за разработка да провери дали крайните потребители постигат очакваните софтуерни резултати.
Кратка история на UAT
Преди появата на интернет, повечето софтуер е разгърнат за известна потребителска аудитория. Ако компания разработи софтуер за клиент, назначен ръководител имаше правомощия да проверява дали софтуерът изпълнява условията на договора. Това е имало за цел да представлява точка, в която софтуерът е "подходящ за целта", което е постигнато чрез избиране на представители на крайните потребители, които да извършват тестване и да предоставят отчет с резултати. Тъй като потребителите бяха известна, затворена група, всеки може да бъде обучен в използването на софтуера, обикновено чрез много подробни стъпки за тестване. Мотото на деня беше, че повече подробности бяха по-добри.
Тъй като все повече софтуер беше разработен за клиенти в мрежата, аудиторията на крайните потребители стана по-отворена. Вече не беше възможно да се идентифицират и обучат всички вероятни крайни потребители, така че софтуерният дизайн трябваше да включва много по-голям акцент върху използваемостта и трябваше да бъде лесно разбираем - дори и с минимално предоставена информация. Така че UAT трябваше да се промени, за да отговори на тези изисквания.
UAT ви казва колко използваема е системата
Така че не само UAT ни казва степента на функционалност за даден софтуер, но и ни казва колко използваем е той. Повечето UAT се изпълняват най-добре от хора, които разбират целевия краен потребител, който ще изпита софтуера с малко предварителни познания и може да даде истинска индикация за лесното използване на софтуера и това, което се нуждае от подобрение.
Кой може да изпълнява UAT?
Като разработчици тестват софтуер, те запомнят подробности за това как е написана система. Тези знания могат да повлияят на тестването и разработчиците могат да предприемат различни стъпки от крайните потребители, като например извършване на стъпки по-бързо или отхвърляне на фини детайли, които крайните потребители могат да намерят объркващи. Така разработчиците не са най-добрите кандидати за UAT. И така, кой е?
Много организации използват специфични екипи за тестване, които не участват в техническия дизайн и разработка. По-малките организации или разпределят тестване на служители, които не са разработващи, като тези, които изпълняват административни задължения, или използват услугите на външна компания. Някои организации използват това, което е известно като "тестване в коридора", където буквално ръчно подбират служители, които не са активно заети по проекта, и ги молят да изпробват системата от гледна точка на крайните потребители. Пример е поръчката на продукт онлайн.
След вътрешно тестване могат да настъпят пилотни или бета-тестови етапи, при които софтуерът се предоставя на малки групи от „истински“ потребители, които са поканени да използват продукта безплатно или със значителна отстъпка, в замяна на подробна обратна връзка при използването.
Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви
Не можете да подобрите уменията си за програмиране, когато никой не се интересува от качеството на софтуера.
Прогресивните UAT етапи с разнообразна аудитория увеличават увереността в използваемостта на софтуера. В комбинация с фази на итеративно развитие могат да се извършват множество UAT цикли, за да се тестват нови функции, докато се доставят, като същевременно се проверяват предишните функционалности.
Добрите тестери за UAT са любопитни да видят какво ще се случи, ако поемат различни маршрути към определена цел. В крайна сметка всеки подхожда към използването на софтуер по различни начини, така че ако много възможности могат да бъдат обхванати от малка група хора, доверието на софтуера в работен режим е по-високо.
Успехът и провалът текат
UAT процесите трябва да потвърдят, че всеки тип потребител на софтуер постига осезаемите резултати, необходими както за потока на успеха, така и за отказа.
В успешен поток крайният потребител се отдалечава с очакван резултат, като например поръчка на продукт. При поток от грешки, софтуерът поддържа крайния потребител чрез някаква форма на сценарий за грешки, например когато клиент предоставя невалидна информация за плащане с кредитна карта.
За да се провери функционалността, трябва да се предостави известна информация на тестерите. В противен случай те не знаят какво трябва да прави софтуерът. Но за да се тества използваемостта, това трябва да е минимално - само на базата на задачи или изисквания, като например закупуване на "x" (продукт) и плащане на "y" (използвайки данни за кредитна карта). Товарът трябва да бъде поставен на тестери, за да записва наблюдения, успехи и неуспехи.
Ползи от UAT
Основно предимство на добрия UAT е, че поддържа текущите разходи за поддръжка възможно най-ниски. По-евтино е да се коригират проблемите с функционалността и използваемостта рано. Много по-трудно е да се поправи грешка, когато има повече код около нея, за да се направи регресионен тест или ако оригиналният разработчик не е наличен.
UAT, който се изпълнява на няколко етапа и с различни видове тестови аудитории, осигурява оптимални възможности за идентифициране и поправяне на нарушени функции / проблеми с използваемостта в ранните фази на тестване. Поддържането на целите на UAT на ниво задачи и изисквания позволява на тестерите да наблюдават и забелязват много повече и дори да опитват стъпки извън предвидения от разработчиците обхват.
Обратната връзка от UAT цикли може да бъде включена в последващи итерации на разработка, повишаваща здравината на софтуера и използваемостта. Времето е добре, дори бета тестовите фази могат да допълнят маркетинговите и продажбените дейности, като предоставят справки и обратна връзка от казуси.