Мени

6 основних вештина које би сваки тестер (углавном свежији) требало да има

6 basic skills that every tester should have

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

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

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

образац документа стратегије тестирања за агилну методологију

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

Ово је чланак који ће приказати процес осигурања квалитета какав се прати у већини компанија и пружиће разјашњења за нове тестере о тестирању.

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

основне вештине тестирања

Почнимо.

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

# 1. Документација

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

Такође, уверите се да видите вредност процеса документације. Предности су бројне - помажу вам да пратите промене захтева, пратите кораке теста, пријавите свој рад итд.

Препоручено читање=> Зашто је документација важна у тестирању софтвера

# 2. Припрема теста

Од свих доступних докумената, следеће се не може занемарити. Они се такође називају испоручивим документима и повезују разумевање клијента, програмера и тестера.

а) План испитивања: Уцртава ток испитивања од почетка до краја .

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

Неки тимови имају више нивоа планова испитивања: Мастер план и фазни план.

План испитивања мора да садржи:

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

Такође прочитајте=>

б) Сценарији теста:

Један ред упућује на „шта тестирати“ на основу сваког захтева и обично се документује и прати кроз табеле.

Већина њих садржи:

  • Назив модула / компоненте / функције (пријава, админ, регистрација итд.)
  • ИД сценарија је за референцу (Нпр .: ТС_Логин_001)
  • Опис сценарија - „Шта тестирати“ Нпр .: Потврдите ако пријава омогућава корисницима са важећим акредитивима да се успешно пријаве
  • Важност сценарија - Давање приоритета у случају недостатка времена - Високо / Средње / Ниско
  • ИД захтева - за следљивост

Додатна литература=>

ц) Тест случајеви:

Тачни тест примери дају тачне резултате испитивања. Табеле су и даље популаран медиј за писање тестова, посебно за почетнике, иако неке компаније прилагођавају алате за управљање тестовима. Основа за писање тест случајева је документ СРС / ФРД / Рек. Али, то није често довољно, па ћете морати да користите много претпоставки и дискусија са тимовима БА / Дев.

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

За више информација о овоме проверите:

Неки од уобичајених атрибута које имају сви тестови су:

  • ИД сценарија - преузето из документа о тестном сценарију
  • ИД тест случаја - за јединствену идентификацију и праћење. Нпр .: ТЦ_логин_001
  • Опис теста - Кратко објашњење тестираног стања теста
  • Кораци за извршење - Детаљна упутства корак по корак о начину тестирања
  • Подаци о испитивању - Подаци достављени у кораке испитивања
  • Очекивани резултат - Исход очекиван
  • Стварни резултат - Одговор АУТ-а приликом покретања теста
  • Статус - успешно / неуспешно / нема покретања / непотпуно / блокирано - описује резултат теста
  • Коментари - За додатне детаље
  • Извршио - Тестерово име
  • Датум извршења - Датум покретања теста
  • ИД квара - квар пријављен на тест случају, у случају неуспеха теста
  • Детаљи о конфигурацији - ОС, прегледач, платформа, подаци о уређају (опционално)

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

# 3. Процес тестирања - Које тестове обавити?

Постоји огроман број типова испитивања, али не могу сви да се изврше на том АУТ. Време, буџет, природа посла, природа апликације и интерес клијента кључни су играчи у избору тестова који ће се урадити на апликацији.

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

# 4. Испитивање у фази делимичног развоја

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

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

# 5. Документ о пријави грешке

Практично, ово је најкритичнији КА документ који ћете икада направити.

Следе поља која мора имати добар извештај о грешкама:

  • ИД квара - Обично серијски број
  • Опис квара - Једно редно објашњење проблема
  • Локација - модул / подручје АУТ-а где је пронађен проблем
  • Број верзије - верзија верзије и кода.
  • Кораци за репродукцију - Листа корака који вас воде до проблема
  • Озбиљност - поставите ниво за описивање озбиљности проблема - низак, средњи, висок, блокатор итд.
  • Приоритет - програмери постављају да одреде редослед којим ће квар бити отклоњен (П1, П2, П3, итд. П1 - највећи)
  • Додијељено - Власнику квара у том тренутку
  • Пријавио - Тестер-ово име
  • Статус - различит статус који представља фазу животног циклуса грешке
    • Ново - Пронађена је грешка и управо је пријављена
    • Отворено - потврђено од стране КА вође
    • Додељено - послато водичу за програмере ради додељивања одговарајућем програмеру
    • У току / Ворк ин Прогресс - Дев је почео да ради на томе
    • Поправљено / решено - програмер је завршио са радом на томе
    • Верификовано / затворено - КА тим је поново тестирао и открио је грешку
    • Поновно тестирање - КА тим се не слаже са резолуцијом компаније Дев и даље напредује у грешци за прераду
    • Дупликат - Слична грешка већ постоји
    • Одложено - важећа грешка, али ће бити исправљена у каснијим издањима
    • Неважеће - Није грешка или се не може репродуковати или нема довољно информација

Додатна литература=>

# 6. Процес одјаве

Одјавити се а слање коначне документације је задатак КА водитеља / менаџера. Међутим, тим мора да достави горенаведене документе (сценарио тестирања, тест случаја и документ дневника квара) на коначне прегледе и ревизију.

Обавезно прочитајте лектуре и пошаљите коначне верзије.

Такође прочитајте=>

Закључак

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

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

Све најбоље за вашу каријеру!

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

^