В настоящото четиво ще имате неворятната възможност да прочетете онова, което другаде трудно ще ви кажат, камо ли да ви обяснят подробно. Тъй като JQA е единственото постакадемично обучение, имащо за цел да ви приближи максимално до QA трудовата обстановка, ние сме длъжни да ви запознаем с това какво е Test Case, какви са неговите атрибути и т.н.

Нека започнем от това какво всъщност е Test Case

Това представлява тестови сценарий, описващ начина, по който продукта извършва очаквано (предварително закодирано) действие. Хората със съответната компетенция (най-често програмисти) са свършили работа, свързана с писането на кодове на различни компютърни езици.

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

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

Добрият Test Case се познава лесно. Той дава възможност и за обратното – да откроим добрия QA специалист от неопитния такъв само по начина, по който е изготвено (изискването за специфично заглавие, от което се разбира за какво става въпрос, също е важно да бъде спазено).

Един Test Case трябва да разполага с кристално ясно описани стъпки, които да насочват четящия към точно онова нещо, което трябва да провери, разбере и изпълни по задание. Разбираемостта на описаните точки трябва да бъде на такова ниво, че дори и човек, незанимавал се с програмиране или с каквато и да е IT дейност, да изпълни стъпките на един тест кейс.

Атрибутите на един Test Case

Атрибутите на Test Case-ът са няколко, като обхващат от заглавието и номера (ID-то) , та докато стигнем до заключението (Pass or Fail). В текста днес ще минем през всеки един атрибут на Test Case-а и ще се опитаме да засегнем най-важното поотделно, така че пригответе се за четене и попиване на нови знания!

• Test Case ID – тук се очаква уникалност (може би сами се досещате, че трябва да е така). Уникалният номер на всеки един кейс означава, че той е надежден и към него може да се подходи сериозно (казано на по-разговорен професионален език: изобщо да се занимават с вашия тест кейс);
• Name – за името не е зле да се знае, че правещият тест кейс е добре да се погрижи кръщаването да е с име, което да е възможно най-кратко и ясно. Препоръчително е в името да се съдържа компонента на тестване и действието, което се проверява с дадения тест кейс.

Ако вие сте човекът, от когото зависи как да се казва един тест кейс, то поставете се в обувките на програмиста. Как би ви било най-лесно да започнете и по-скоро какво име би ви улеснило да започнете от нулата с четенето и съответно с изпълнението на тест кейс;

• Description – допълнително инфо за теста. Тук е мястото, на което вие, като QA специалист, можете максимално да помогнете на човека, на който му предстои да се занимава с теста, който вие сте правили като му дадете допълнителна информация, която би била полезна при изпълнението на кейса.

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

• Preconditions – условията, които са необходими да са изпълнени преди да се премине към изпълнението на същинския кейс;
• Test Datа – тест датата е съвкупност от тест данни, с които се тества, а може да го приемете и като среда за тестване;
• Steps to Reproduce – тук не е лоша идея (да не кажем, че е задължително) срещу всяка стъпка да присъства Expected Result. Този „Expected“ подход дава правото на програмиста да си даде възможно най-ясна представа до какво се опитвате да стигнете в крайна сметка.

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

• Post – Conditions – положението, в което изпращате продукта обратно (разликите);
• Pass or Fail – ако вие като QA специалист сте свършили своята работа „от-до“, но продуктът работи по очаквания начин, то тестът е с положителна оценка Pass.

Ако, обаче сте открили наличие на бъг, то тестът е негативен с оценка съответно Fail и ЗАДЪЛЖИТЕЛНО го прикачате към теста при връщането му към разработчиците на софтуерния продукт.