Меню

Тестов сценарий срещу тестов случай: Каква е разликата между тях?

test scenario vs test case

Опитайте Нашия Инструмент За Премахване На Проблемите

Разлика между тестовия сценарий срещу тестовия случай.

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

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

Тестов сценарий срещу тестов случай

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

Бяхме отново на срещата и обсъждахме идеи за спазване на критичния срок. Приложението беше основно за търсене и генериране на различни отчети чрез различни елементи от менюто. Документирането на тестови случаи трябваше да грабне през повечето време и не бяхме сигурни колко ще използва документът за клиента.

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

Какво ще научите:

Бързо ли се заменят тестовите случаи с тестови сценарии?

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

коя е най-добрата компания за игри

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

Кога е важна документацията на тестовите случаи?

  1. Клиентът е поискал същото като част от проекта.
  2. Няма ограничение във времето (не мисля, че е възможно).
  3. Тестерите са по-свежи или неизвестни за продукта.
  4. Фирмена политика (силно вярвам, че тя може да бъде променена).

Позволете ми да споделя с вас едно преживяване:

Аз и моят екип участвахме в тестването на проект от компания от Fortune 500 с гъвкави срокове. Документирахме тестови случаи с най-добрия наличен шаблон и го одобрихме от клиента.

След като компилацията започна да се пуска на екипа за QA, през по-голямата част от деня, нашето задължение беше, механично да проследяваме 100 тестови случая на ден, да актуализираме документа с резултат pass / fail и да го изпратим на клиента в края на деня. Повечето от членовете на екипа започнаха да се оплакват монотонна работа но компанията генерира приходи.

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

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

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

И повярвайте ми, когато документът за тестови случаи е изготвен, ние просто искаме да го следваме механично. Кажете ми колко пъти в кариерата сте преживявали, че вие ​​или съотборникът сте предлагали допълнителни тестови случаи към одобрения документ за тестови случаи?

Още едно преживяване:

По време на седмична активност за екипно предизвикателство, ние обявихме заявлението и помолихме членовете на екипа да включат тестови сценарии.

Всички членове на екипа, включително онези, които реагират късно или не, отговарят на идеите. Защо? Нямаше официална документация, в която трябваше да попълнят очаквания резултат за всяка последователност от функционалности и предварително условие за всеки тестов случай. Събрахме 40 тестови сценария на ден и това беше страхотно изживяване.

За да подкрепя моя опит, Бих искал да представя пример.

Вземете примерно приложение, кажете страница за вход с потребителско име, парола, вход и бутони за отмяна. Ако бъдете помолени да напишете тестови случаи за същите, в крайна сметка ще напишем повече от 50 тестови случая, като комбинираме различни опции и подробности.

тествайте уебсайт за уязвимост при инжектиране на sql

Но ако тестовите сценарии трябва да бъдат написани, това ще е въпрос на 10 реда, както е показано по-долу:

Сценарий на високо ниво: Функционалност за вход
Сценарии на ниско ниво :

1. За да проверите Приложението се стартира
2. За да проверите текстовото съдържание на страницата за вход
3. За да проверите полето за потребителско име
4. За да проверите полето Password
5. За да проверите бутона за влизане и да отмените функционалността на бутона

Вижте също=> 180+ примерни тестови сценария за тестване на уеб и настолни приложения.

Тъй като на всички ни липсва време, тестовите сценарии работят по-скоро като болкоуспокояващ спрей, отколкото като старомоден IODEX. И все пак ефектът е същият.

Разлики между тестовия сценарий срещу тестовия случай в табличен формат

И накрая, бих искал да обобщя разликата между тестовия сценарий и тестовия случай:

Тестови случаиТестови сценарии
Какво представлява => Концепция, която предоставя подробна информация какво да тествате, стъпки, които трябва да се предприемат и очакван резултат от същотоКонцепция, която предоставя информация от един ред за това какво да тествате.
Става въпрос за => Това е повече за документиране на подробности.Това е повече за мислене и обсъждане на подробности.
Важност => Важно е, когато тестването е извън магазина и разработката е на място. Писането на тестови случаи с подробности ще помогне както на разработчика, така и на екипа за осигуряване на качеството в синхрон.Важно е, когато времето е по-малко и повечето от членовете на екипа могат да се съгласят / разберат подробностите от сценарий с едно свързване.
Предимство => Еднократно документиране на всички тестови случаи е полезно за проследяване на 1000-те кръга на регресионно тестване в бъдеще.
По-голямата част от времето е полезно, докато докладвате за грешки. Тестерът просто трябва да даде справка за идентификатор на тестовия случай и не изисква да се споменава всяка минута.
Спестяване на време и дейност за генериране на идеи, предпочитана от общността за тестване на софтуер от ново поколение.
Модифицирането и добавянето е просто и не е специфично за човек.
За огромен проект, при който група хора знаят само специфични модули, тази дейност дава възможност на всеки да разгледа други модули и мозъчна буря и да обсъди
Полезно за => Пълноустойчив документ за тестови случаи е спасителна линия за нов тестер.Добро покритие на теста може да се постигне чрез разделяне на приложението в тестовите сценарии и това намалява повторяемостта и сложността на продукта
Недостатък => Отнема време и пари, тъй като изисква повече ресурси за детайлизиране на всичко за това какво да тествате и как да тестватеАко е създаден от конкретно лице, рецензентът или другият потребител може да не синхронизира точната идея зад него. Нуждаете се от повече дискусии и екипни усилия.

Заключение

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

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

Както обикновено, приветстваме вашите мисли и въпроси. Моля, настройте се.

PREV Урок | СЛЕДВАЩ урок

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

^