Увод у рад софтверског тестера
Шта вам прво пада на памет кад размишљате о послу за тестирање софтвера? Дело кодирања? Или професија која је врло једноставна јер вам пружа могућности да пронађете грешке у раду других (проналажење грешака када је у свима нама најлакши задатак)? Или на то мислите као на професију која се бави провером исправности производа? Све ове мисли су тачне и свакодневне су активности за тестирање софтверског софтвера. Међутим, тестирање софтвера није ограничено само на ове активности.
Разумевање апликације
Апликација може бити из било којег домена - Здравство, осигурање, финансије, итд. Учење домене апликације веома је важно за било који софтверски рад да бисте отворили врата размишљању из различитих углова и различитих корисничких перспектива током тестирања апликације. Откривање и потврђивање очигледних и не тако очигледних путева примене увек је главно очекивање од овога. Посједовање детаљног знања о апликацији помаже ефикасном валидацији производа у исто време, испитивач може постати предност пројекту где се он / она сматра једним од основних извора знања у вези са понашањем производа.
Иако је учење домена и функционалности процес који је у току, било који други важан фактор је знање о процесу тестирања.
Процес тестирања
Процес тестирања може варирати од компаније до компаније или чак од једног до другог пројекта. Данас имамо разне моделе за развој софтвера као што су В модел, Прототипинг модел или сасвим другачију методологију попут Агиле приступа развоју софтвера. Са променом развојног модела, такође варира и приступ тестирању. Рад у В моделу имаће добро дефинисане процесе, док се очекује да се овај рад у агилној методологији тестира у стално променљивим условима.
Посао још увек није у реду са прихватљивим познавањем домена и разумевањем процеса тестирања, следећи изазов који долази са животом је учење различитих алата.
Алати
Алат подразумева алате за управљање тестовима, алате за грешку грешака, алате за управљање базама података и тако даље.
Са разним софтвером за евидентирање кварова, који се користе квалитетом и алатима, неким отвореним кодом, а неки лиценцираним, увек је предност имати знање о више алата. Помаже му да лако пребаци пројекте или тимове пратећи различите алате. Уз адекватно познавање домене, процеса и алата, живот софтверског тестера је већи што чини његове радне дане изазовним и узбудљивим. Сарадња унутар тимова један је од важних фактора успеха било ког пројекта, а за ефикасну сарадњу комуникација игра веома важну улогу.
Препоручени курсеви
- Комплетан Ј2ЕЕ свеобухватни курс
- Обука за програмирање на мрежи Р
- Иди на курс програмирања
- Обука за онлине сертификацију у Хаскелл програму
Комуникација
Комуникација игра веома важну улогу за софтвер који се њеног квалитета бави од почетних фаза развоја софтвера, чланови тима за тестирање су укључени (као најбоља пракса) у расправу о захтевима, испитивање пословних аналитичара у случају било каквих упита или недостатака у захтеву. Потрошач који има ефикасне комуникацијске вештине може ефикасно да комуницира о ризицима, може ефикасно да комуницира са развојним тимом и може ефикасно да комуницира о резултатима испитивања и извештајима са тестирања.
Планирање софтверског тестера
Као што име каже, планирање испитивања је фаза у којој се врши припрема за тестирање. Припрема за тестер ће укључивати различите врсте активности које полагач ради како би се ефикасно пријавила. Ово ће вам помоћи у потврђивању апликације и ефикасном откривању недостатака у апликацији. Да би се започело са планирањем, тестирање пролази кроз захтеве да разуме очекивања.
1. Услови
Захтеви могу бити постављени тиму за тестирање у облику жичаних оквира, плоча с причама, екцел листова. Сврха свих ових докумената је да на ефикасан и једноставан начин представе захтеве клијента. Документ са жичним оквиром није ништа друго него документ који може бити у облику презентације ПоверПоинта који приказује захтеве клијента. На истим линијама плоче са сликама обично приказују тражени изглед / дизајн екрана. Данас су на тржишту доступни различити алати који се могу користити за припрему потребних докумената. Израда потребних докумената је главна одговорност пословног аналитичара. Очекује се да дегустација темељно разуме захтеве. Да би тесте и програмери правилно разумели захтеве, пословни аналитичари држе форум отворен да би га сви поставили и добили одговоре на било који од захтева. Платформа за дискусију и комуникацију о отвореним питањима и упитима варира од пројекта до пројекта. То би могао бити ланац е-порука или конференцијски позив или чак спремиште заједничког диска које се одржава како би се пратила сва отворена питања и њихови одговори како их пружа пословни аналитичар.
Јасна комуникација и запис комуникације играју врло важну улогу као доказ. Мала претпоставка у захтеву понекад може довести до већих оштећења производа. У свакој фази се препоручује тестирање квалитета софтвера како би се комуникација одржавала чистом. Софтвер Тестер Ворк комуникација може бити с пословним аналитичарима или чак у оквиру тима. Јасна комуникација помаже да се избегну претпоставке током планирања и извршења. У исто време, препоручује се евиденција комуникације (по могућности комуникација путем е-поште). Имати писану комуникацију о захтевима у захтевима помаже у каснијим фазама извођења теста у којима функционалност можда није развијена како је потврђено у снимљеној комуникацији.
2. Сценариј
Једном када се захтеви разумеју, испитивач започиње документовање сценарија у документу Тест Сценарио. Сценариј као што име сугерира је проток функционалности који корисник слиједи како би испунио задатак.
Примери сценарија -
- Корисник треба да буде у могућности да се успешно пријави.
- Корисник треба да буде у могућности да резервише карте у систему.
- Корисник треба да може да откаже карте у систему.
- Корисник би требао бити у могућности да прегледа / ажурира детаље о профилу.
Ово су логични задаци које корисник извршава у систему. Ови логички задаци када се групирају заједно помажу да се бележе сви могући сценарији које корисник очекује. Ови сценарији се обично документују у Екцел листовима или се понекад користе неки алати. Потврда успијева извући све такве сценарије из докумената о захтјеву. Документ који садржи такве сценарије назива се Тест Сценарио Доцумент (или негде као Доцумент Сценарио Хигх-Левел). Овај документ служи као улазни документ за израду тест случајева.
3. Случај
Овај случај је детаљнија верзија радног сценарија софтвера Тестер где се сценарио разбија на детаљније кораке које ће корисник заиста изводити током коришћења апликације. Једноставни пример заснован на горе поменутим сценаријима је:
Сценариј - Корисник треба да буде у могућности да се успешно пријави.
Тест случајева:
- Проверите да ли корисник може уписати исправно корисничко име.
- Проверите да ли корисник може унети лозинку.
- Када унесете исправно корисничко име и лозинку, потврдите да када се кликне дугме за пријаву корисник може успешно да се пријави.
Таква листа ових случајева може да укључи провјеру ваљаности сваког поља, провјеру негативних сценарија и тако даље.
Испод је неколико додатних примера ових случајева -
- Проверите да ли корисничко име када није унесено, систем баца одговарајућу грешку.
- Проверите да ли је лозинка када није унета, систем ће открити одговарајућу грешку.
- Проверите да су корисничко име и лозинка када нису унети, систем ће открити одговарајућу грешку.
- Проверите да ли систем уноси погрешну лозинку и шаље одговарајућу поруку о грешци.
- Проверите да ли уносом погрешног корисничког имена систем шаље одговарајућу поруку о грешци.
4. Матрица следљивости захтева (РТМ)
Матрица сљедивости захтјева, као што име сугерира, помаже да се докаже да се провјери и укључи обухватност захтјева које пружа Бусинесс у тестне документе попут сценарија и тест случајева.
Као најбоља пракса, ово је посебан документ који приказује пресликавање броја захтева са оним сценаријем / случајевима који укључују тај захтев.
Овај документ се не може користити у свим врстама пројеката, али када се користи, помаже на снажан начин да се прате сценарији високог нивоа који се мапирају у складу са захтевима. Означава покривеност и може се користити за провјеру присуства барем једног случаја у односу на сваки захтјев. Стварање и одржавање РТМ документа сматра се најбољом праксом, али нису све врсте пројеката (попут Агиле) коришћење софтвера доказују радни документ. Када се захтеви веома често мењају, одржавање овог документа могло би се чути. Да би се избегле ове претпоставке и истовремено се пронашао начин да се прате захтеви, неки пројекти укључују део сљедивости у радни случај софтвера Тестер или у његов документ са сценаријем.
Важан аспект је имати начин да се прате сценарији / случајеви до захтева и обрнуто. Добро документовани захтеви олакшавају задатак Провер-у да креира и одржава ове документе. Двосмислени захтеви, захтеви који се стално мењају чине живот неповољнијим и могу довести до неусаглашених докумената који могу да се испоруче, што резултира пропуштањем неке потврде, а самим тим и недостатком у крајњем производу.
До сад је путовање за тестера планирало и припремало се за тестирање. Како је припрема за рат део рата, овде важи исто. Што су ови документи сажетији, лакши је доказима да потврде функционалност и открију скоро све недостатке. Следећа фаза путовања тестера је Извршење.
Извођење софтверског тестера ради
Ово је фаза у којој се сви горе наведени документи стављају у употребу. За креирање сценарија коришћени су захтеви, а за израду сценарија коришћен је сценариј. овај документ случаја је документ који није довољан за почетак провере апликације. Провер започиње потврђивање апликације извршавањем корака из овог документа случаја. Вишеструки случајеви могу се користити за потврђивање једног сценарија или чак један тест случај може одговарати једном сценарију теста. Све зависи од сложености сценарија или понекад стандарда који се следи у испитном тиму. Према томе, један документ случаја може садржати 20-50 испитних случајева или може имати 100-120 тест случајева. Ови бројеви су само у сврху објашњења, могу различито варирати од пројекта до пројекта. Исход ове фазе су тестни недостаци. Број валидних недостатака прикупљених у овој фази даје добру представу о стабилности примене, квалитети тестирања, квалитети израде и многим таквим факторима који директно утичу на производ. Ова фаза је најважнија фаза јер испитивач успева да покрије све испитне случајеве (валидирање готово свих потребних корисничких стаза) и истовремено покрене што већи број валидних оштећења. Све припреме, комуникационе вештине, упити за које се тражи да посао дође у овој фази тестирања.
Дефецтс оф Софтваре тестер функционира
Током извођења овог случаја, свако понашање које није једнако очекиваном резултату поставља се као дефект. Сваки тест случај садржи Опис, очекивани резултат и ступац за стварни резултат. Док овај документ о планирању софтвера за тестирање софтвера садржи опис и очекиване резултате и празну колону за стварне резултате. Приликом извођења тестних случајева, испитивач треба да попуни стварни ступац резултата. Истовремено, ако стварна вредност није једнака очекиваном резултату, грешка се бележи. Дневник грешке једноставно не значи информисање програмера о проблему. То је опет формални поступак који се обично изводи уз помоћ алата. Тренутно на тржишту постоје разни алати, неки отвореног кода, а неки лиценцирани. Сваки алат за евидентирање оштећења има следећа поља -
- Назив пројекта / издања
- Резиме дефеката
- Опис детаља о дефекту
- Дефецт Северити
- Приоритет дефекта
- Фаза је пронађена
- Додељено
- Прилози
Као што видимо, сврха свих ових поља је да се пронађу формалне детаљне информације о проблему. Ово помаже програмерима да репродукују квар у свом окружењу и да га исправе. Испод је кратак опис свих ових поља -
- Назив пројекта / издања - Име издања на коме је откривен квар, обично пројекат има више издања и исти пројекат може имати више подпројеката. Ово поље помаже да покренете проблем за одређено издање.
- Сажетак Дефекта - кратак опис пронађеног недостатка у једном слоју.
- Опис детаља о дефекту - Ово је детаљан опис оштећења, треба да садржи детаље као што је окружење у коме је квар пронађен, и коришћени подаци испитивања, стварни резултати очекују резултат и све додатне информације које додају вредније информације заинтересованим странама да разумеју дефект.
- Озбиљност дефекта - означава колико је оштећење озбиљно. Обично има вредности сличне критичним, високим, средњим, малим или нумеричким вредностима попут 4, 3, 2, 1.
- Приоритет дефекта - означава колико је хитно исправити квар.
- Фаза је пронађена - Како постоји много фаза када се грешка може евидентирати, Фаза испитивања јединице, СИТ (тестирање системске интеграције), УАТ (тестирање прихватања корисника) или чак производна фаза.
- Додељено - Име програмера или развојног водича.
- Прилози - Ово је дало тестирачу могућност да дода снимку екрана на коме је наишао проблем.
Извршење теста и евидентирање грешака је фаза у којој има много изазова са којима се тестер може суочити. Неки од њих ефикасно комуницирају са програмерима. Можемо ли тврдити да је бележење грешке са свим потребним информацијама које нису довољне да програмери разумеју квар?
У неким случајевима то захтева додатно објашњење / расправу са програмерима. Постоје случајеви да испитивач наиђе на неочекивано понашање за које можда није сигуран да ли је у питању квар. Овим околностима се обично суочавају они који су нови у тиму, који имају ограничено знање о домену или имају двосмисленост у погледу захтева. Па, овде не треба кривити тестера ако постоје кратки рокови и постоје захтеви који се стално мењају и у већини случајева доказују учење о домену док заправо планирају и извршавају тестне случајеве. Као што видимо да пут тестера није лак као што се перципира. Захтијева стални став о учењу, добре комуникацијске вјештине, добре сурадничке вјештине и спремност да се прилагодите увјетима у којима постоје промјене у доменама, алатима, процесима који се користе. Док смо разговарали о путовању ручних тестера, целокупни процес се односи и на тестере за аутоматизацију. С друге стране, аутоматизација има значајне промене у процесу пошто обим тестирања и планирања, извршење значајно варира.
Узимајући у обзир путовање доље описаног горе, можемо ли ипак рећи да је посао квалитета софтверског тестера лакши него код програмера?
Може се рећи да ће, више него упоређивање улога програмера тестер в / с, бити корисније водити дискусију о томе како сарадња двоје може довести до великог успеха производа у целини. Понекад заборављамо да је посао тестера да пронађе проблеме у апликацији, а не да указује на грешке програмера. Када заборавимо на саму идеју свог посла, то понекад доводи до непотребне дискусије. Међутим, примећено је да постоје подједнако добри тестирање, развојни тимови где сви разумију да је крајња сврха да апликација делује како се и очекивало. Надајмо се да ће сви гледати на позитивну страну посла тестирања као на улогу која помаже у чишћењу производа, а не као на ону која управо открива грешке!
Препоручени чланци
Ово је водич за откривање и потврђивање очигледних и не тако очигледних путева примене увек је примарно очекивање рада теста софтвера. Ово су следећа спољна веза везана за рад софтверског тестера.
- Неисправан животни циклус у тестирању софтвера
- 6 најневероватнијих питања за испитивање интервјуа са софтвером
- Каријере у тестирању софтвера