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

how perform post release testing effectively

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

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

Ово ми је било све ново и у мислима сам имао толико питања и недоумица:

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

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

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

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

• Шта је верификација издања након продукције?
• Који су задаци и активности укључени у фазу верификације након објављивања?
• Да ли треба да тестирам све испочетка?
• Како да формулишем стратегију верификације постпродукције?
• Ко израђује план теста за постпродукцију?
• Ко одобрава план теста за објављивање након продукције?
• Када могу да направим план верификације за постпродукцију?
• Завршио сам верификацију издања након продукције. Шта је следеће?
• Шта се дешава ако нађем проблем?
• Шта још морам да знам о поступку верификације постпродукције?
• Закључак:
• Препоручено читање

Шта је верификација издања након продукције?

По дефиницији, пошта значи После , Издање продукције односи се на распоређивање да ЖИВЕ / производна окружења и Верификација укључује осигуравајући да објављене функције испуњавају захтеве .

Препоручено читање=> Како ефикасно припремити „Тест Енвиронмент“ пре почетка тестирања

Циљ је да се верификује издање у продукцијским / ЛИВЕ окружењима.

знање из домена здравствене заштите за тестере пдф

Али онда се постављају питања:

• Зашто треба да тестирамо издање након продукције када сам све тестирао на КА окружењу?
• Зашто предвиђамо да ће се појавити проблеми у производњи, иако смо издање темељито тестирали у тест окружењу?

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

Разлози због којих бисмо имали проблема са производњом:

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

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

Такође прочитајте=> Шта КА тестер треба да зна о процесу примене

3) Подручја утицаја нису идентификована - Могу постојати неки сценарији за које тим можда није тачно и потпуно идентификовао погођена подручја.

На пример, размотрите а СааС Животна средина.

Ако тим није идентификовао утицај прерађене ДБ табеле на клијента користећи старију шему табеле (нпр. Губитак података, потреба за миграција података пре издања итд.) итд. Ово је мање вероватно да ће се догодити за добро планиране пројекте са прецизним захтевима. Али, могућност и даље постоји.

4) Непозната подручја удара - То се може догодити ако опсег и погођена подручја испуштања нису познати. На пример, у компанији са неколико софтверских производа који деле заједничке ДБ и архитектуру, чак и мала промена може сломити функционалност многих производа.

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

Задаци и активности постпродукције углавном укључују:

• Верификација издања након продукције
• Пријави резултате верификације
• Пријављивање свих проблема пронађених у производњи
• Чишћење података верификације након објављивања
• Надгледање након објављивања (ако је применљиво)

Да ли треба да тестирам све испочетка?

Не нужно. Ово зависи од верзије која ће се објавити и анализе утицаја.

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

Како да формулишем стратегију верификације постпродукције?

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

Стратегија треба да буде на истим линијама као и испитни ток праћен током КА циклуса. Важно је укључити најважније и најважније кораке који омогућавају максимално покривање функционалности.

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

Добра стратегија објављивања након продукције треба да:

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

Ко израђује план теста за постпродукцију?

Ово ће се разликовати у зависности од предузећа и зависиће од организационе структуре.

Узмимо пример следеће организације КА тима.

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

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

Ово ће се разликовати у зависности од предузећа и зависиће од организационе структуре.

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

Када могу да направим план верификације за постпродукцију?

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

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

Завршио сам верификацију издања након продукције. Шта је следеће?

Након завршетка верификације након објављивања, следећи кораци би били

1) Комуникација резултата верификације - Резултате верификације треба доставити заинтересованим странама, укључујући сва питања која су можда пронађена у производњи.

2) Пријављивање свих проблема пронађених у производњи помоћу алата за управљање недостацима - До олакшати анализу основног узрока и сљедивост .

3) Чишћење података о верификацији након објављивања - Чишћење података треба обавити након завршетка верификације.

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

4) Надгледање пуштања након продукције (ако је применљиво) - Нека издања захтевају праћење производње.

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

Шта се дешава ако нађем проблем?

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

Важно је да се сви пронађени проблеми пријаве у алатки за праћење недостатака. Препоручује се да се они поставе као засебни тип издања (нпр. Грешка у постпродукцији) како би се показало одвајање од редовних грешака КА циклуса. Ови проблеми могу се лако филтрирати ако су потребни у сврху анализе основног узрока.

Шта још морам да знам о поступку верификације постпродукције?

Поред стварног поступка верификације, плана и стратегије верификације постпродукције, у наставку су наведени и неки напутци:

модел животног циклуса у софтверском инжењерству

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

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

Ограничења:

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

Пример # 1): За компанију еСурвеи, ако тестирање укључује одговарање и предавање анкете, КА би требало да пошаље захтев за брисање тест анкете након верификације како не би утицало на податке о прикупљеним анкетама клијената и њихове статистике.

ИС пример # 2): За компанију за е-трговину, претпоставимо да се ажурирање цена СКЛ посао покреће сваког дана у поноћ и поставља коначну цену на веб локацију. Не можемо покренути овај СКЛ на захтев, више пута у сврху верификације након издавања, јер то може довести до тога да се недовршени подаци потисну у производњу.

Штавише, то може повећати шансе за ДБ ћорсокаци и велика потрошња ресурса ЦПУ и меморије током вршног радног времена што може утицати на перформансе клијентске апликације.

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

Пример:

Преглед пројекта:

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

1. Провера ваљаности поља са именом мора бити уклоњена. Раније је примењено као „Презиме би требало да има најмање 4 знака“ (побољшање за постојеће поље)
2. Примените дугме за пребацивање поред адресе е-поште како би корисник могао да подеси поставке приватности за приказ адресе е-поште на свом профилу (захтев за нову функцију)
3. Корисник би требао бити у могућности да бира свој аватар (нови захтев за функцију)
4. Смањите АПИ позиве током процеса регистрације ради побољшања перформанси апликације (побољшање)

План верификације постпродукције:

Закључак:

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

На пример, док користите Модел водопада , тим може имати продукцијско издање на сваких 1,5 месеца, међутим са Агиле процесом, исти тим сада може имати производно издање на сваке 2-3 недеље.

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

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

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

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

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

О аутору: Овај корисни чланак написала је Неха Б. Тренутно ради као менаџер за осигурање квалитета и специјализована је за вођење и управљање интерним тимовима и офшор тимима за КА.

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

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

• Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
• Преузимање е-књиге за тестирање буквара
• Практична примена ручног испитивања у 7 корака пре пуштања у рад
• Испитивање оптерећења помоћу ХП ЛоадРуннер водича
• Практично тестирање софтверског тока КА процеса (услови за објављивање)
• Разлика између тестирања радне површине, клијентског сервера и веб тестирања
• Шта је гама тестирање? Завршна фаза испитивања
• Шта је рано тестирање: тестирајте рано, често тестирајте, АЛИ како? (Практични водич)