Мени

Како се припремити за писање тест случајева (Савети за продуктивност)

how prepare yourself

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

Како се припремити за писање пробних случајева и побољшати продуктивност:

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

Прво, морају се професионално и психолошки припремити за неке од кључних тачака неопходних за све успешне тестере софтвера у ИТ индустрији. Ово ће се третирати као „ Улази ”За тестер пре почетка писања тест случајева.

писање тест случајева

Даље, они треба да разумеју метрике квалитета укључене у пројекат, који се користи као алат за процену перформанси тестера у различитим фазама животног циклуса тестирања. Ово ће се третирати као „ Излази ”За тестер након завршетка писање тест случајева .

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

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

основна питања и одговори на интервју за техничку подршку

Припремите се за писање тест случајева

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

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

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

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

5) Темељито разумите домену апликације .На пример, тестирање веб странице је лакше од тестирања финансијског софтвера развијеног за берзу који истовремено користе хиљаде људи. Једноставна функционалност веб странице може бити разумљива било ком испитивачу, док финансијски услови и функционалности не могу бити разумљиви свим тестерима док и уколико немају одговарајуће образовање или обуку или ако немају искуство домена .

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

6) Захтеви пројекта и врсте испитивања која треба извршити разликују се од пројекта до пројекта. Тестер треба да буде припремљен за било коју врсту тестирања. Не ограничавајте своје могућности својим вештинама и специјалностима. Будите спремни да преузмете одговорности и изазове за писање и извршавање тест случајева за било коју врсту тестирања.

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

7) Утврдите врсте испитивања које треба изводити и вештине потребне за тестирање АУТ. На пример, неки пројекти захтевају само тестирање црне кутије, а неки вештине тестирања беле кутије. Знање „ скриптирање “Или искуство у„ СКЛ ”Или рад са„ означи језик ”Попут ХТМЛ / КСМЛ итд., Или чак системско знање о томе како инсталирати / отклонити проблеме са инсталацијом софтвера, итд. Неки су захтеви специфични за пројекат које морате сами научити или се за исти обучити.

8) Уверите се да тест примери покривају Типови испитивања перформанси, испитивања сигурности и тестирања регресије. На пример, да бисте се пријавили у апликацију помоћу екрана за пријављивање испод:

Ефикасност тест случаја 2

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

9) Преглед тест случаја : Једна од најважнијих и најзапаженијих фаза било ког развоја софтвера и животног циклуса тестирања је „ ПРЕГЛЕД ”. Када пројектни план укључује довољно времена за а поступак прегледа у свакој фази развоја пројекта, најквалитетнији производи и резултати које можемо очекивати исти.

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

Документе за тестне случајеве треба прегледати најмање 3 пута путем:

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

10) Коначно, разумети како проценити и планирати задатке тестирања . Планирајте да радите само предвиђено време у дану. То се може постићи започињањем и довршавањем задатака на време и остављањем дана са плановима за задатке наредног дана.

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

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

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

Метрика квалитета

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

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

Такође, видитедруге корисне метрике испитивања које се користе у фазама тестирања:

=> Важне метрике и мерења софтверског тестирања и Праћење грешака у пројекту, метрике теста и процес одјаве из теста.

1) Просечна ефикасност испитивања

  • Грешке по човеко-месецима напора за тестирање.
  • Израчунато као просек (укупан број грешака током напора на тестирању у људским месецима).
  • Израчунава се након сваког интерног издања, као и након завршетка теста.
  • Ограничење прихватања: требало би да буде мање од 50

2) Просечна густина оштећења купца

  • Грешке које је клијент пријавио након испоруке Вс укупни напори на тестирању у месецима.
  • Израчунато као просек (укупан број грешака након испоруке / напора у тестирању у људским месецима).
  • Израчунава се након екстерног издања и завршетка пројекта.
  • Ограничење прихватања: требало би да буде мање од 1

3) Неуспеси функционалних тестова

  • Број неуспелих функционалних тест случајева / Укупан број извршених функционалних тест случајева.
  • Израчунава се месечно или двонедељно.

