Как решавате кои дефекти са допустими за пускане в действие на софтуера?

how do you decide which defects are acceptable

Софтуерът Go-Live винаги е голямо събитие за всеки софтуерен продукт. Важно е абсолютно да сме сигурни, че всичко работи и че сме ние предоставяне на качествен софтуер на потребителите .

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

Често пъти чуваме, че тестването трябва да се извършва, докато не изпълним критериите за изход. Също така чуваме, че дефектите трябва да бъдат отстранени до приемливо ниво.

Макар че това са чудесни звучащи насоки, те са неясни.

За да бъдем по-конкретни:

• Какъв процент дефекти са приемливи за пускане в действие на софтуера?
• Как решавате за отворените дефекти, с които софтуерът може да работи?
• Какво видове дефекти са по-сериозни от останалите?

Препоръчително четене => Кога да спрете тестването?

Имали ли сте тези въпроси някога? След това тази статия ще ви помогне да отговорите на тях. Прочетете нататък ...

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

Колкото повече отстранявате дефекти, толкова по-вероятно е да се инжектира нов дефект, докато се затваря дефектът. Така,

• Как решавате степента на дефектите и вида на дефектите, с които можете да живеете?
• Как базирате софтуера, който ще бъде внедрен за пускане в експлоатация?
• Как координаторите на UAT отправят призив за стартиране или не?
• По какви параметри трябва да бъде оценяван софтуерът?
• Как да отговорим - Годен ли е софтуерът за употреба и ще донесе ли стойност на заинтересованите страни?

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

Моят опит показва, че клиентите искат тяхната стойност за парите и имат критерий за излизане за UAT, с които да живеете.

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

1. Функционални
2. Производителност и натоварване
3. Използваемост
4. Сигурност
5. Интеграция с външни системи
6. Доклади
7. Миграция на данни

Вярвам, че всеки един от тези видове дефекти трябва да бъде обяснен допълнително. И точно това ще направим сега:

как да отворите xml файл в Word

# 1. Функционални дефекти:

Ако софтуерът е създаден съгласно спецификациите, дадени от клиента, той трябва да отговаря на изискванията. Всички отклонения се регистрират като функционални дефекти.

Функционални дефекти след това се класифицират според тежест и приоритет .

Следните са важни съображения:

• Дефектите с висока тежест и приоритет обикновено са тези, които биха повлияли на ежедневната употреба на софтуера. Тези видове дефекти са тези, които трябва да бъдат отстранени, преди да стартираме. Без изключения.
• Понякога функционалните дефекти се класифицират като заявки за промяна, тъй като не са били част от първоначално зададените изисквания. Такива CR, които са задължителни, за да може бизнесът да работи след пускането в действие, също трябва да бъдат приложени.
• Класификацията на дефектите и приоритизирането на функционалните дефекти се извършват от координаторите на UAT в сътрудничество с бизнес потребители и бизнес анализатори. Обикновено клиентът има критерии за изход колко процента от дефектите могат да бъдат отворени за пускане в действие.

# 2. Дефекти на производителността и натоварването:

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

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

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

Например: Ако има партиден процес, който се изпълнява в края на всеки ден и ако времето за реакция на приложението страда, докато това продължава, тогава изпълнението на партидата също е фактор, който трябва да се има предвид.

• Ефективността обикновено се измерва по отношение на времето за реакция на екрани, които да се изобразят и станат достъпни за потребителите, докато в системата има определен брой едновременни потребители.
• Тестовете за ефективност се извършват с помощта на инструменти като LoadRunner , WebLoad , Neoload и др.
• Ефективността на софтуера при дадено натоварване и при бъдещо прогнозирано натоварване обикновено се документира в договора и трябва да бъде демонстрирана преди пускане в експлоатация.
• Екраните или частите на приложението, които се използват по-малко от потребителите, се отлагат за оценки след пускане в експлоатация.
• Производителността също зависи от вида на хардуера и мрежовите условия, на които е разположен софтуерът.
• Тестовете за производителност се извършват по време на UAT в посочения хардуер с помощта на инструменти за изпълнение и техните дефекти се проследяват по начин, подобен на този на функционалните дефекти. Те също така са приоритизирани и е постигнат консенсус относно изпълнението на критериите за изход за пускане на живо.
• Обикновено тестовете за производителност и натоварване в UAT се правят след завършване на функционалния UAT от бизнес потребителите и постигане на приемлив критерий за изход за функционални дефекти.

