Мени

Практична примена ручног испитивања у 7 корака пре пуштања у рад

7 step practical implementation manual testing before production release

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



Ако сте пропустили, можете прочитати овде .

Надам се да сте успели да вас приближите што је могуће ближе одговорима које сте тражили.

У том случају, не бисте ли волели да сазнате више о практичној примени ручног тестирања, како се с њим више упознати и како у њему заправо започети каријеру?



Овај чланак ће осветлити све ове аспекте.

Примена ручног испитивања

Почнимо.





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

Циклус ручног испитивања

Разумети Циклус ручног испитивања или Животни циклус тестирања софтвера (СТЛЦ), пре свега, морамо да разумемо животни циклус развоја софтвера (СДЛЦ), за који сам сигуран да га већ разумете.

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

Као и већина свет иде окретан ових дана ћу своје ствари поједноставити око Агиле-а.

7 практичних корака ручног испитивања пре пуштања у рад

Ево ме.

Запамтите да говорим и о СДЛЦ и о СТЛЦ.

# 1) Окупљање захтева

Фаза окупљања захтева

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

Људи користе било шта да документују ово што им одговара, али не ограничавајући се на традиционалне платформе као што је МС ворд доц, модерне платформе попут Јира / Ралли и нев аге алате попут Трелло.

претвори цхар у инт ц ++

# 2) Дискусија / размена захтева

Фаза дискусије о захтевима

Потом би пословни аналитичар требало да дели документоване захтеве са развојним тимом, тимом за тестирање и УКС тимом (ако је потребно). То се обично дешава на формалном састанку на којем СПОЦ (зависно од једног контакта или цео тим) из све три функције испуњавају и разумеју цео захтев.

У здравој радној култури, захтеви се разматрају из сваког угла и сваки члан састанка може постављати питања и сумње. Једном када се одговоре на сва питања и изврше потребне измене захтева, ова фаза се може сматрати Готовом. Поново се оно што називамо одређеним састанком / кораком и његова документација разликују од компаније до компаније.

Додатна литература=> Како прегледати СРС документ

Када се одговоре на сва питања и изврше потребне измене захтева, ова фаза се може сматрати Готово .

Поново се оно што називамо одређеним састанком / кораком и његова документација разликују од компаније до компаније.

На пример, документација се назива или рашчлањује као СРС (спецификација системског захтева), документ захтева, епика, корисничка прича, тачка приче (могуће, најмања јединица захтева) итд. На сличним линијама овај састанак на коме се дели захтев назива се Захтев Захтев за састанак, сређивање, састављање рупа, итд., Надам се да сте схватили моју поенту?

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

Објавите овај састанак истовремено у два корака, без одређеног редоследа, погледајте следећа два корака.

# 3) Дизајнирање

Развојни тим започиње са својим техничким дизајнирањем чим се расправља о захтевима и када нема већих тачака на чекању. Оно што се ради у овој фази разликује се од компаније до компаније.

Ова фаза може укључивати, али не ограничавајући се на следеће задатке:

  • Одлучивање о развојном приступу
  • Припрема пројектног документа
  • Дизајнирање дијаграма тока
  • Процена напора
  • Откривање утицаја овог новог захтева на било коју постојећу функционалност
  • Треба поправити постојеће податке итд.

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

Белешка: Идеално је да су ови екрани или барем њихове верзије верзије приказани у дискусији о захтевима само да би помогли тиму да стекне боље разумевање. Означава се оригиналним захтевом тако да се на њега може упутити у било ком тренутку.

# 4) Израда сценарија теста / тест случаја

Тест сценарио Фаза пројектовања

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

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

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

Тест случајеви када су једном написани идеално их може прегледати вођа или вршњак из више углова као што су:

  • Покривеност захтева
  • Правописна граматика
  • Стандарди за писање тест примера (ништа осим шаблона који тим / компанија следи)
  • Компатибилност
  • Компатибилност платформе
  • Референце података са тестова
  • Врсте циљаних испитивања итд.

Додатна литература=> Писање тест случајева из СРС документа

У идеалном случају, само након прегледа и потребне модификације, они се прослеђују развојном тиму.

Када сам рекао „једном када се писање тест случаја заврши“, мислио сам једном „сви тест случајеви су написани на основу потпуног познавања датог захтева и могућих тест сценарија откривених до тог одређеног времена“. Готово је немогуће имати 100% покривеност тест случаја у првом покрету.

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

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

Па, до сада неки од вас сигурно сумњају у моје знање о тестирању софтвера јер неку реч (која је на неки начин постала норма у тестирању софтвера) још увек не користим. План теста, зар не?

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

У сваком случају, то је сасвим посебна тема за дискусију. Поделити информације о овоме „одговара свима“ је тешко, али покушаћу.

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

Додатна литература=> Како написати документ плана теста

