how review srs document
Това е вторият урок в нашия ‘Безплатно обучение за онлайн тестване на софтуер по проект на живо’ серия. Ако сте нов тук, моля, проверете първия урок за въвеждане: Обучение за тестване на софтуер от край до край по проект на живо.
Нека сега да влезем в подробен анализ на това как се случва разходка SRS, какво е това, което трябва да идентифицираме от тази стъпка, какви предварителни стъпки трябва да предприемем, преди да започнем, какви са предизвикателствата, пред които бихме могли да се изправим и т.н. подробен начин.
Фаза на проектиране на SDLC:
Следващата фаза на SDLC е „Дизайн“ - тук функционалните изисквания се трансформират в техническите подробности. В тази стъпка участват екипите за разработчици, дизайн, среда и данни. Резултатът от тази стъпка обикновено е документ за технически проект - TDD.
Входът е SRS документ както за създаването на TDD, така и за екипа за QA да започне работа по QA аспекта на проекта - който е да прегледа SRS и да идентифицира целта на теста.
Какво ще научите:
- Какво е SRS преглед?
- Предварителни стъпки към преглед на спецификацията на софтуерните изисквания
- Изисква ли се шаблон за тестови сценарии?
- Някои важни забележки относно прегледа на SRS
- Препоръчително четене
Какво е SRS преглед?
SRS е документ, който е създаден от екипа за разработка в сътрудничество с бизнес анализатори и екипи за околна среда / данни. Обикновено този документ, след като бъде финализиран, ще бъде споделен с екипа за осигуряване на качеството чрез среща, на която е уредена подробна инструкция.
Понякога за вече съществуващо приложение може да не се нуждаем от официална среща и някой да ни води през този документ. Може да разполагаме с необходимата информация, за да направим това сами.
Прегледът на SRS не е нищо друго освен преминаване през документа за спецификация на функционалните изисквания и опитване да се разбере какво ще бъде целевото приложение.
Официалният формат и извадка бяха споделени с всички вас в предишната статия. Това не означава непременно, че всички SRS ще бъдат документирани точно по този начин. Винаги, формата е вторична за съдържанието .
Някои екипи просто ще изберат да напишат списък с водещи символи, някои екипи ще включват случаи на използване, някои екипи ще включват примерни екранни снимки (като документа, който имахме), а други просто описват подробностите в параграфи.
Предварителни стъпки към преглед на спецификацията на софтуерните изисквания
Етап 1) Документите преминават през множество ревизии, така че се уверете, че разполагаме с правилната версия на референтния документ, SRS.
Стъпка 2) Установете насоки за това какво се очаква в края на прегледа от всеки член на екипа. С други думи, решете какви резултати се очакват от тази стъпка - обикновено резултатът от тази стъпка е да се идентифицират тестовите сценарии. Тестовите сценарии не са нищо друго, освен еднолинейни указатели на „какво да тествате“ за определена функционалност.
Стъпка # 3) Също така установете насоки за това как трябва да бъде представен този резултат - имам предвид шаблона.
Стъпка # 4) Решете дали всеки член на екипа ще работи върху целия документ или ще го раздели помежду си. Силно се препоръчва всеки да чете всичко, защото това ще попречи на концентрацията на знания при определени членове на екипа.
Но в случай на огромен проект, при който документите SRS работят на близо 1000 страници, подходът на разбиване на модула на документите и назначаване на отделни членове на екипа е най-практичен.
Стъпка # 5) Прегледът на SRS също помага за по-доброто разбиране дали има някакви специфични предпоставки, необходими за тестването на софтуера.
Стъпка # 6) Като страничен продукт се идентифицират списък със заявки, при които някои функции са трудни за разбиране или ако е необходимо да се включи повече информация във функционалните изисквания или ако се допуснат грешки в SRS.
sql срещу nosql плюсове и минуси
Какво ни трябва, за да започнем?
- Правилната версия на SRS документа
- Ясни инструкции кой какво ще работи и колко време имат.
- Шаблон за създаване на тестови сценарии.
- Друга информация - с кого да се свържете в случай на въпрос или с кого да докладвате в случай на несъответствие в документацията
Кой би предоставил тази информация?
Водещите на екипа обикновено отговарят за предоставянето на всички елементи, изброени в горния раздел. Приносът на членовете на екипа обаче винаги е важен за успеха на цялото това начинание.
Водещите от екипа често питат - Какъв вид входни данни? Не би ли било по-добре да зададете определен модул на някой, който се интересува от него, отколкото на член на екипа, който не е? Не би ли било хубаво да се вземе решение за целевата дата въз основа на мнението на екипа, отколкото да се наложи решение върху тях? Също така, за успеха на даден проект, шаблоните са важни.
Като общо правило, шаблоните имат по-висока степен на ефективност, когато са съобразени с удобството и комфорта на конкретния екип. Следователно трябва да се отбележи, че ръководителите на екипа са повече от всичко членове на екипа. Включването на екипа ви в ежедневните решения е от решаващо значение за гладкото протичане на проекта.
Изисква ли се шаблон за тестови сценарии?
Защо шаблон за тестови сценарии - не е ли достатъчно, ако просто направим списък?
Със сигурност е. Софтуерните проекти обаче не са „моноспектакли“. Те включват съвместна дейност .
Представете си екип от 4, ако всеки от тях реши да прегледа по един модул от спецификацията на софтуерните изисквания. Член на екипа А е направил списък на лист хартия. Член на екипа 2 използва лист на Excel. Член на екипа 3 използва бележник. Член на екипа 4 използва дума doc. Как да консолидираме цялата работа по проекта в края на деня?
безплатен софтуер за извличане на DVD за Windows
Също така, как можем да решим кой е стандартът и как можем да кажем кое е правилно и кое не, ако не сме създали правилата, за начало?
Ето какво представлява шаблонът: Набор от насоки и съгласуван формат за еднаквост и съгласуваност за целия екип.
Как да създам шаблон за тестови сценарии за QA?
Шаблони не трябва да са сложни или негъвкави.
Всичко, което трябва да бъдат, е ефективен механизъм за създаване на полезен артефакт за тестване. Нещо просто като това, което виждаме по-долу:
Заглавката на този шаблон съдържа пространството, необходимо за заснемане на основна информация за проекта, текущия документ и референтния документ.
Таблицата по-долу ще ни позволи да създадем тестови сценарии. Включените колони са:
Колона # 1) Идент. № на сценария за тестване
Всеки обект в нашия процес на тестване трябва да бъде уникално разпознаваем. Така че, на всеки тестов сценарий трябва да бъде присвоен идентификатор. Трябва да се дефинират правилата, които да се спазват при присвояване на този идентификатор.
Заради тази статия ще следваме конвенцията за именуване като TS (префикс, който означава „Тест сценарий“), последван от „_“, име на модула МЕН (Моят информационен модул на проекта Orange HRM), последван от „_“ и след това подраздел ( Например, МЕН за Моят информационен модул, P за снимка и т.н.), последвано от сериен номер. Пример за това би бил: „TS_MI_MIM_01“.
Колона # 2) Изискване
Помага ни, че когато създаваме тестов сценарий, трябва да можем да го прикачим обратно към раздела на SRS документа, откъдето сме го избрали. Ако изискванията имат идентификатори, бихме могли да ги използваме. Ако не номера на раздели или дори номера на страници на SRS документа, откъдето идентифицирахме, може да се провери изискване.
Колона # 3) Описание на сценария на теста
Еднолинеен, указващ „какво да тествате“. Бихме го посочили и като цел на теста.
Колона # 4) Значение
Това е да се даде представа за това колко важна е определена функционалност за AUT. Стойности като висока, средна и ниска могат да бъдат присвоени на това поле. Можете също така да изберете точкова система, като 1-5, 5 е най-важна, 1 е по-малко важна. Каквато и стойност да има това поле, то трябва да бъде предварително решено.
Колона № 5) Брой на тестовите случаи
Груба оценка за това колко отделни тестови случая бихме могли в крайна сметка да напишем този тестов сценарий. Например, За да тестваме влизането - ние включваме следните ситуации: Правилно потребителско име и парола. Правилно потребителско име и грешна парола. Правилна парола и грешно потребителско име. Така валидирането на функционалността за вход ще доведе до 3 тестови случая.
Забележка: Можете да разширите този шаблон или да премахнете полетата, както сметнете за добре.
Например , можете да добавите „Прегледано от“ в заглавката или да премахнете датата на създаване и т.н. Също така в таблицата можете да включите поле „Създадено от“, за да посочите тестера, отговорен за определен тестов сценарий, или да премахнете „Не. на тестови случаи “. Изборът е твой. Вървете с това, което работи най-добре за целия екип.
Нека сега прегледаме нашия Orange HRM SRS документ и да създадем тестови сценарии
Професионален съвет: разгледайте съдържанието в извадката на SRS, която предоставихме в 1-ва урока, за да получите добра представа за това как ще протича всеки документ и колко работа може да включва.Секция 1 е целта на документа. Няма проверими изисквания там.
Раздел 2.1 : Преглед на проекта - Аудитория - там също няма проверими изисквания.
Раздел 2.2 : Хардуер и хостинг - Този раздел говори за това как ще бъде хостван сайтът Orange HRM. Сега, важна ли е тази информация за нас, изпитателите? Отговорът е Да и Не. Да, защото когато тестваме, трябва да имаме среда, подобна на средата в реално време.
Това ни дава представа как трябва да бъде. Не, защото това не е проверимо изискване - нещо като предпоставка за провеждане на теста.
Раздел 3: Тук има екран за вход и подробности за типа акаунт, който трябва да имаме, за да влезем в сайта. Това е проверимо изискване. Така че трябва да е част от нашите тестови сценарии.
Моля, вижте документа за тестовите сценарии, където са добавени тестови сценарии за няколко раздела на SRS. За практика, моля, добавете останалите сценарии по подобен начин. Преминавам обаче към раздел 4 от документа.
Раздел 4: Естетични / HTML изисквания и насоки - Този раздел най-добре обяснява как някои изисквания може да нямат смисъл за тестовия екип по време на прегледа на SRS, но екипът трябва да ги отбележи като проверими изисквания.
Как да ги тестваме и ако се нуждаем от конкретна настройка / помощ на някой екип, за да го потвърдим, са подробности, които може да не знаем в този момент. Но превръщането им в част от нашия обхват на тестване е първата стъпка, за да гарантираме, че няма да ги пропуснем.
Примерни тестови сценарии за приложението OrangeHRM: (щракнете, за да увеличите изображението)
=> Моля, направете справка и изтеглете документа Сценарии на теста за повече информация.
Някои важни забележки относно прегледа на SRS
# 1) Не трябва да се оставя информация непокрита.
# две) Извършете анализ на осъществимостта дали дадено изискване е правилно или не, както и дали може да бъде тествано или не.
# 3) Освен ако няма отделно изпълнение / сигурност или друга форма на тестови екипи - нашата работа е да се уверим, че всички нефункционални изисквания трябва да бъдат взети под внимание.
# 4) Не цялата информация е насочена към тестерите, така че е важно да се разбере какво да се отбележи и какво не.
# 5) Важността и не. от тестови случаи за тестов сценарий не трябва да са точни и могат да бъдат попълнени с приблизителна стойност или могат да бъдат оставени празни.
произволно число между 1 и 10 c ++
За да обобщим, SRS преглежда резултатите в:
- Списък на тестовите сценарии
- Преглед на резултатите - Грешки в документацията / изискванията, открити чрез статично преминаване / проверка на SRS документа
- Списък с въпроси за по-добро разбиране - в случай на такива
- Предварителната идея за това как трябва да бъде тестовата среда
- Идентифициране на обхвата на теста и груба представа за това колко тестови случая може да имаме, така че колко време ни е необходимо за документация и евентуално изпълнение.
Важни забележки:
# 1) Тестовите сценарии не са външни продукти (не се споделят с бизнес анализатори или екипи за разработчици), но са важни за вътрешното потребление на QA. Те са първата ни стъпка към целта за 100% покритие на теста. След завършване на тестовите сценарии се извършва партньорска проверка и след като се направи, всички те се консолидират.
За повече подробности как се преглеждат документите за осигуряване на качеството, вижте статията: Как да извършите прегледи на тестовата документация в 6 прости стъпки.
# две) Можем да използваме инструмент за управление на тестове като HP ALM или qТест за създаване на тестови сценарии. Създаването на тестови сценарии обаче в реално време е ръчна дейност. Според мен е по-удобно ръчно. Тъй като е стъпка 1, все още не е нужно да изваждаме големите оръжия. Обикновените листове на Excel са най-добрият начин да го направите.
Следващата стъпка към тази поредица е тази - ще работим върху създаването на тестови казуси и ще влезем по-нататък във фазата на проектиране на теста. Преди това също ще влезем в - Какво е планиране на теста?Къде се вписва в целия QA проект? Както винаги, работете с нас за най-добри резултати.
QA Training Day 3: Как да напиша SRS документ от нулата.
Моля, поддържайте вашите въпроси и коментари. Оценяваме вашата читателска аудитория!
Препоръчително четене
- Учебна програма за тестване на софтуер - Подробен план за обучение на онлайн курс
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Обучение за тестване на софтуер: Обучение от край до край по проект на живо - Безплатно онлайн обучение за QA, част 1
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Обратна връзка и рецензии на курсове за тестване на софтуер
- Често задавани въпроси за курса за обучение на софтуер за тестване на софтуера
- QA Софтуер за тестване на ресурси и файлове за изтегляне
- Ръководство за аутсорсинг на QA: Тестване на софтуерни компании за аутсорсинг