Мени

Како се носити са лошим захтевима као испитивач

how deal with bad requirements

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

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

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

Након одлуке да се то питање закуца, сви су се разишли. И током ископавања, примећено је да клијент никада није споменуо ништа о двострукости записа у документу са захтевима и зато нико није постављао релевантна питања нити размишљао о томе.

лоши захтеви

Ово је био само пример.

У каријери дугој више од 10 година , Приметио сам много случајева када су пројекти патили због лоших или лоших захтева.

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

Дозволи да објасним -

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

Колико лоши, сиромашни и сукобљени захтеви стварају гњаважу:

# 1) Нема захтева - Ниједан захтев не подразумева претпоставке и нагађања и самим тим нема поверења. Веома је тешко тестирати производ / апликацију без икаквог основног стања. А то резултира са више посла, више грешака од клијента и више патње за пројектом.

  • Како би ти Пријавите проблем о паду система када не постоји дефиниција како треба поступати са понашањем је ли доступна?
  • Како бисте рекли да је време учитавања почетне странице од 100 секунди неприхватљиво када не постоје релевантни захтеви за перформансе?

Више информација о Без захтева и начину решавања ситуације током тестирања можете наћи у раније објављеном чланку - Како тестирати апликацију без захтева?

# 2) Лоши захтеви - Цитат, Знати нешто непотпуно је опасно него уопште не знати , је веома тачно када је реч о решавању лоших захтева.

Тумачење лошег захтева и његово спровођење је велики ризик.

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

# 3) Сукобни захтеви - Тражити од некога да ради две различите ствари истовремено само га збуњује, а систем такође није изузетак.

  • Како бисте тестирали апликацију са наведеним захтевима, као што је приказано у наставку:
    • Апликација увек треба да се отвори на почетној страници.
    • Очекује се да се корисници пријаве за приступ апликацији.
  • Шта бисте одлучили за приоритет када је документ са захтевима као што је доле:
    • Апликација за игре треба да унапреди корисника на следећи ниво ако корисник постигне 1000.
    • Корисник би требало да буде преусмерен на бесплатну страницу претплате када постигне 1000.

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

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

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

Погледајмо могућа решења:

Лоши захтеви и како са њима поступати као са тестером:

Метод # 1)Истражите и научите:

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

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

Метод # 2)Искористите искуство:

Искористите искуство

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

Метод # 3)Погледајте жичане оквире:

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

Опширније => Жичани оквири - треба ли их заиста тестирати? А ако да, како?

Метод # 4)Вршњачка дискусија:

алгоритам сортирања уметања ц ++

Вршњачка дискусија

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

Метод бр. 5)Разјашњење од купца:

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

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

Закључак

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

О аутору: Ову инспиративну поруку написао је члан СТХ тима Бхумика М. Она је вођа пројекта, која има више од 10 година искуства у тестирању софтвера.

Срећно тестирање, као и обично ... .. чекајући своје ставове, коментаре и мишљења.

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

^