Мени

Како тестирати апликацију без захтева?

how test an application without requirements

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

Технички нема апликација без захтева. Замислите софтвер који не ради ништа специфично, већ се једноставно шири ред за редом кода. То ће бити степениште које не води никуда.

Сав софтвер има захтеве и циља се на одређени задатак; конкретно, то је решење проблема. Тако без захтева софтвер није могућност.

Међутим, софтвер без документованих захтева је стварност са којом се нажалост већина нас чешће суочава ми волимо. Једино горе може бити то што је документација недовољна, нетачна или ужасно застарела. Нажалост, и ово се дешава.

тест без захтева

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

Стога је овај чланак покушај неких пракси које смо следили када смо се нашли у тим ситуацијама.

Такође прочитајте:

свф датотеке се не репродукују у прегледачу

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

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

Све су то препреке које ми испитивачи морамо храбро прећи и успешно се појавити. Колико тачно, зар не?

Ево три најбоље методе за тестирање апликације без захтева:

Метод # 1:

Радите са било којом мало документације која вам дође под руку. То може бити основни једноставан заостатак (у агилним пројектима), датотека помоћи, е-пошта, старија верзија БРД / ФРД или стари тест примери (потражите их у својим АЛМ алатима и можда ћете их пронаћи) итд.

Истражите, распитајте се и увек постоји неко документовано суђење, чак и ако је танко.

Када ово не успе, не одбацујте своје искуство као корисник софтвера.На пример, ако морате да тестирате операцију преноса за банковни рачун, нико не треба да нам каже како се то ради, зар не? Јер као клијенти интернет банкарства сви знамо да нам је потребан рачун са и на рачуне са великим бројем расположивих средстава за пренос.

Сложили смо се да неће све ситуације бити тако директне, али опет, можда и оне буду.

Метод # 2:

Користите старију / тренутну верзију апликације као референцу за тестирање будућег издања софтверског производа. Сада признајем да ово негативно одступа од правила, „Никада не пишите тест случајеве користећи апликацију као референцу“. Међутим, када радимо у мање савршеној ситуацији, морамо обликовати правила која ће одговарати нашим потребама.

Помаже да се следећи аспекти у перспективи држе у перспективи:

  • Апликација може садржати грешке - па ако вас систем након регистрације директно одведе на Сцреен1 (одређени хипотетички екран ради нашег примера) - Никад не претпостављајте да је то исправно понашање. Такође, ако поље заузима алфанумеричке знакове и представља телефонски број - питање је и уверите се да апликацију не узимате као одобрени пример за очекивану функционалност.
  • У горе наведеним ситуацијама користите своју просудбу и искористите помоћ апликације да вам започнете, али будите критични према њој и поставите питање да ли ради.

Метод # 3:

Разговарајте са члановима пројектног тима:

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

Сада, применимо методе у примеру:

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

Примени метод бр. 1:

Пронађите било коју документацију коју бисте могли. Питајте свој развојни тим да ли имају макете екрана / потражите алатку АЛМ или било шта друго. Ако нешто пронађете, то би било добро полазиште. Али ако овај метод ништа не покаже, онда можете да користите свој пресудник / интуиција тестера.

Сви знамо како функционишу колица за куповину, зато претпоставите и дођите до неколико основних сценарија као што су:

  • Предмети се могу додати у корпу након прегледавања или претраживања
  • Једном када додам ставке у корпу, листа ставки треба да се освежи
  • Корисник би требао бити у могућности да настави куповину чак и након додавања неколико предмета у корпу
  • Двоструко додавање исте ставке довешће до повећања броја додатих ставки
  • Ставке се могу ажурирати
  • Предмети се могу уклонити
  • Укупан износ треба да буде једнак збиру свих додатих цена
  • Порез треба израчунати на основу унетог поштанског броја
  • Трошкови испоруке морају се додати у складу с тим

Можемо наставити, али сигуран сам да сте схватили.

Примени метод бр. 2:

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

Као што можете видети са доњег екрана, ове ствари су очигледне - имена поља, дугмад или други присутни елементи итд. (кликните на слику за увећани приказ)

тест без захтева

У овом тренутку тестери имају неколико питања попут:

  1. Шта се дешава када дам знак у поље за износ?
  2. Када додам превише ставки?
  3. Који је максимални бр. предмета које ово може потрајати? Итд.

Примените метод # 3 :

Однесите своју листу питања БА-у, програмеру или чак клијенту и потражите појашњење. Једном када се метода 3 заврши, требали бисте у великој мери бити опремљени свим информацијама које су вам потребне за писање детаљних случајева испитивања и спровођење тестирања са толико поверења као што би било када би била доступна детаљна документација.

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

У закључку, све се не губи када документација не постоји или је недовољна. Има још наде! Молимо поделите своја искуства у сличним ситуацијама.

О аутору: Ову корисну поруку написао је члан СТХ тима Свати С.

Као и увек, ваши коментари, питања и предлози су добродошли.

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

^