Мени

Како одлучујете које су недостатке прихватљиве за покретање софтвера?

how do you decide which defects are acceptable

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

Софтвер Го-Ливе је увек велики догађај за било који софтверски производ. Важно је апсолутно осигурати да све функционише и да јесмо објављивање квалитетног софтвера за кориснике .

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

Често чујемо да тестирање треба радити док не испунимо излазне критеријуме. Такође смо чули да се недостаци морају отклонити на прихватљив ниво.

Иако су ово одличне звучне смернице, оне су нејасне.

критеријуми за покретање софтвера

Да будемо прецизнији:

  • Који проценат кварова је прихватљив за покретање софтвера?
  • Како се одлучујете за отворене недостатке са којима софтвер може да ради?
  • Шта врсте недостатака су озбиљнији од осталих?

Препоручено читање => Када зауставити тестирање?

Да ли сте икада имали ова питања? Затим ће вам овај чланак помоћи да одговорите на њих. Прочитајте на…

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

Што више отклоните недостатке, већа је вероватноћа да је нови недостатак убризган током затварања недостатка. Тако,

  • Како одлучујете о степену недостатака и типу недостатака са којима можете живјети?
  • Како постављате основни софтвер који ће бити постављен за покретање?
  • Како координатори УАТ упућују позив за покретање или не?
  • Према којим параметрима треба проценити софтвер?
  • Како да одговоримо - Да ли је софтвер погодан за употребу и да ли ће донети вредност заинтересованим странама?

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

Моје искуство показује да купци желе своју вредност за новац и имају критеријум изласка да би УАТ могао да живи.

Наведени излазни критеријуми би више или мање дефинисали прихватљиви обим проблема у свим областима примене, као што су:

  1. Функционално
  2. Перформансе и оптерећење
  3. Употребљивост
  4. Сигурност
  5. Интеграција са спољним системима
  6. Извештаји
  7. Миграција података

Верујем да сваку поједину од ових врста недостатака треба даље објаснити. И, управо то ћемо сада учинити:

јава вс ц ++ што је боље

# 1. Функционални недостаци:

Ако је софтвер креиран према спецификацијама које је дао купац, он мора да испуњава захтеве. Сва одступања евидентирају се као функционални недостаци.

Функционални недостаци се затим класификују према озбиљност и приоритет .

Следе важна разматрања:

  • Кварови озбиљности и приоритети обично су они који би могли утицати на свакодневну употребу софтвера. Ове врсте кварова су оне које се морају отклонити пре пуштања у рад. Без изузетака.
  • Понекад се функционални недостаци класификују као захтеви за промену јер нису били део првобитно задатих захтева. Такви ЦР-ови, који су неопходни за пословање компаније након покретања уживо, такође морају бити примењени.
  • Класификацију недостатака и одређивање приоритета функционалних недостатака врше координатори УАТ у сарадњи са пословним корисницима и пословним аналитичарима. Обично купац има излазне критеријуме колико% квара може бити отворено за покретање.

# 2. Кварови перформанси и оптерећења:

Кварови перформанси је важно узети у обзир за пуштање у рад и још више ако софтвер треба да користе спољни корисници.

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

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

На пример: Ако постоји пакетни поступак који се покреће на крају сваког дана и ако време одзива апликације пати док то траје, онда је и фактор перформансе фактор који треба узети у обзир.

  • Учинак се обично мери у смислу времена одзива екрана који ће се приказати и постати доступни корисницима док у систему постоји одређени број истовремених корисника.
  • Тестови перформанси се раде помоћу алата као што су ЛоадРуннер , ВебЛоад , Неолоад итд.
  • Перформансе софтвера при датом оптерећењу и при будућем предвиђеном оптерећењу обично су документоване у уговору и морају се демонстрирати пре пуштања у рад.
  • Екрани или делови апликације које корисници користе мање користе се за одлагање на процене након покретања.
  • Перформансе такође зависе од врсте хардвера и мрежних услова на којима је софтвер распоређен.
  • Тестови перформанси се раде током УАТ-а на наведеном хардверу помоћу алата за перформансе и њихови недостаци се прате на начин сличан ономе код функционалних недостатака. Они такође имају приоритет и постигнут је консензус о испуњавању излазних критеријума за покретање.
  • Обично се тестови перформанси и оптерећења у УАТ-у раде након завршетка функционалног УАТ-а од стране пословних корисника и постизања прихватљивог излазног критеријума за функционалне недостатке.

# 3. Дефекти употребљивости:

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

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

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

# 4. Сигурносни недостаци:

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

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

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

# 5. Интеграција са спољним софтверским системима:

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

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

Провера спољног међусобног повезивања система требало би опсежно проводити током фаза система и УАТ. То би морало бити неопходно за излазне критеријуме који би требало да буду задовољени пре пуштања у рад.

# 6. Извештаји:

Извештаји из софтверске апликације су критичан начин да се покаже да се подаци у апликацији броје.

На пример: сви подаци који се односе на обрачун морају да се рачунају у билансима кредита и задужења.

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

# 7. Миграција података:

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

Сви стари подаци можда неће бити доступни у новом систему; међутим, снимак старих података могао би бити доступан у новом систему. Ови подаци би требали бити доступни према договору.

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

Пример излазних критеријума за покретање:

Ово је само пример. Може се разликовати од пројекта до пројекта.

  • 100% дефеката Приоритет 1 је затворено (критичност озбиљности и приоритет 1)
  • 90% дефеката приоритета 2 је затворено (озбиљност висока и приоритет 2), а логично заобилазно решење је доступно за осталих 10% дефеката. Доступан је и план за затварање осталих 10% недостатака.
  • Контролна листа за постављање производње и здравствено исправно стање је спремна.
  • Тим за подршку производњи је формиран и спреман за затварање улазница.
  • 70% недостатака приоритета 3 је затворено и постоји план за затварање остатка од 30% ниских недостатака.

Неколико напомена:

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

У закључку

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

О аутору: Ово је гостујући чланак Крисхнана Венкатрамана. Има скоро 18 година искуства у тестирању софтвера. Радио је на многим великим и сложеним пројектима за тестирање софтвера.

Слободно објавите своје упите / коментаре у наставку.

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

^