Мени

Шта КА тестер треба да зна о процесу управљања издавањем и применом

what qa tester should know about release

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

На данашњем састанку нашег тима, менаџер је проверио све на свом спремност за извршење теста . Поменуо је да ће „код бити спреман за КА до сутра ујутро“. На шта је мислио када је рекао „код ће бити спреман“, да ли то значи да ће програмери вечерас написати код у КА окружењу?

апликација временске картице за ипхоне и андроид

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

Многи од вас се сада могу запитати шта је примена и шта они заиста раде у њој?

процес управљања пуштањем и распоређивањем за ка

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

Општи процес управљања издавањем и применом и значај за КА тим

  • Зашто заиста одржавамо различита окружења?
  • Како се код премешта из једног окружења у друго?

У овом чланку ћу покрити следеће теме

  1. Зашто је за тестере важно да буду свесни процеса пуштања и примене?
  2. Различита окружења
  3. Шта подразумевате под Израдом и применом?
  4. Планирано у односу на хитно распоређивање
  5. Контролна листа квалитета - пре и после примене

# 1. Зашто је за тестере важно да буду свесни процеса примене?

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

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

# 2. Различита окружења

Различита окружења

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

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

Такође прочитајте=> Како ефикасно припремити „испитни лежај“ и умањити недостатке тестног окружења

# 3. Шта подразумевате под Израдом и применом

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

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

Једном када је изградња примењена, КА тим је обавештен да уради тестирање верификације израде (БВТ) и ако је успешан, тим изводи остатак функционално испитивање .

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

Израде се одржавају помоћу бројева рецимо 1.0.01 или 1.0.03. Дакле, могуће је да верзија 1.0.01 можда има ДЛЛ в0.2, а верзија 1.0.03 ДЛЛ в0.5. За КА тим постаје важно да обезбеди да се исправна израда примени у окружењу пре почетка тестирања. Увек је добра идеја водити евиденцију о променама наведеним као део сваке верзије.

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

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

Изградња и примена

бесплатни софтвер за поправак рачунара за Виндовс 10

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

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

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

Порука Деплоимент Цомплете (Обавештавање завршено) даје индикацију КА тиму да су промене / нови код спремни за тестирање.

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

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

# 4. Планирано у односу на хитно распоређивање

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

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

Планирано распоређивање може имати свој изазов. Размислите о случају када се нови код поставља у КА окружење и током теста исправности тим утврди квар блокера и тестирање мора да се заустави. Да ли тест тим чека недељу дана до следећег распоређивања?

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

# 5. Контролна листа квалитета - пре и после примене

Пре распоређивања -

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

После распоређивања -

користећи низове у функцијама ц ++

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

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

Закључак

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

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

Да ли вам је овај поступак био користан? Обавестите нас о процесу примене који пратите у својој организацији.

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

^