how improve test release process
Погледајмо типични процес укључен у испоруку софтвера од „фазе развоја“ до „фазе тестирања“ за а успешно пуштање софтвера без грешака у производњу / клијента .
Софтверске компаније ове процесе или превиде или прескоче, што резултира лошим управљањем тестовима и самим тим „ бугги ”Софтвер се издаје клијенту, што доводи до„ незадовољни купци ”.
Иако много времена и великог труда даје тим за тестирање за свако издање , када објављени софтвер нема квалитет како је дефинисан или је стандардно означен или не испуњава очекиване критеријуме, то неће утицати само на репутацију компаније код купаца већ и демотивира и деморалише пројектни тим, што је најважније испитни тим у целини .
Ако сте део тима за тестирање у овом сценарију, можда ћете и даље размишљати „како да побољшам своје могућности тестирања и постоји ли бољи начин за превазилажење ове ситуације“.
Желим да дам неколико савета и сугестија, на основу свог искуства са разним тимовима за тестирање који су укључени у издања софтверских апликација и корпоративних производа са више домена и платформи и са више оквира за тестирање, на како побољшати процесе објављивања теста , што ће вам поједноставити професионални живот као инжењера за тестирање или менаџера за испитивање за испоруку софтвера светске класе.
Шта ћете научити:
- Процес објављивања теста
- Побољшање процеса објављивања теста:
- Управљање и контрола садржаја издања теста
- Пример предлошка извештаја о издању:
- Закључак:
- Препоручено читање
Процес објављивања теста
Табела у наставку даје преглед процеса пуштања у тест са три универзалне фазе као што су Улаз, Процес и Излаз.
ширина прва претрага ц ++ стабло
УЛАЗНИ | ПРОЦЕС | ИЗЛАЗ |
---|---|---|
7 | Контролна листа за преглед кода је ажурирана и доступна у ВСС-у? | |
Претходни процес Развој | Процес започиње са • Инсталација објављеног софтвера на серверу за тестирање | Следећи процес је потребан • Софтвер који је прошао тестирање дима / разума |
Референца информација / докумената • Документ о корисничким захтевима • Спецификације софтверских захтева • Јединствени план испитивања • Стандарди кодирања • Контролна листа за преглед кода • План развоја • План осигурања квалитета • Расподела задатака • Радни пакет • Распоред пројекта • Пројектни план • План управљања конфигурацијом • План управљања ризиком. | Подпроцеси • Припрема тест случајева за све јединице • Развој и јединствено тестирање • Руковање поступцима неусклађености • Имплементација плана управљања конфигурацијом. • Спровођење плана управљања ризиком • Праћење напретка пројекта • Исправљање грешака и прегледи | Интерне потребе купаца • Израда софтвера са бројем верзије • Извештај о издању • Случајеви за тестирање / документ за Суите Суите • Планирање извршења теста • Матрица сљедивости • Тест подаци |
Провера улазног улаза • Пројектна документација се прегледава и одобрава? • Стандарди кодирања, контролна листа за преглед кодова доступни су за референцу? • Додељен задатак и ажуриран радни пакет? • Функционална спецификација, план развоја и план квалитета су прегледани и одобрени? • План управљања ризиком садржи ублажавање и непредвиђене случајеве да би се бавио ризиком? • Учинковитост пројектног распореда за испоруку производа на време? | Спецификација процеса • Случајеви јединствених тестова треба да се састоје од свих критеријума за улаз и излаз • Придржавање кода са стандардима кодирања • НЦП треба поступати у складу са Смерницама • Кораци управљања конфигурацијом треба да се придржавају плана управљања конфигурацијом • Управљање ризиком треба да се придржава Плана управљања ризиком • Испитивање дима пролази све главне карактеристике и функционалности | Потребе спољних купаца • Софтвер без грешака |
Процеси подршке • Додјела људи / хардвера / софтвера / ресурса • Одржавање квара хардвера • Обука за чланове тима | Процес се завршава • Извршење испитивања дима / разума на издатој згради | Параметри ефикасности • Свака јединица треба да прође први круг тестирања • Задаци које треба извршити према распореду пројеката • Тест пушења треба проћи пре објављивања • Тестирање тимске страсти за тестирање софтвера |
Сваки тим за тестирање треба да креира јединствен Контролна листа за издање софтвера, према домену и платформи софтвера и методологији управљања пројектима (попут Агиле Сцрум итд.) и према оквиру за ручно / аутоматизовано тестирање, да прихвате објављену верзију, пре почетка извођења теста, ради уштеде времена и труда.
Ово је један од најважнијих параметара ефикасности у фази пуштања у тест.
Побољшање процеса објављивања теста:
1) Прегледајте извештај о издању за нову функционалност, прилагођавање / модификовање постојеће функционалности, исправке грешака из претходне верзије, која ће одлучити да започне са извршавањем тестирања дима или испитивања здравственог стања или њихове комбинације.
два) Прегледајте исправку Испитивање докумената према новој функционалности и исправкама грешака, ако већ нису ажуриране. Обично, током животног циклуса развоја софтвера, тим докумената ажурира ове документе на основу редовних недељних састанака за преглед пројеката.
3) Прегледајте спремиште за конфигурацију софтвера се ажурира за број верзије, број верзије, означава или коментарише именом издања према стандардима дефинисаним у пројектном плану. Такође, осигурајте да је изградња успешно компајлирана и инсталирана на серверу за тестирање.
4) Закажите састанак за брзи преглед пројекта након објављивања да разговарају о предностима и недостацима објављене верзије, познатим грешкама и критичној функционалности итд., како би се избегле било какве погрешне комуникације и прегледали сви важни захтеви клијента. Строго избегавајте било какву усмену комуникацију између развојних и испитних тимова, јер она у великој мери утиче на квалитет издања софтвера.
5) Уверите се да је алат за праћење грешака правилно конфигурисан , за додељени испитни тим и развојни тим пројекта, бројеве израде и издавања софтвера, као и модуле / функционалност софтвера, који ће помоћи у ефикасном пријављивању грешака. Ако није, треба да буде прослеђен руководиоцу пројекта или менаџеру теста по принципу високог приоритета.
6) Вратите Изградњу развојном тиму без икаквих компромиса, ако израда не успе у тестирању дима или исправности. Строго, испитивање се не би требало наставити када систем закаже у тестирању дима. Ово ће уштедети пуно времена и труда и побољшати квалитет софтвера објављеног у следећим издањима.
7) Закажите објављивање пројекта за 1стДан у недељи што ће помоћи менаџеру теста да планира предстојећи циклус тестирања на основу стабилности израде, а такође и да менаџеру пројекта пошаље брзи извештај о тестирању који ће унапред ескалирати квалитет софтвера. Ако развојни тим закаже пуштање пројекта у петак, викенд се може искористити за било какве клизање, као и за све проблеме у вези са градњом у ручном или аутоматизованом оквиру за изградњу.
8) Осигурајте да су тестери правилно обучени на домену што ће помоћи испитном тиму да се придржава распореда испитивања и прикупи време за следећу рунду тестирања. Такође, тим за тестирање треба да буде обучен и да буде изложен потребној технологији попут скриптирања и СКЛ-а ако пројекат захтева бели бокс.
9) Избегавајте доделу тестера у више пројеката јер у великој мери утиче на квалитет извршења теста у реалном времену. У пракси чак и искусни тестери превиђају карактеристике и функционалност, као и прескачу тест случајеве претпостављајући да неки тест случајеви никада не пропадну, када су преоптерећени послом или додељени на више пројеката са роковима.
10) Цените испитни тим да има страст јер тестери не би требало да раде за „Дан“ или да коментаришу „Назовите га даном“. Када софтвер има више модула, а функционалиста је потпуно или делимично интегрисан или међусобно повезан, тестери би требали имати страст за писање / извршавање тест случајева са великом покривеношћу и матрицом сљедивости, циљајући квалитет коначног софтвера / производа. Јер чак и козметичко питање представља „грешку“ и рачуна се као „1 грешка“.
Једанаест) Уверите се да је инсталација софтвера лака и јасна јер помаже тиму за тестирање да поново инсталира софтвер по потреби, уместо да чека да менаџер развоја или менаџер инсталације уради исти посао, што ће непотребно убити доступно време тестирања. На пример, иако је инсталација заснована на Виндовсима једноставна, али када укључује више веб сервера и мреже широког подручја у вишеслојном тестном окружењу, тестерима ће требати сати да инсталирају софтвер. Ако је покрива тестирање софтвера и инсталацију, деинсталацију , закрпе или ажурирања софтвера, већа је вероватноћа да ће се о процесу извршавања тест случајева детаљно разговарати са тест тимом.
12) Уверите се да су аутоматизовани алати доступни са лиценцом за ан оквир за испитивање аутоматизације . Извршење тест случајева у аутоматизованом оквиру је лако у поређењу са сценаријем ручног тестирања, под условом да су аутоматизовани алати правилно конфигурисани и лиценцирани за више корисника. Нарочито, када план тестирања укључује тестирање перформанси и оптерећења, осим редовног извршавања тестног случаја и регресијског тестирања, тестери би требало да покривају извршавање тест случајева у више окружења као што су више сервера, више прегледача, више корисника итд.
13) Уверите се да су Гхостед Мацхинес постављени за тестирање пре започетог извршења теста. Машине са духовима су машине са различитим окружењем за тестирање. На пример, софтвер веб апликација може се планирати за тестирање у више окружења као што су Виндовс 7 и Аццесс ДБ или Виндовс 2008 и СКЛ Сервер или Виндовс 8 & Орацле или Маинфраме & ДБ2 итд., Са свим прегледачима попут Цхроме-а, Фирефок-а, Интернет Екплорер-а , Сафари итд., Неко „системско тестирање“ чак захтева потпуно форматирање чврстог диска и инсталирање новог софтвера или ажурирање постојећег софтвера закрпама и исправкама итд.
14) Избегавајте примену нових функција / захтев за промену заустављањем извођења теста и поновним пуштањем софтвера за поновно навођење фазе тестирања. Ово је врло лоша пракса у многим софтверским организацијама према пословним захтевима да би се задовољили спољни купци или бар да би се задовољили захтеви управног одбора или понекад продајних / маркетиншких тимова. Иако се захтеви купаца за промену увек подстичу у „агилном“ пројектном окружењу, то треба правилно планирати и применити пре објављивања софтвера тиму за тестирање.
Управљање и контрола садржаја издања теста
Управљање и контрола садржаја издања теста је најважније за било који ИТ софтвер или чак за било које софтверско окружење које није ИТ, а које ће бити приказане на доњој слици.
- Менаџери пројеката и / или управљачки одбор пројекта зависе од ауторитета матрице организације, одговоран је за одабир садржаја за свако издање.
- Када се грешке и / или нове функције и захтев купаца за променом идентификују и одобре, имплементираће их развојни тим који би требало да буде представљен заинтересованим странама пре почетка развоја / имплементације.
- На основу спроведеног коначног издања, тим за тестирање ће ажурирати повезане документе и припремити се за тестирање у складу с тим.
- Тим за тестирање започиње тестирање дима / разума у складу са дефинисаним захтевима у извештају о издању.
- Након што Санити прође, тим за тестирање започиње извршење теста према распореду и додељеним задацима, на пример, функционално тестирање, нефункционално тестирање, безбедносно тестирање, системско тестирање, испитивање перформанси, оптерећење, корисничко тестирање итд.
- Када се заврши прва рунда циклуса тестирања, извештаји о тестовима биће послати свим заинтересованим странама и менаџеру развојног тима да планирају следећу итерацију извршења теста.
- У зависности од статуса извештаја о испитивању и тежине и сложености грешака, планираће се комплетан циклус другог круга извршавања теста или регресијског тестирања заједно са корисничким тестирањем прихватања.
- Након завршетка планираних циклуса извршавања теста, извештаји о тестовима биће послати свим заинтересованим странама у пројекту за усвојене / неуспеле / пропуштене функције, функционалност и исправке грешака.
Пример предлошка извештаја о издању:
Белешка : Пример узорка МС Ворд за извештај о издању такође је доступан за преузимање у наставку.
Пронађите испод „ Пример извештаја о објављивању ”Који покрива главне аспекте процеса издавања што професионални живот целог пројектног тима чини много срећнијим него икад пре.
ГПСНавигатион_Релеасе_Репорт_Вер_1.0.7_Релеасе_14.0_Буилд_105.25.03
#1 Обим
ГПС навигација за компанију КСИЗ Цомпани Лимитед пушта се на интерно тестирање. Објављена верзија је 1.0.7, број издања је 14.0 и број верзије 105.25.03. Ово издање софтвера укључује нове функције и главне исправке грешака из претходног издања. Тестирање дима пролази се из развојне фазе, али пре него што се иде на регресијско тестирање потребан је Смоке & Санити.
# 2) Референце
ГПСНавигатион_УРД_1.0.12, ГПСНавигатион_ФФД_2.17, ГПСНавигатион_БусинессУсеЦасес_1.23.10, ГПСНавигатион_ТестПлан_1.44, ГПСНавигатион_ТестСуитес_2.10, ГПСНавигатион_УнитТестинг_23.3
# 3) Опис издања
Ово издање је контролисано издање ГПС навигације и садржи следеће функције и функције.
Функције означене са * су нове у овом издању.
Следеће функције нису примењене у овом издању.
1. Модул 1
1.1 Карактеристика 1
1.1.1 Функционалност 1
# 4) Управљање конфигурацијом
Висуал Соурце Сафе користимо као алат за управљање конфигурацијом. Изградња је доступна на следећој путањи.
Интерна веза: хттп://234.23.45.111/интерналбуилд/гпснавигатион/релеасе1.0.13
Спољна веза: хттпс: // 234.23.45.111/ектерналбуилд/гпснавигатион/релеасе1.0.13
# 5) Упутства и кораци за инсталацију
Дајте детаљне информације о инсталацији верзије КА / тиму за тестирање.
# 6) Отклоњени проблеми / грешке
Статус грешака се ажурира у систему за праћење недостатака.
# 7) Проблеми / грешке које треба отклонити
# 8) Испоруке
# 9) Познате грешке / проблеми
# 10) Листа за проверу издања
Да не / | Опис | И / Н |
---|---|---|
1 | Да ли су све датотеке проверене у програму Висуал Соурце Сафе? | |
два | Да ли је налепница стављена у одговарајућу фасциклу у ВСС према интерним стандардима? | |
3 | Да ли се издање може идентификовати као „спољно“ / „унутрашње“ издање у ВСС-у? | |
4 | Да ли је у коментарима верзија поменута у ВСС-у? | |
5 | Да ли је у коментарима поменут кратки опис у ВСС? | |
6 | Код је прегледан, а проблеми са прегледом кода пријављени у Цлеар Куест? | |
8 | Јединствени тест документ је припремљен и прегледан? | |
9 | Извршени јединични тест случајеви и ажурирани резултати за статус? | |
10 | Ажурирани документ јединице примера је доступан у ВСС-у? | |
Једанаест | Сви проблеми са Цлеар Куест-ом за ово издање су решени / затворени? | |
12 | Сви задаци радног пакета завршени и ажурирани у ВСС-у? | |
13 | Да ли је тестирање дима завршено и положено? |
=> Преузимање: Кликните овде да бисте преузели узорак предлошка извештаја о издању у МС Ворд формату.
Закључак:
Како континуирано побољшавати процес објављивања теста
Савет бр. 1) Основајте инжењерски тим за издања који ће се побринути за критичне факторе одржавања издања и израде софтвера и одговоран за централизоване системе за управљање конфигурацијом софтвера.
Савет бр. 2) Мотивишите и цените пројектне тимове за праћење процеса укључених у животни циклус развоја софтвера, животни циклус развоја производа и животни циклус тестирања софтвера. Можемо дефинисати процес, али док га не прате људи који су укључени, нема користи од дефинисања процеса.
Савет бр. 3) Процените напор на тестирању на основу искустава и претходне историје. Писање тест случајева се потпуно разликује од извршавања истих. Тестер би требало да разуме шта да тестира, како да тестира и када да тестира, у противном напори уложени у циклус тестирања пропадају, иако се десило више кругова циклуса тестирања.
Савет бр. 4) Коначно, ако је могуће и изводљиво, аутоматизујте фазу тестирања користећи неке универзално прихваћене алате за тестирање. Коришћење аутоматизованих алата за израду и аутоматизованих алата за тестирање смањује напоре тестирања за више од 50% побољшавајући квалитет софтвера и осигуравајући 100% квалитет ако је оквир за аутоматизацију правилно дизајниран.
Савет бр. 5) На крају, али не најмање важно, издање теста није само посао, то је уметност омогућавања лаког и угоднијег живота свих заинтересованих страна у пројекту.
О аутору: Балу А. је искусни техно-функционални ИТ професионалац са преко две деценије искуства у ИТ софтверу и деценијом искуства у управљању пројектима и тестовима, испоручујући пословне апликације и решења за мобилност у различитим доменима користећи Мицрософт, Орацле, Јава и Мобиле технологије. У основи је вођа са страшћу да промовише људе да постану вође са правим ставом и воли да ради у окружењу оријентисаном на процес и верује да процес побољшава ефикасност, квалитет и продуктивност запослених.
Уследећи водич, научићемо - Како Побољшати ефикасност тест случајева.
Јавите нам своје мисли / упите у коментарима испод.
Имајте издање софтвера према процесу!
Комплетно тестирање према распореду уз велику продуктивност и напоре !!
Покушајте да постигнете испоруку софтвера без гаранција квалитета !!!
Ако вам се свиђа овај чланак, размислите о подели са пријатељима!
Препоручено читање
- Курс за тестирање софтвера: Који институт за тестирање софтвера да се придружим?
- Најбољи алати за тестирање софтвера 2021. [Алати за аутоматизацију КА теста]
- Посао за КА помоћника за тестирање софтвера
- Шта је тестирање мајмуна у тестирању софтвера?
- Одабир тестирања софтвера за вашу каријеру
- Тестирање софтвера Посао писца техничког садржаја Посао слободњака
- Узорак извештаја о грешкама
- Практично тестирање софтверског тока КА процеса (услови за објављивање)