how test software requirements specification
Знаете ли това 'Повечето от Грешки в софтуера се дължат на непълни или неточни функционални изисквания? ' Колкото и добре да е написан, софтуерният код няма значение и нищо не може да се направи, ако има неясноти в изискванията.
Тази статия относно спецификацията на софтуерните изисквания (SRS) гласи, че изискванията трябва да бъдат ясни, конкретни, измерими и пълни, без противоречия.
По-добре е да уловите неяснотите на изискванията и да ги поправите в самия жизнен цикъл на ранното развитие.
Разходите за отстраняване на грешката след завършване на разработката или пускането на продукта са твърде високи. Затова е важно да имате анализ на изискванията и да уловите тези неправилни изисквания преди проектните спецификации и фазите на изпълнение на проекта на SDLC.
Какво ще научите:
Как да се измерват функционални SRS документи?
Е, трябва да определим някои стандартни тестове, за да измерим изискванията. След като всяко изискване бъде преминато през тези тестове, можете да оцените и замразите функционалните изисквания.
Да вземем пример, работите върху уеб-базирано приложение. Изискването е следното: „Уеб приложението трябва да може да обслужва потребителските заявки възможно най-рано“
Как ще замразите Изискването в този случай?
Какви ще бъдат вашите критерии за удовлетворяване на изискванията? За да получите отговор, задайте този въпрос на заинтересованите страни: Колко време за реакция е добре за вас? Ако те кажат, ние ще приемем отговора, ако е в рамките на 2 секунди, тогава това е вашата мярка за изискване. Замразете това изискване и изпълнете същата процедура и за следващото изискване.
Току-що научихме как да измерим изискванията и да замразим тези във фазите на проектиране, внедряване и тестване.
жизнен цикъл на развитие на системата на водопада
Сега да вземем друг пример: Работих по уеб-базиран проект. Клиентът (заинтересованите страни) посочи изискванията на проекта в началната фаза от разработването на проекта. Моят мениджър разпространи всички изисквания в екипа за преглед. Когато започнахме дискусията за тези изисквания, бяхме просто шокирани!
Всеки имаше собствена концепция за изискванията. Открихме много неясноти в „термините“, посочени в документите за изисквания, които по-късно бяха изпратени на клиента за преглед / изясняване.
Клиентът използва много двусмислени термини, които имат много различни значения, което ни затруднява да анализираме точното значение. Следващата версия на документа за изисквания от клиента беше достатъчно ясна, за да замръзне за фазата на проектиране.
От този пример научихме, че „Изискванията трябва да са ясни и последователни“
Следващият критерий за тестване на спецификацията на изискванията е „Открийте липсващите изисквания“, нека я разгледаме.
Открийте липсващите изисквания
Много пъти дизайнерите на проекти не получават ясна представа за всеки конкретен модул и те просто поемат някои изисквания във фазата на проектиране. Всяко изискване не трябва да се основава на предположения. Изискванията трябва да са пълни, да обхващат всеки аспект на системата в процес на разработка.
Спецификациите трябва да посочват и двата типа изисквания, т.е. какво трябва да прави системата и какво не.
Като цяло използвам собствен метод за разкриване на неуточнените изисквания. Когато прочетох Документ за спецификация на софтуерните изисквания (SRS) , Отбелязвам собственото си разбиране за посочените изисквания, плюс други изисквания, които документът SRS трябва да покрива.
Това ми помага да задам въпросите за неуточнените изисквания, като по този начин го направя по-ясен.
За да проверите пълнотата на изискванията, разделете изискванията на три раздела, изисквания „Трябва да се приложат“, изисквания, които не са посочени, но са „приети“, а третият тип е тип „въображение“. Проверете дали всички видове изисквания са адресирани преди фазата на проектиране на софтуера.
Проверете дали изискванията са свързани с целта на проекта
Понякога заинтересованите страни имат свой собствен опит, който очакват да влезе в системата в процес на разработка. Те дори не се замислят дали това изискване би било от значение за съответния проект. Не забравяйте да идентифицирате такива изисквания. Опитайте се да избягвате всички неподходящи изисквания през първата фаза на цикъла на разработване на проекта.
Ако не е възможно, задайте въпросите на заинтересованите страни, като например защо искате да приложите това специфично изискване? Това ще опише подробно конкретното изискване, като по този начин ще улесни проектирането на системата с оглед на бъдещия обхват.
Но как да решим дали изискванията са уместни или не?
Прост отговор: Задайте целта на проекта и задайте този въпрос: Ако неприлагането на това изискване ще доведе до някакъв проблем при постигането на определената ни цел? Ако не, тогава това е без значение изискване. Попитайте заинтересованите страни дали наистина искат да приложат този тип изисквания.
Накратко, документът за спецификация на изискванията (SRS) трябва да включва следното:
- Функционалност на проекта (Какво трябва да се направи и какво не трябва да се прави).
- Софтуер, хардуерни интерфейси и потребителски интерфейс.
- Критерии за коректност на системата, сигурност и ефективност.
- Въпроси при изпълнението (рискове), ако има такива.
Заключение
Покрих почти всички аспекти на измерването на изискванията. За да бъда конкретен по отношение на изискванията, ще обобщя тестването на изискванията в едно изречение:
„Изискванията трябва да са ясни и конкретни, без никаква несигурност, изискванията да бъдат измерими по отношение на конкретни стойности, изискванията трябва да бъдат проверявани, като има някои критерии за оценка за всяко изискване, а изискванията трябва да бъдат пълни, без никакви противоречия“
Тестването трябва да започне във фазата на изискванията, за да се избегнат допълнителни грешки, свързани с изискванията. Общувайте все повече и повече със заинтересованите страни, за да изясните всички изисквания, преди да започнете проектирането и изпълнението на проекта.
Имате ли опит в тестването на софтуерни изисквания?
Моля, не се колебайте да ги споделите в коментарите по-долу.
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Тестване на софтуер QA Assistant Job
- Урок за деструктивно изпитване и безразрушително тестване
- Картографиране на ума при тестване на софтуер - начини да направим тестването по-забавно!
- Как да тествате приложение без изисквания?
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Изборът на софтуерно тестване като кариера
- Тестване на софтуер Техническо съдържание Writer Работа на свободна практика