Меню

Как да се справим с лоши изисквания като тестер

how deal with bad requirements

Опитайте Нашия Инструмент За Премахване На Проблемите

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

В края на краищата липсата на никаква съответна грешка, когато потребителят се опитва да дублира съществуващия запис и позволяването му да го направи, не беше малка грешка - Това също за застрахователна компания.

След като решиха да засегнат въпроса, всички се разпръснаха. И докато разкопавахме, беше забелязано, че клиентът никога не е споменавал нищо за двойствеността на записите в документа за изисквания и следователно никой не е задавал съответни въпроси и не е мислил за това.

лоши изисквания

Това беше само пример.

В кариера от повече от 10 години , Наблюдавал съм много случаи, при които проекти са страдали поради лоши или лоши изисквания.

Но както се казва, нищо не е перфектно на този свят и ще трябва да се справите с него и да се справяте с проекти, които нямат никакви изисквания или лоши изисквания, е някакъв кошмар.

Нека обясня -

Какво ще научите:

Колко лоши, лоши и противоречиви изисквания създават главоболия:

# 1) Няма изисквания - Никакви изисквания не предполагат предположения и предположения и следователно няма доверие. Много е трудно да се тества продукт / приложение без изходно ниво. И това води до повече работа, повече грешки от клиента и повече страдания за проекта.

  • Как можа подайте сигнал за проблем относно срив на системата, когато няма дефиниция как трябва да се работи с поведението, налице ли е?
  • Как бихте казали, че времето за зареждане от 100 секунди за началната страница е неприемливо, когато няма съответно изискване за производителност?

Повече информация за Няма изисквания и как да се справите със ситуацията при тестване можете да намерите в по-рано публикувана статия - Как да тествате приложение без изисквания?

# 2) Лоши изисквания - Цитатът, Да знаеш нещо непълно е опасно, отколкото да не знаеш изобщо , е много вярно, когато става въпрос за справяне с лошо изискване.

Тълкуването на лошо изискване и прилагането на същото е голям риск.

  • Как бихте потвърдили, че изскачащият прозорец, показващ резултатите от търсенето, е валиден или не, когато единственото споменато изискване беше - резултатите от търсенето трябва да са правилни и не сте сигурни кои критерии трябва да се вземат предвид при търсене.
  • Как бихте тълкували това - Трябва да се приложи забравена парола, за да се улесни потребителят да регенерира / нулира забравената парола. Неизвестно кой работен поток иска клиентът за забравена парола, разработчикът прилага това, което смята за най-добро и конфликтите започват.

# 3) Противоречиви изисквания - Искането някой да направи две различни неща едновременно просто го обърква и системата също не е изключение.

  • Как бихте тествали заявление със споменатите изисквания са както по-долу:
    • Приложението трябва винаги да се отваря на началната страница.
    • Очаква се потребителите да влязат в системата за достъп до приложението.
  • Какво бихте решили приоритета, когато документът за изискванията е както по-долу:
    • Приложението за игри трябва да повиши потребителя до следващо ниво, ако потребителят получи 1000 точки.
    • Потребителят трябва да бъде пренасочен към безплатна страница за абонамент, след като набере 1000.

И ето как лошите, лошите и противоречивите изисквания създават главоболия.

Тъй като е в софтуерната индустрия, това трябва да е част от проекта, тъй като понякога дори клиентът не е сигурен какво точно иска и как да го формулира.

От гледна точка на тестването, въпреки че е трудно да се справим с тези двусмислени или неясни изисквания, не е напълно невъзможно.

Нека разгледаме възможните решения:

Лоши изисквания и как да се справите с тях като тестер:

Метод # 1)Разгледайте и научете:

Проучването на други приложения, научаването за общо очаквано поведение, разбирането на работния поток, мисленето за удобството на потребителя и прилагането на логика е един от начините за справяне със ситуацията. Също, разчитайки на изследователски тестове би било полезно в този вид ситуации, когато изискванията не са ясни.

В повечето случаи е добре да се даде приоритет на потребителското изживяване и удобство, когато изискванията не са ясни.

Метод # 2)Използвайте опит:

Използвайте опит

Домейн опит , цялостното изпитание, проблемите, с които се сблъсквали в миналото, и личните прозрения могат да помогнат за справяне с объркващи ситуации и изисквания.

Метод # 3)Вижте телени рамки:

Wireframes са вид визуално изискване, където можете да намерите малко подробности и тези подробности могат да бъдат много полезни при създаването на очакваната картина на продукта или приложението и помагат за по-добро покриване на аспектите на тестването.

Прочетете още => Wireframes - трябва ли наистина да бъдат тествани? И ако да, как?

Метод # 4)Партньорска дискусия:

функция за сортиране на балончета c ++

Дискусия от партньори

Без значение какво е объркването, ако се обсъди с подходящ куп хора, нещата се изясняват. Всеки носи различен опит, очаквания, поглед на потребителя и анализ и обсъждането на тези лоши изисквания с връстници ще послужи в полза на кристализирането на разбирането и повишаването на самочувствието.

Метод # 5)Изяснение от клиента:

Клиентът е собственик на продукта / приложението и винаги е разумно да се обърнете към него, когато става въпрос за яснота на изискванията. Но не забравяйте, че не е препоръчително да атакувате клиента със 100 въпроса. Преди да направите това, са необходими някои домашни.

Опитайте се да разберете най-добрите налични практики, да разберете предимствата на внедряването и след това да се свържете с клиента с въпрос и възможно решение.

Заключение

И накрая, слабо дефинираните или недефинирани изисквания са част от живота на тестера и ние трябва да ги приемем, но нека се опитаме да бъдем оптимисти и да определим решения за него. В края на краищата ние сме тестери, помагаме на приложенията да останат на път и ги предпазваме от падане. YAY на нас :)

За автора: Тази вдъхновяваща публикация е написана от член на екипа на STH Bhumika M. Тя е ръководител на проекта, като има 10+ години опит в тестването на софтуер.

Приятно тестване, както обикновено ... ..очакваме вашите мнения, коментари и мнения.

Препоръчително четене

^