Информације које би у овој фази требало апсолутно замрзнути:

  • Обим тестирања: Захтев, уназад компатибилност, платформе, уређаји итд.
  • Особа / тим који ће тестирати
  • Процена напора на испиту
  • Ограничења: Све претпоставке или унапред прихваћена ограничења.
  • Људи додатно документују критеријуме уласка, критеријуме изласка, ризик итд., Што мислим да заправо не треба посебно помињати, јер би то пре требало бити нормално разумевање.
    • Критеријуми за улазак (Када започети тестирање): Мало започиње када постоји тестирани део функционалности доступан за тестирање. Мало ко чека да се читава функционалност тестира. Када се утврди да основни проток функционише, започиње тестирање.
    • Излазни критеријуми (Када се зауставити): Када нема блокатора, критични и главни (изложени ударцу) кварови у испитивању отворене фазе могу се зауставити. Или на пола пута, када постоји превише дефеката са којима се тестирање може зауставити, одговарајуће заинтересоване стране.
    • Ризик : Пословни ризик или функционални ризик ако се испитивање не догоди према документованом плану.

# 5) Фаза развоја

Фаза развоја софтвера

Развојни тим након фазе дизајнирања започиње са стварним развојем и јединственим тестирањем када и када заврше са развојем проверивих делова захтева. Они могу проследити функционалност за тестирање у комадима када и када је имплементирана или могу проследити целокупну функционалност одједном.

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

# 6) Фаза тестирања

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

Тим за тестирање започиње тестирање или када је тестиран (нешто што се може независно тестирати) део целокупног захтева или када је развијен целокупан захтев.

Дозволите ми да детаљније разрадим у овој фази и разговарам о важним задацима:

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

Друга ствар која се разликује од компаније до компаније је колико тестова треба обавити. Као и у неким случајевима, прва рунда тестирања се дешава на малим деловима карактеристика када су спремни, а затим следи рунда тестирања од краја до краја у другом окружењу када се сви захтеви развију. Али опет, такође сам чуо за људе који су радили три правилна пуна круга тестирања, а четврти као круг здраве памети / дима.

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

Прочитајте детаљне кораке=> Фаза извршења теста

# 7) Преглед пословног аналитичара (БА)

Пословни аналитичар прегледава тражену функционалност позивањем на резултат теста или позивањем на резултат теста плус поигравање са апликацијом како би стекао стварни осећај. Овај корак је подвргнут различитим акцијама међу компанијама.

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

Изнад 7 корака догађа се да би се испуниле све корисничке приче / захтеви, посебно издање (испорука). Када су сви ови кораци завршени за све захтеве, издање је спремно за отпрему.

# 8) Пошиљка / пуштање

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

Препоручено читање=> Процес пуштања у тест

Врсте ручног (читај људског) тестирања

Па, ако морамо да разговарамо о укупним врстама тестирања у бројевима, негде сам их нашао 100 врста тестирања са различитим именима . Да будем искрен, нисам довољно паметан да разумем разлику између свих тих врста (намењена каламбуру).

Једноставно је и једноставно: Тестирање функционалности апликације према датом захтеву уз људске напоре и интелигенцију. Даље се дели на неколико типова на основу обима и дневног реда тестирања. Врсте наведене у следећем пара.

Даље се дели на неколико типова на основу обима и дневног реда тестирања. Врсте наведене у следећем пара.

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

Испод је листа са неким од популарних и важних типова тестирања који се могу сврстати у Људско тестирање:

  • Ручно функционално испитивање : Тестирање функционалности апликације према датом захтеву уз људске напоре и интелигенцију. Даље се дели на неколико врста на основу обима и дневног реда тестирања, као што су системско тестирање, јединствено тестирање, тестирање дима, испитивање исправности, интеграционо тестирање, регресијско тестирање, тестирање корисничког интерфејса итд.
  • Тестирање перформанси : Ово се сврстава у нефункционално тестирање, зар не? Али опет, човек је тај који то спроводи, мада извршење врши човек или алат. Тестер би требало да изврши ово тестирање у смислу времена одзива (да види да ли је прихватљиво) ако не би требало да користи било који алат за испитивање оптерећења и све остало.
  • Прегледач / Испитивање компатибилности платформе: Апликација која се тестира треба да изгледа и ради како се очекује (очигледно може да постоји мања разлика у зависности од мотора претраживача) у прегледачима и платформама (или уређајима ако је то мобилна апликација).
  • Испитивање употребљивости : Дозволите ми да се прво сложим да је ово огромна тема сама по себи и обично је у власништву специјалиста за испитивање употребљивости. Још увек верујем да бисмо као тестер требали да пријавимо или истакнемо ако нађемо нешто мање корисно или да делимо своје мишљење.
  • Испитивање сигурности : Опет врло огроман тип тестирања и наравно захтева пуно практичног знања. Тестер треба да покуша да научи и изврши најмање основне тестове попут неовлашћеног коришћења УРЛ-а, скриптирања на више локација, убризгавања СКЛ-а, отмице сесија итд., У зависности од доступног знања и где год је то могуће.
  • Вишестанарско тестирање: Ако је ваша апликација вишестанарска, тј. Појединачна инстанца која садржи податке више клијената, онда је ово тестирање неопходно. Без обзира на изричито помињање захтева, то би требало учинити. Подаци једног клијента који се приказују другом врста су кривичног дела за развој и тестирање.

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

То је све за овај део. Хвала вам за читање. Делите своје ставове / повратне информације у коментарима.

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

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

^