Мени

Тест сценариј против тест случаја: Која је разлика између њих?

test scenario vs test case

Испробајте Наш Инструмент За Елиминисање Проблема

Разлика између сценарија испитивања и тест случаја.

пре 6 година , док сам радио са средњим МНЦ-ом, када сам предложио документовање тест сценарија, уместо да губим време на припрему комплетног доказног документа који се зове тест случајеви, све главе су ми се изнервирано окренуле.

Израз лица јасно је доказивао да сам направио велику грешку сугерирајући је. Иако нико није негирао ту идеју, нико није ни прихватио. Сви су сматрали да би следење традиције, тј. Писање докумената са тест случајева, било сигурније. Нисам могао да расправљам.

Тест сценариј против тест случаја

После 4 године , компанија је добила пројекат тестирања, где је једино ограничење било време, а једино очекивање било је потпун доказ тестирање.

Поново смо били на састанку и разговарали смо о идејама за испуњење критичног рока. Апликација се углавном тицала претраживања и генерисања различитих извештаја путем различитих ставки менија. Документирање тест случајева требало је да уграби већину времена и нисмо били сигурни колико ће документ клијенту користити.

Предложио сам документовање тест сценарија и некако су се, уз оклевање, сви сложили. Не треба напомињати да бисмо могли уштедети драгоцено време за документацију и искористити је за тестирање.

Шта ћете научити:

Да ли се тест случајеви брзо замењују тест сценаријима?

Временом, како се све мења, софтверска индустрија и процеси такође су се много променили.

који програм отворити епс датотеку

Традиционални Водопад и В-модели замењују се агилним и итеративним моделима. Документација је неопходна али да би се поштовали рокови и поступак учинио лаким и транспарентним, начин документације се може променити.

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

  1. Клијент је тражио исто као део пројекта.
  2. Нема временског ограничења (мислим да то није могуће).
  3. Тестери су свежији или непознати производу.
  4. Политика компаније (чврсто верујем да се може променити).

Дозволите ми да поделим са вама једно искуство:

Ја и мој тим били смо укључени у тестирање пројекта компаније Фортуне 500 са флексибилним роковима. Документирали смо тест случајеве са најбољим доступним шаблоном и клијент га одобрио.

Једном када је израда почела да се објављује КА тиму, већи део дана била нам је дужност, механички пратити 100 тест случајева дневно, ажурирати документ резултатом пасс / фаил и послати га клијенту на крају дана. Већина чланови тима почели су да се жале монотоно дело али је компанија стварала приход.

Затим је уследила пауза за један дан, без нове верзије за тестирање. Седели смо заједно на почетку дана и разговарали о томе шта ћемо радити за тај дан. Када сам предложио да генеришем више идеја за побољшање документа о тест случају, сви чланови тима су порекли да улажу напоре.

Што се њих тиче, више се није имало о чему размишљати јер смо покрили све сценарије. И убедити их да размишљајте ван оквира и генеришите више идеја било заиста тешко.

Већину времена, када документујемо тест случајеве и то и када их клијент одобри, тај људски ум мисли да смо одрадили свој посао и наш ум аутоматски престаје да разматра било какав напор да размишља о другим начинима за тестирање производа.

И верујте ми, када се припреми документ за тест случајеве, ми га само желимо механички пратити. Реците ми колико пута сте у својој каријери доживели да сте ви или саиграч нудили додатне тест случајеве одобреном документу тест случајева?

Још једно искуство:

Током недељних активности тимског изазова, најавили смо пријаву и замолили чланове тима да улијеју сценарије теста.

Сви чланови тима, укључујући оне који касне или који нису реаговали, дају идеје. Зашто? Није постојала формална документација у којој су морали испунити очекивани резултат за сваки редослед функционалности и предуслов за сваки тест случај. Прикупили смо 40 сценарија за дан и то је било сјајно искуство.

Да фаворизујем своје искуство, Изнео бих пример.

Узмите пример апликације, рецимо страницу за пријављивање са дугметима за корисничко име, лозинку, пријаву и отказивање. Ако се од нас затражи да напишемо тест случајеве за исти, на крају ћемо написати више од 50 тест случајева комбиновањем различитих опција и детаља.

Али ако ће се писати сценарији за тестирање, радиће се о 10 редова као што је приказано доле:

Сценариј на високом нивоу: Функционалност пријаве
Сценарији на ниском нивоу :

1. Да бисте проверили да ли се апликација покреће
2. Да бисте проверили текстуални садржај на страници за пријављивање
3. Да бисте проверили поље Корисничко име
4. Да бисте проверили поље Лозинка
5. Да бисте проверили дугме за пријаву и отказали функцију дугмета

Такође видети=> 180+ примера тест сценарија за тестирање веб и десктоп апликација.

Како нам свима недостаје времена, сценарији испитивања делују као спреј против болова, а не као стари ИОДЕКС. А опет, ефекат је исти.

Разлике између сценарија испитивања и тест случаја у табеларном формату

На крају, желео бих да резимирам разлику између Тестног сценарија и Тест случаја:

Тест случајеваТест сценарији
Шта је то => Концепт који пружа детаљне информације шта тестирати, кораке које треба предузети и очекивани резултат истихКонцепт који пружа информације у једном реду о томе шта тестирати.
Ради се о => Више се ради о документовању детаља.Више се ради о размишљању и расправи о детаљима.
Важност => Важно је када је тестирање искључено, а развој је на лицу места. Писање тест случајева са детаљима помоћи ће синхронизацији и развојног и КА тима.Важно је када је времена мање и већина чланова тима може да се сложи / разуме детаље из једног линер сценарија.
Предност => Једнократна документација свих тест случајева је корисна за праћење 1000 рунди регресивног тестирања у будућности.
Већину времена је корисно док извештава о грешкама. Тестер треба да наведе референцу ИД-а тест случаја и не захтева помињање сваког минута детаља.
Уштеда времена и активност генерисања идеја, коју преферира заједница за тестирање софтвера нове генерације.
Измена и додавање је једноставно и није специфично за особу.
За огроман пројекат, где група људи познаје само одређене модуле, ова активност даје прилику свима да погледају друге модуле и олују мозга и разговарају
Корисно за => Потпуно доказан документ о тест случају је животни пут за новог тестера.Добра покривеност тестом може се постићи поделом примене у тестним сценаријима и смањује поновљивост и сложеност производа
Недостатак => Захтева време и новац, јер захтева више ресурса за детаљно објашњење свега о томе шта и како тестиратиАко га је креирала одређена особа, рецензент или други корисник можда неће синхронизовати тачну идеју која стоји иза тога. Потребно је више дискусија и тимских напора.

Закључак

Тест случајеви су најважнији део животног циклуса развоја софтвера и без њега је тешко нешто пратити, разумети, следити и образложити. Али у ери Агиле-а, тест примери се брзо замењују тест сценаријима.

Заједнички тест контролна листа за сваку врсту тестирања (тестирање базе података, тестирање графичког корисничког интерфејса, функционалност итд.), заједно са сценаријима тестирања, представља модерну артиљерију за софтверске тестере. Дискусије, обука, питања и вежбање могу дефинитивно променити коначни графикон вашу продуктивност као и матрицу извештаја о грешкама.

Као и обично, поздрављамо ваше мисли и упите. Молим вас, прилагодите се.

ПРЕВ Туториал |. | СЛЕДЕЋА Лекција

како отворити .торрент датотеке

Препоручено читање

^