ad hoc testing how find defects without formal testing process
Самият термин ad-hoc предполага липса на структура или нещо, което не е методично. Когато говориш за ad-hoc тестване , това означава, че е форма на a Черна кутия или поведенческо тестване, извършено без официален процес.
Официалният процес тук означава наличие на документация като документи за изисквания, планове за тестове, тестови случаи и правилно планиране на теста по отношение на графика и реда на извършените тестове. Освен това всички действия, извършени по време на тестването, обикновено не се документират.
Това се прави главно с цел да се опитат да се открият дефекти или недостатъци, които не могат да бъдат уловени чрез традиционни или официални процеси, следвани по време на цикъла на тестване.
Както вече разбрахме, същността на това тестване се състои в липсата на формален или структуриран начин на тестване. Когато се извършва такъв вид техники за произволно тестване, очевидно е, че тестерите извършват това, без да има предвид конкретен случай на употреба, с цел да разбият системата.
Следователно определено е още по-очевидно, че такава интуитивна или креативна методология за тестване изисква тестващият да бъде изключително квалифициран, способен и да има задълбочено ноу-хау на системата. Ad-hoc тестването гарантира, че извършеното тестване е завършено и е особено полезно при определяне на ефективността на тестовата кофа.
Препоръчително четене=> Изследователско тестване - Как да мислим отвъд традиционните граници на тестване?
Какво ще научите:
- Нека започнем с Ad-hoc пример за тестване
- Кога правим ad-hoc тестване?
- Видове Ad-hoc тестване
- Предимства на ad-hoc тестване
- Ad-hoc недостатъци за тестване
- Най-добри практики, за да направите това тестване по-ефективно
- Заключение
- Препоръчително четене
Нека започнем с Ad-hoc пример за тестване
Ето пример за това как можем да извършим това тестване, когато става въпрос за UI Wizard.
Да предположим, че трябва да създадете план или шаблон за някаква задача, която да бъде изпълнена с помощта на този съветник за потребителския интерфейс. Съветникът е серия от панели, които имат въведени от потребителя име, описание и т.н.
С напредването на съветника: да речем в един от панелите трябва да се въведат потребителски данни, което включва съветника на потребителския интерфейс, за да се изведе контекстно изскачащо поле, което добавя свързаните данни, за да завърши съветника и да разгърне / активира съветника.
За да тества този тестер прави редовното си тестване като:
въпроси и отговори за интервю за бизнес обекти
- Попълнете съветника успешно с всички валидни данни и създайте плана.
- Анулирайте съветника по средата.
- Редактирайте създаден план чрез съветника.
- Изтрийте създадения план и вижте, че от него няма остатъци.
- Въведете отрицателна стойност в съветника и вижте съответните съобщения за грешка.
Сега, за горния пример ето няколко тестови случая за ad-hoc тестове които биха могли да бъдат изпълнени за откриване на възможно най-много дефекти:
- Докато се опитвате да добавите отрицателни данни, добавете определени специални знаци, които не са ограничени, за да видите дали с тях се работи правилно. Например, понякога съветниците не ограничават {или [скоби, но в определени ситуации това може да противоречи на кода въз основа на езика, на който е написан, и да причини много ненадеждно поведение.
- Друг тест е специално по отношение на изскачащите прозорци. Потребителят може да доведе до стартиране на изскачащия прозорец и след това да се опита да натисне бутона за връщане назад на клавиатурата. Много пъти съм забелязвал, че по този начин съветникът на фона напълно изчезва и всички потребителски данни, въведени до стартирането на изскачащия прозорец, се губят!
Характеристики на Ad-hoc тестване:
Ако забележите сценариите по-горе, ще видите нещо много различно от характеристиките на този тип тестване.
Те са:
- Те винаги са в съответствие с тестовата цел. Те обаче са определени драстични тестове, извършени с намерение да разбият системата.
- Тестерът трябва да има пълни познания и осведоменост относно системата, която се тества. Резултатът от това тестване открива грешки, които се опитват да подчертаят вратичките в процеса на тестване.
- Също така, разглеждайки горните два теста, естествената реакция към него би била такава - този вид тест може да се извърши само веднъж, тъй като не е възможно повторно тестване, освен ако няма свързан дефект.
Кога правим ad-hoc тестване?
Наистина въпрос за милион долара!
Повечето от тестовите екипи на времето винаги са натоварени с твърде много функции, за да тестват в ограничени срокове. В този ограничен период от време има много тестови дейности, които са получени от официалния процес, който също трябва да завърши. В такива ситуации ad-hoc тестовете да намерят място в тестването са тънки.
От моя опит обаче един кръг от ad-hoc тестване може да направи чудеса за качеството на продукта и да повдигне много дизайнерски въпроси.
Тъй като ad-hoc тестването е по-скоро техника за тестване на „диво дете“, която не трябва да бъде структурирана, общата препоръка е тя да се извърши след изпълнението на текущата тестова група. Друга гледна точка е, че това може да се направи, когато не може да се извърши подробно тестване поради по-малко време.
Според мен бих казал това ad-hoc тестване може да се направи почти по всяко време - в началото, към средата и към края! Той просто намира своето място по всяко време. Въпреки това, когато трябва да се правят ad-hoc тестове, за да се постигне максимална стойност, най-добре се преценява от опитен тестер, който има задълбочени познания за системата, която се тества.
Кога да не се изпълни?
Ако предишният въпрос беше на стойност милион долара, това би трябвало да струва милиард!
Въпреки че установихме колко ефективни и ползотворни могат да бъдат ad-hoc тестовете, като квалифициран и способен тестер, ние също трябва да разгадаем кога да не инвестираме в този тип тестване. Въпреки че е по преценка на тестера, ето ви някои препоръки / примери, когато това може да не е необходимо.
- Избягвайте това тестване, когато има тестов случай, за който съществува дефект. В такава ситуация е необходимо да се документира точката на повреда на тестовия случай и след това да се провери / повторно тества дефектът, когато той е отстранен. Следователно той няма да бъде приложим тук.
- Възможно е също да има определени сценарии, при които могат да бъдат поканени клиенти или клиенти тествайте бета версията на софтуера . В такива случаи това тестване не трябва да се провежда.
- Друг сценарий е, когато има добавен много прост екран на потребителския интерфейс. Традиционните положителни и отрицателни тестове трябва да са достатъчни тук, за да се открият максимални дефекти.
Видове Ad-hoc тестване
Ad-hoc тестовете могат да бъдат категоризирани в три категории по-долу:
# 1) Тестване на приятел
При тази форма на тестване ще има член на теста и член на разработката, които ще бъдат избрани да работят върху същия модул. Точно след разработчикът завършва модулното тестване , тестер и разработчик седят заедно и работа по модула. Този вид тестване позволява функцията да се разглежда в по-широк обхват и за двете страни.
Разработчикът ще придобие перспектива за всички различни тестове, които тестващият тества, и тестерът ще придобие перспектива за това как е присъщият дизайн, който ще му помогне да избегне проектирането на невалидни сценарии, като по този начин предотвратява невалидни дефекти. Ще помогне на единия да мисли, както мисли другия.
# 2) Тестване на двойки
При това тестване двама тестери работят заедно върху модул със същата настройка на теста, споделена помежду им. Идеята зад тази форма на тестване да има двама тестери идеи и методи за мозъчна атака да имат редица дефекти. И двамата могат да споделят работата по тестване и да правят необходимата документация за всички направени наблюдения.
# 3) Тестване на маймуни
Това тестване се извършва главно на ниво тестване на единица. Тестерът анализира данни или тестове по напълно случаен начин, за да гарантира, че системата е в състояние да издържа на всякакви сривове. Това тестване може допълнително да бъде класифицирано в две категории:
най-добрите безплатни програми за настройка на компютър -
Предимства на ad-hoc тестване
Тестването гарантира на тестера много сила, за да бъде толкова креативен, колкото е необходимо.
Това повишава качеството и ефективността на тестване, както е показано по-долу:
- Най-голямото предимство, което се откроява, е, че тестерът може да открие броя на дефектите, отколкото при традиционното тестване, поради различните иновативни методи, които те могат да прилагат за тестване на софтуера.
- Тази форма на тестване може да се приложи навсякъде в SDLC; това не е ограничено само до екипа за тестване. Разработчиците могат също да проведат това тестване, което ще им помогне да кодират по-добре и също така да предвидят какви проблеми могат да възникнат.
- Може да се съчетае с друго тестване, за да се получат най-добрите резултати, които понякога могат да съкратят времето, необходимо за редовното тестване. Това би позволило да се генерират тестове с по-добро качество и по-добро качество на продукта като цяло.
- Той не изисква да се прави документация, която предотвратява допълнителното натоварване на тестера. Тестерът може да се концентрира върху действителното разбиране на основната архитектура.
- В случаите, когато няма много време за тестване, това може да се окаже много ценно по отношение на покритието и качеството на теста.
Ad-hoc недостатъци за тестване
Ad-hoc тестването има и няколко недостатъка. Нека да разгледаме някои от недостатъци, които са изразени:
Тъй като не е много организиран и няма задължителна документация, най-очевидният проблем е, че тестерът трябва да запомни и да си спомни всички подробности за ad hoc сценариите в паметта. Това може да бъде още по-предизвикателно, особено в сценарии, при които има много взаимодействие между различни компоненти.
- Следвайки от първата точка, това също би довело до невъзможност за пресъздаване на дефекти в последващите опити, ако бъде поискана информация.
- Друг много важен въпрос, който излиза наяве, е отчетността за усилията. Тъй като това не е планирано / структурирано, няма начин да се отчете времето и усилията, вложени в този вид тестване.
- Извършването на ad-hoc тестове трябва да се извършва само от много знаещ и опитен тестер в екипа, тъй като изисква активност и интуиция по отношение на предвиждането на потенциални дефектни зони.
Най-добри практики, за да направите това тестване по-ефективно
Обсъдихме подробно силните и слабите страни, свързани с това тестване.
В идеалния случай ad hoc тестването трябва да намери своето място в SDLC, но ако не се подходи по подходящ начин, може да се окаже скъпо и загуба на ценно време за тестване. И така, дадени по-долу са няколко насоки за ефективно ad-hoc тестване:
# 1) Идентифицирайте дефектните зони:
Когато имате добра възможност да тествате даден софтуер, ще се съгласите, че ще има някои функции, които са по-податливи на грешки от останалите. Ако сте нов в системата, продължете и проверете характеристиките v / s дефекти, отворени срещу тях.
Броят на дефектите в дадена функция е ще ви покаже, че е чувствителен и трябва точно да изберете точно тази област, за да извършите ad-hoc тестване. Това се оказва много ефективен във времето начин за излагане на някои сериозни дефекти.
# 2) Изграждане на опит:
Несъмнено тестващият, който има повече опит, е по-интуитивен и може да познае къде могат да бъдат грешките, в сравнение с някой, който няма много опит. Бих казал, опитен или не, зависи от човека да вземе крачка и да изгради опит в системата, която се тества.
Да, опитните тестери имат предимство, тъй като техните умения, изградени през годините, са полезни, но новите тестери трябва да използват това като платформа, за да получат възможно най-много знания за проектиране на по-добри ad hoc сценарии.
# 3) Създайте тестови категории:
След като сте запознати със списъка на функциите, които ще бъдат тествани, отделете няколко минути, за да решите как да категоризирате тези функции и да тествате. Например, трябва да решите да тествате функции, които са най-видими и най-често използвани от потребителя преди всичко друго, тъй като те изглеждат критични за успеха на софтуера.
След това можете да ги категоризирате по функционалност / приоритет и да ги тествате сегмент по сегмент.
Друг пример, при който това е особено важно, е дали има интеграция между компоненти или модули. В тези случаи може да има много аномалии, които могат да възникнат. Използването на категоризация би помогнало да се засегне този вид тест поне веднъж или два пъти.
# 4) Имайте груб план:
Да, да, този момент може да ви обърка малко, тъй като ние описахме ad-hoc тестването като тестване, което не трябва да има планиране или документация. Идеята тук е да се придържате към същността на ad-hoc тестването, но все пак има някои груби указания за това как планирате да тествате.
Много основен пример е, че понякога може просто да не можете да запомните всички тестове, които възнамерявате да извършите. Така че записването им ще гарантира, че няма да пропуснете нищо.
# 5) Инструменти:
Нека вземем пример, с който се сблъскваме много често всички ние. Много пъти, ако наблюдавате, самото тестване на функционалността е успешно, без да се отчита несъответствие в поведението му. Въпреки това дневниците зад кулисите може да отчитат някои изключения, които могат да бъдат пропуснати от тестерите, тъй като по никакъв начин не пречат на тестовата цел.
Те могат да бъдат дори с висока тежест. Следователно е много важно за нас да се учим и инструменти, които ще помогнат да се определи това незабавно.
# 6) Документ за повече дефекти:
Отново разбирам, че това може отново да повдигне някои вежди. Документацията не трябва да бъде подробна, а само малка бележка за собствена справка за всички обхванати различни сценарии, отклонение в участващите стъпки и записване на тези дефекти за конкретната категория тестови характеристики.
Това ще ви помогне да подобрите цялостната тестова група, като по този начин можете да решите как да импровизирате съществуващите тестови случаи или да добавите още, ако е необходимо.
Заключение
Обсъдихме подробно за ad-hoc техниките за тестване - неговите силни, слаби страни, ситуации, когато това би било и не би било от полза.
Това е една техника за тестване, която гарантира максимално задоволяване и удовлетворяване на креативността на тестера. В целия ми тестова кариера , Получавам най-голямо удовлетворение от ad-hoc тестването, тъй като няма ограничение за иновации, а вие в крайна сметка сте по-знаещи.
Като казах това, основното нещо, което трябва да вземем обратно от цялата горепосочена информация, би било да определете как да се възползвате от ad hoc силните страни на теста и да го накарате да добави стойност към цялостния процес на тестване и качеството на продукта
За автора: Това е статия за гости на Снеха Надиг. Тя работи като ръководител на теста с над 7 години опит в проекти за ръчно тестване и автоматизация.
Извършвате ли ad-hoc тестване на вашия проект? Какви са вашите предложения, за да направите Ad-hoc тестването успешно?
Препоръчително четене
- Функционално тестване срещу нефункционално тестване
- Какво е алфа тестване? Ранен сигнал за дефекти
- Основни разлики между тестване на черна кутия и тестване на бяла кутия
- Разликите между модулното тестване, интегрираното тестване и функционалното тестване
- Тестване на ефективността срещу тестване на натоварване срещу тестване на стрес (разлика)
- Проучвателно тестване срещу тестване по сценарий: кой печели?
- Какво е техника за изпитване на базата на дефекти?
- Процес на изпитване на шлюз B2B (Business to Business)