4) Грешке са нивоом озбиљности 1

  • Укупан број грешака идентификованих са нивоом озбиљности 1 (блокатор).
  • Тестирање софтвера није могуће наставити због проблема са блокадом.
  • Израчунава се недељно.

5) Грешке са нивоом озбиљности 2

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

6) Грешке са нивоом озбиљности 3

  • Укупан број грешака идентификованих са нивоом озбиљности 3 (мање грешке).
  • Тестирање се може наставити јер је идентификована грешка мања и не зауставља тестирање.
  • Израчунава се недељно.

7) Грешке са нивоом озбиљности 4

  • Укупан број грешака идентификованих са нивоом озбиљности 4 (козметички проблеми).
  • Тестирање се може завршити без икаквих проблема, јер су идентификоване грешке повезане са козметиком и биће поправљене за следеће издање.
  • Израчунава се недељно.

Извештавање о грешкама

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

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

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

=> Како написати добар извештај о грешци? Савети и Трикови
=> Узорак извештаја о грешкама
=> Зашто је пријављивање грешака уметност коју би требало да научи сваки тестер?
=> Животни циклус буба
=> Узорци извештаја о грешкама за веб и производе

Извештаји о испитивању

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

Испод је један такав једноставан извештај са теста:

Такође прочитајте следеће корисне водиче заефикасно извештавање о тестовима:

=> Водич за писање ефикасног резимеа теста
=> Како паметно пријавити извршење теста (Преузми образац извештаја о статусу)

најбољи софтвер за видео конвертере за Виндовс

победнички

јаиа1

Закључак

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

Дакле, праћење процеса, стандарда, процедура и строго придржавање мерила квалитета са страшћу, може аутоматски донети у вас велику ефикасност тестирања, продуктивност и испитивач квалитета, што ће вам постати навика у професионалном животу.

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

  • Да ли сте прошли кроз функционалне захтеве / корисничке захтеве / документе случаја пословне употребе?
  • Да ли је документ о функционалним захтевима прегледан и исправно ажуриран са коментарима на преглед?
  • Да ли сте добили прототипове екрана за све функције које треба тестирати?
  • Да ли вам је угодно писати тест случајеве који се могу тестирати и пратити кроз читав животни циклус тестирања?
  • Да ли имате потребан скуп вештина и знање домена за тестирање апликације која се тестира?
  • Да ли вам је потребна обука или техничко знање потребно за извршавање тест случајева?
  • Да ли имате распоред писања, прегледа и извршавања тест случајева, који покрива време за припрему квалитетних докумената?
  • Да ли имате вршњаке који ће прегледати ваше тестове и овлашћеног стручњака за предмет за проверу потпуности и покривености карактеристика и функционалности које ће се тестирати?
  • Да ли имате довољно тест случајева за све функционалне захтеве?
  • Да ли имате довољно тест случајева за перформансе, тестирање оптерећења и безбедносно тестирање?
  • Да ли имате довољно тест случајева за инсталацију и регресијско тестирање?
  • Да ли имате контакт особу за ескалацију проблема или пријављивање грешака?
  • Да ли је алат за праћење грешака правилно конфигурисан са потребном дозволом за све?
  • Да ли вам је угодно да пратите све процесе дефинисане планом теста?
  • Да ли сте укључени у све ревизијске састанке и да ли имате прилику да разговарате са развојним или управљачким тимом?
  • Да ли су ваша продуктивност и ефикасност побољшани или за то треба да предузмете неке мере?

Препоручена литература = >> Најбољи курсеви креативног писања на мрежи

Постоји много сличних питања које тестери могу себи поставити за анализу само-побољшања, у зависности од врсте пројекта или организације са којом раде. Најважније је да све ове активности не треба следити само ради праћења процеса, већ да то буду ваше свакодневне навике које се могу остварити кроз СТРАСТ ЗА ТЕСТИРАЊЕ само.

ПРЕВ Туториал |. | СЛЕДЕЋА Лекција

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

^