То ниси ти; Велики део обезбеђења квалитета је локализација дефекта

Велики део КА је локализација дефекта.

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

Почнимо са основама

Локализација је попут играња детектива: „Где и када су ствари пошле наопако?“ Без одговарајуће локализације, дефект може постати врући кромпир који се баца између фронтенда, бацкенда и било ког развојног тима. Време се губи, а потенцијално чак и контекст.

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

Шта је архитектура апликације?

То је начин на који различити делови система раде заједно. У смислу наше метафоре лавиринта, то је како се један део повезује са другим, који пролази где воде.

Разликујем две главне архитектуре: клијент-сервер и бацкенд.

• Архитектура клијент-сервер нам показује како клијент и сервер комуницирају.
• Позадинска архитектура одређује како позадински систем рукује захтевима клијената.

Неколико речи о архитектури клијент-сервер

Генерално постоје два типа:

• Танки клијент
• Дебели клијент

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

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

У дебелим клијентским апликацијама, клијент већину обраде обавља сам: додаје податке у базу података, генерише извештаје, израчунава суме и креира документе. Често се инсталирају локално, али не увек. Примери дебелих клијената укључују игре ван мреже, АутоЦАД и неке верзије 1Ц.

Сада, хајде да истражимо позадинску архитектуру

Два уобичајена приступа су:

• Монолитна
• Микроуслуге

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

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

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

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

Организациона структура и области одговорности

Наслов звучи застрашујуће, али само говори ко шта ради и ко је за који део лавиринта (апликације) одговоран. Замислите да имамо велику компанију: банку, пијацу, службу за доставу хране – само тако. Што је наша апликација већа и сложенија, више људи ради на њој. И што је више људи, то је више потребно да их поделите у тимове, од којих је сваки одговоран за своју област развоја.

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

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

Стављајући све заједно

Мапа у руци, конац је спреман, хајде да заронимо у наш лавиринт и пронађемо извор квара. Хајде да замислимо неколико сценарија.

Сценарио 1

Замислите ово: Тестирамо веб локацију за конверзацијски клуб.

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

Сада, како да схватимо одакле је настао? Нека авантура почне!

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

Сада отварамо дневнике и тражимо обраду захтева или одговора бацкенд-а – ово је наше пређе од магичне лопте. Можемо претраживати евиденције користећи било коју информацију из захтева и одговора, али је боље користити јединствене вредности: захтев киид, ИД из захтева, број телефона и тако даље.

Проналазимо унос и проверавамо: да ли смо информације о класи добили из базе података или од другог сервиса?

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

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

Честитамо! Освојили смо наш први лавиринт: квар је локализован и пријављен.

Сценарио 2

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

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

Време је да откријемо нашу магичну лопту! Идемо на нашу вољену картицу Мрежа у девТоолс-у и видимо шта је пошло по злу: понављамо све кораке и проверавамо одговор сервера.

Као одговор на захтев, добијамо код 400 са празним телом одговора. Да ли треба да побегнемо и пријавимо дефект на фронтенд? Али још увек не знамо шта је тачно пошло по злу и шта треба да се поправи. Често се грешка 400 јавља када постоји неслагање између онога што је клијент послао и онога што је сервер очекивао. Може бити много разлога за ово, укључујући:

• Застарела документација у задатку
• Измене урађене без документације
• Типос

Хајде да проверимо захтев клијента

Ако имамо документацију, написану ручно или генерисану у Сваггер-у или ОпенАПИ-у, хајде да је користимо да проверимо да:

• Шаљемо све потребне параметре
• Вредности параметара имају исправне типове података (нпр. нумеричке вредности за инт параметре)

Како другачије можемо да проверимо захтев?

Чак и ако немамо документацију, можемо да проверимо:

• Усклађеност са синтаксом (нпр. ако је захтев послат у ЈСОН формату, требало би да прати ЈСОН синтаксу)
• Грешке у именима параметара (нпр. „мони“ уместо „монеи“, „доби“ уместо „боди“)
• Ћирилични знакови међу латиничним словима (нпр. „име“ написано ћириличним „е“)

Да ли је све у реду? Онда је време да наставимо наше путовање кроз лавиринт како бисмо пронашли одговор. Узимамо нашу мапу и „спуштамо се“ у дневнике.

Анализа дневника

Овде су могућа два сценарија:

• Грешка се евидентира током обраде захтева
• Ниједна грешка се не евидентира, али се захтеви снимају

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

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

• Бацкенд захтев
• Дневник грешака
• Препоручена поправка

Закључак

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

Можда ће бити потребно доста времена да се истражи лавиринт. Путовање може бити тешко и опасно: обрада неких захтева може бити замршена и слати захтеве на неколико различитих служби. Понекад има смисла поједноставити задатак и контактирати архитекте лавиринта – програмере.