# 3. Дефекти на използваемост:

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

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

• Указанията за използваемост се създават преди да бъде изграден софтуерът. Софтуерът трябва да се придържа към тези указания.
• При създаването на софтуера може да има и ограничения на инструмента, които трябва да бъдат преодолени разумно, преди софтуерът да бъде използван от крайните потребители.
• С изключително използваем софтуер, краен потребител може да въведе данни до 5 пъти повече от обикновения софтуер.
• Външният вид и усещане на софтуера трябва да бъде свеж, а също така правните въпроси трябва да бъдат подредени преди пускането в експлоатация.
• Много пъти се назначава консултант за използваемост, за да се осигури безпроблемно използване на потребителите.
• Документацията, която трябва да излезе със софтуерното приложение, също трябва да се придържа към строги насоки за използваемост, тъй като те могат да се използват законно.
• Дефектите на използваемостта, регистрирани от тестери / външни тестери на UAT, също се приоритизират като функционални дефекти и дефекти в производителността и трябва да отговарят на критериите за изход за пускане в действие.

# 4. Дефекти в сигурността:

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

Следователно надеждният софтуер не трябва да позволява дори на много компетентен хакер да влезе в приложението без подходящи привилегии.

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

# 5. Интеграция с външни софтуерни системи:

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

Например: При системата за печат те се използват или може да са външни системи като приложение за фактуриране или системи за екран с данни. Разгръщащото се софтуерно приложение трябва безпроблемно да се интегрира с тези външни системи. Всички входове и изходи към тези системи трябва да работят синхронно. Днес технологията обхваща мобилни приложения и различни софтуерни платформи, каквито трябва да бъдат приложенията съвместим с .

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

# 6. Доклади:

Отчетите от софтуерното приложение са критичен начин да се покаже, че данните в приложението се отчитат.

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

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

# 7. Миграция на данни:

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

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

Забележка : Горният списък не е изчерпателен. В зависимост от типа на приложението, може да има повече неща, които трябва да проверите, или не всичко по-горе може да е приложимо. И така, задълбоченото разбиране на софтуера, бизнес целта, потребителските очаквания и архитектурните или хардуерни зависимости е необходимост за разработване на изчерпателни критерии за изход.

Примерен критерий за изход за пускане на живо:

Това е само пример. Тя може да варира от проект до проект.

• 100% от дефектите от Приоритет 1 са затворени (Критичност на сериозността и приоритет 1)
• 90% от дефектите с приоритет 2 са затворени (сериозност висока и приоритет 2) с логично решение за останалите 10% от дефектите. И има план за затваряне на останалите 10% от дефектите.
• Контролният списък за внедряване на производството и здравословен режим е готов.
• Екипът за производствена поддръжка е сформиран и готов за затваряне на билети.
• 70% от дефектите с приоритет 3 са затворени и има план за затваряне на останалите 30% от ниските дефекти.

Няколко забележки:

• Всички дефиниции на сериозност и приоритет се решават по време на бизнес срещите между клиента и доставчика в началото на програмата.
• След като всички дефекти на UAT се регистрират и всички други дефекти бъдат затворени, координаторите на UAT и бизнес спонсорите се срещат, за да направят равносметка на чакащите и открити дефекти. Ако всички дефекти, които се изискват за пускането в действие на Ден 1, са затворени, бизнес спонсорите виждат готовността си за пускане в експлоатация и въвеждат софтуера в производство.

В заключение

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

За автора: Това е статия за гости на Кришнан Венкатраман. Той има близо 18 години опит в тестването на софтуер. Работил е по много големи и сложни проекти за тестване на софтуер.

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

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

• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Тестване на софтуер QA Assistant Job
• Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
• Изборът на софтуерно тестване като кариера
• Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
• Някои интересни въпроси за интервю за тестване на софтуер
• Обратна връзка и рецензии на курсове за тестване на софтуер
• Тестване на софтуер Помощ Партньорска програма!