Ad-hoc тестването е вид софтуерно тестване, което разработчиците и софтуерните компании прилагат при проверка на текущата итерация на софтуера. Тази форма на тестване дава по-добра представа за програмата, като открива проблеми, които конвенционалното тестване може да не успее да открои.
От първостепенно значение е екипите за тестване да имат пълно разбиране за процеса на ad hoc тестване, за да знаят как да заобиколят неговите предизвикателства и да се уверят, че екипът може успешно да приложи тази техника.
Знаейки как точно работи ad hoc тестването и кои инструменти могат да улеснят прилагането му, предприятието може непрекъснато да подобрява собствените си процедури за осигуряване на качеството. Официалният процес на тестване следва много специфични правила, в резултат на което екипът може да пропусне някои грешки – ad-hoc проверките могат да заобиколят тези мъртви точки и бързо да тестват всяка функция на софтуера.
В тази статия разглеждаме отблизо ad-hoc тестването и как можете да го използвате в своя полза при разработването на софтуерен продукт.
Значение на Ad-Hoc тестването: Какво е Ad-Hoc тестване?
Ad-hoc тестването е процес за осигуряване на качеството, при който се избягват формалните правила и документацията – това помага на тестерите да откриват грешки в приложенията си, които традиционните подходи не могат да идентифицират. Това обикновено изисква цялостно познаване на софтуера преди началото на тестването – включително разбиране на вътрешните механизми на програмата. Тези ad hoc проверки имат за цел да нарушат приложението по начин, който отразява въведените от потребителя данни, като отчитат различни потенциални ситуации, така че разработчиците да могат да отстранят всички съществуващи проблеми.
Липсата на документация е от основно значение за тази техника, която не включва контролен списък или тестови случаи, които да насочват тестерите към функциите на приложението. Ad-hoc тестването е изцяло свързано с тестване на софтуера по начин, който екипът реши, че е ефективен в конкретния момент. При това може да се вземат предвид вече съществуващи официални тестове, но може и просто да се проведат възможно най-много тестове в рамките на (вероятно ограниченото) време, което е отделено за тази техника.
1. Кога и защо е необходимо да се прави Ad-Hoc тестване при тестването на софтуер?
Основната причина, поради която компаниите провеждат ad hoc тестове, е способността им да откриват грешки, които традиционните подходи не могат да открият. Това може да се дължи на множество причини, като например конвенционални тестови случаи, следващи особено стандартизиран процес, който не може да отчете особеностите на дадено приложение.
Всеки тип тестване може да предложи нови перспективи и интересни подходи към осигуряването на качеството – това показва и проблеми с обичайната стратегия за тестване. Например, ако ad-hoc тестването може да идентифицира проблем, който тестовите казуси на екипа не адресират, това означава, че те могат да се възползват от калибриране на методологията си за тестване.
Тестващите могат да извършват ad hoc проверки във всеки момент от процеса на тестване. Обикновено това служи като допълнение към традиционното (и по-официално) осигуряване на качеството и с оглед на това тестерите могат да извършват ad-hoc проверки, докато колегите им провеждат по-официални проверки. Вместо това обаче те могат да предпочетат да запазят ad hoc проверките до края на официалния процес на тестване като последващо действие, което е насочено конкретно към потенциалните “слепи” места.
Ad-hoc тестването може да бъде полезно и когато времето е особено ограничено поради липса на документация – подходящият момент зависи от компанията и предпочитания от нея подход.
2. Когато не е необходимо да правите Ad-Hoc тестване
Ако няма достатъчно време за провеждане на ad-hoc и формално тестване, важно е екипът да даде приоритет на последното, тъй като то осигурява значително покритие на тестовете – дори и да съществуват някои пропуски.
Ако официалните тестове на екипа открият грешки, които трябва да бъдат отстранени, обикновено е по-добре да се изчака, докато разработчиците завършат необходимите промени, за да се въведат ad hoc проверки. В противен случай резултатите, които те предоставят, могат скоро да станат неактуални, особено ако тестовете се отнасят до компонент, в който вече има грешки.
Освен това преди етапа на бета-тестване трябва да се извърши и ad-hoc тестване.
3. Кой участва в Ad-Hoc тестването?
В процеса на Ad-Hoc тестване участват няколко ключови роли, включително:
– Софтуерните тестери са основните членове на екипа, които извършват ad hoc проверки. Ако се прилага тестване по двойки, няколко от тези тестери ще работят заедно върху едни и същи компоненти.
– Разработчиците могат самостоятелно да използват тези проверки преди официалния етап на осигуряване на качеството, за да проверят бързо собствения си софтуер, въпреки че това е по-малко задълбочено от специалното ad-hoc тестване.
– Ръководителите на екипи или отдели разрешават цялостната стратегия за тестване, като помагат на тестерите да определят кога да започнат ad-hoc тестване и как да го извършат, без да прекъсват други проверки.
Предимства на Ad-Hoc тестването
Предимствата на ad-hoc тестването при тестването на софтуер включват:
1. Бързи решения
Тъй като тези тестове не изискват често документиране преди, по време или след проверките, екипите могат да идентифицират проблемите много по-бързо. Тази простота предоставя огромна свобода на тестващите.
Например, ако тестват даден компонент и не могат да идентифицират никакви грешки, екипът може просто да премине към следващия тест, без да отбележи това в документа.
2. Допълва други видове тестове
Нито една стратегия за тестване не е съвършена, а 100% покритие обикновено е невъзможно да се постигне – дори и при изчерпателен график. Винаги ще има пропуски в конвенционалните тестове, затова е важно компаниите да интегрират множество подходи.
Ad-hoc тестването има за цел да открие проблемите, които формалното тестване не може да покрие, което гарантира по-широко общо покритие на тестовете.
3. Гъвкаво изпълнение
Ad-hoc тестването може да се извърши във всеки момент от процеса на осигуряване на качеството преди бета тестването, което позволява на компаниите и екипите да решат кога е най-добре да извършат тези проверки. Те могат да изберат да извършат ad hoc тестове заедно с конвенционалните тестове или да изчакат до края – независимо от това, екипът се възползва от възможностите, с които разполага.
4. По-голямо сътрудничество
Разработчиците са по-ангажирани с този процес в сравнение с много други форми на тестване – особено ако компанията използва тестване по двойки.
В резултат на това разработчиците получават по-добра представа за собствените си приложения и могат да се справят с грешките по по-качествен начин. Това спомага за още по-голямо подобряване на цялостното качество на софтуера.
5. Разнообразни перспективи
Ad-hoc тестването може да покаже приложението от нов ъгъл, като помогне на тестващите да се запознаят с тези функции по нов начин. Допълнителните гледни точки са от решаващо значение по време на тестването, тъй като официалните проверки често имат поне малки пропуски.
Ако тестващите ad-hoc използват софтуера с конкретното намерение да го разбият, те ще могат по-лесно да определят ограниченията на програмата.
Предизвикателства при Ad-Hoc тестването
Процесът на ad-hoc тестване също се сблъсква с няколко предизвикателства, като например:
1. Трудности при отчитането
Липсата на документация прави ad-hoc тестването много по-бързо, но също така може да затрудни докладването за всичко друго, освен за сериозен проблем.
Например, една предварително извършена проверка може да стане по-подходяща на по-късна дата, въпреки че първоначално не е довела до значителни резултати. Без изчерпателна документация екипът може да не е в състояние да обясни тези тестове.
2. По-малко повторяеми
По подобен начин тестващите може да не са напълно наясно с точното условие, необходимо за предизвикване на наблюдаваните от тях реакции. Например при ad hoc проверка, която връща грешка, екипът може да не разполага с достатъчно информация, за да предприеме действия. Възможно е да не знаят как да повторят този тест и да получат същия резултат.
3. Изисква се опит в областта на софтуера
Тъй като скоростта е от ключово значение при ad-hoc тестването и то обикновено включва опити за разбиване на приложението, е важно тези тестери да познават тази програма отблизо.
Познаването на начина, по който работи, позволява на тестващите да разбиват и манипулират софтуера по повече начини, но това може значително да повиши изискванията за умения при ad-hoc тестване.
4. Ограничена отчетност
Липсата на документация може да доведе не само до лошо отчитане, но и до неволно удължаване на процеса на тестване, което може да повлияе на полезността на бързите индивидуални ad hoc тестове.
Тестерите могат да се затруднят да проследят напредъка си без достатъчно документация по време на всеки етап. Това може дори да ги накара да повторят проверка, която други тестери вече са извършили.
5. Може да не отразява опита на потребителя
Целта на почти всички видове тестване е да се отчетат грешките, които по някакъв начин засягат крайните потребители. Ad-hoc тестването разчита предимно на опитен тестер, който се опитва да имитира неопитен потребител, и това трябва да бъде последователно при всяка проверка до и включително опитите му да разбие приложението.
Характеристики на Ad-Hoc тестовете
Основните характеристики на успешните ad-hoc тестове включват:
1. Разследване
Основният приоритет на ad-hoc тестването е да се идентифицират грешки в приложението, като се използват техники, които не се отчитат при конвенционалните проверки. Специалните проверки претърсват този софтуер с ясната цел да открият пропуски в процедурата за тестване на екипа, включително покритието на тестовите случаи.
2. Неструктуриран
Проверките ad hoc обикновено нямат определен план, освен провеждането на възможно най-много тестове извън типичните граници на официалното осигуряване на качеството. Тестващите обикновено групират проверките по компоненти за удобство, но това не е задължително – те дори могат да измислят проверките, докато ги извършват.
3. Задвижван от опита
Ad-hoc тестерите използват своя вече натрупан опит в областта на софтуера, за да преценят кои тестове биха донесли най-големи ползи и да се справят с често срещаните “слепи” места при формалното тестване.
Въпреки че процесът на тестване все още е напълно неструктуриран, тестващите прилагат знанията си за предишни ad-hoc проверки, наред с други, докато решават стратегията си.
4. Широк обхват
Няма точни указания за това кои проверки трябва да се извършват от екипа по време на ad hoc тестването, но те обикновено обхващат редица компоненти – вероятно с по-голямо внимание към по-чувствителните аспекти на приложението. Това помага на тестващите да гарантират, че техните изпити могат да допълнят напълно официалното тестване.
Какво тестваме в Ad-Hoc тестовете?
Екипите за осигуряване на качеството обикновено тестват следните неща по време на ad hoc тестване:
1. Качество на софтуера
Тези проверки имат за цел да идентифицират грешки в приложението, които не могат да бъдат открити при конвенционалното тестване; това означава, че процесът проверява основно общото състояние на приложението.
Колкото повече грешки могат да бъдат открити чрез ad-hoc тестване, толкова повече подобрения могат да бъдат въведени от разработчиците преди крайния срок.
2. Тестови случаи
При ad-hoc тестването обикновено не се прилагат тестови казуси – и това е специално, за да може екипът да проучи доколко те са ефективни при осигуряването на достатъчно покритие. Случаите за тестване вероятно са неадекватни, ако ad-hoc проверките могат да открият грешки, които конвенционалните процеси на тестване не могат да открият.
3. Персонал за изпитване
Целта може да бъде и проверка на уменията и знанията на екипа за тестване, дори ако тестовите казуси са подходящи. Например тяхната методология за изпълнение на случаите може да е недостатъчна и ad-hoc тестването може да е от решаващо значение за преодоляване на произтичащите от това пропуски в покритието на тестовете.
4. Ограничения на софтуера
Тестването ad-hoc има за цел също така да разбере границите на приложението – например как то реагира на неочаквани входни данни или високи натоварвания на системата. Тестерите могат да изследват конкретно съобщенията за грешки на програмата и доколко добре работи това приложение, когато е подложено на значителен натиск.
Изчистване на някои неясноти:
Ad-Hoc тестване и проучвателно тестване
Някои хора смятат, че ad-hoc и проучвателното тестване са синоними, но истината е по-сложна.
1. Какво представлява проучвателното тестване?
Изследователското тестване се отнася до процедури за осигуряване на качеството, които изследват софтуера от цялостна гледна точка и специално съчетават процесите на откриване и тестване в един метод. Обикновено това е междинно звено между напълно структурирано тестване и напълно свободни ad-hoc проверки.
Проучвателното тестване работи най-добре в специфични сценарии, например когато е необходима бърза обратна връзка или ако екипът трябва да се справи с крайни случаи. Този тип тестване обикновено достига пълния си потенциал, когато екипът използва скриптирано тестване заедно с него.
2. Разлики между проучвателното тестване
и Ad-Hoc тестване
Най-голямата разлика между ad-hoc и проучвателното тестване е, че при първото се използва документация за записване и улесняване на проверките, докато при ad-hoc тестването това се избягва напълно. Проучвателното тестване поставя по-голям акцент върху свободата на тестовете, но никога не е на същото ниво като подхода ad hoc, който е изцяло неструктуриран.
Проучвателното тестване включва също така изучаване на приложението и неговата вътрешна работа по време на тези проверки – вместо това ad-hoc тестерите често имат изчерпателни познания за функционалността на софтуера, преди да започнат.
Видове Ad-Hoc тестове
Съществуват три основни форми на ad-hoc тестване при тестването на софтуер, включително:
1. Тестване с маймуни
Може би най-популярният тип ad hoc тестове са “маймунските” тестове, при които екип разглежда на случаен принцип различни компоненти.
Обикновено това се извършва по време на процеса на тестване на единици и включва серия от проверки без тестови случаи. Тестерите изследват независимо данните по напълно неструктуриран начин, което им позволява да проучат по-широката система и нейната способност да издържа на интензивно натоварване от страна на потребителите.
Наблюдението на изхода на тези нескриптирани техники помага на екипа по тестване да идентифицира грешки, които други тестове на единици са пропуснали поради недостатъци в конвенционалните методи за тестване.
2. Тестване на приятели
В контекста на ad-hoc тестовете на приятелите се използват минимум двама служители – обикновено тестер и разработчик – и се провеждат предимно след етапа на тестване на модулите. “Приятелите” работят заедно в един и същи модул, за да установят грешките. Техните разнообразни умения и богат опит ги правят по-ефективен екип, което помага да се облекчат много от проблемите, възникващи поради липса на документация.
Разработчикът може дори сам да предложи някои от тестовете, за да определи компонентите, на които може да е необходимо да се обърне повече внимание.
3. Тестване по двойки
Тестването по двойки е сходно с това, че включва двама служители, но обикновено това са двама отделни тестери, единият от които изпълнява действителните тестове, а другият води записки.
Дори и без официална документация, воденето на бележки може да позволи на екипа неформално да следи отделни ad hoc проверки. Ролите на изпитващия и пишещия могат да се сменят в зависимост от теста или двойката може да запази определените им роли през целия процес.
Обикновено тестерът, който има повече опит, е този, който извършва действителните проверки, въпреки че те винаги си поделят работата.
Ръчни или автоматизирани Ad-Hoc тестове?
Автоматизираното тестване може да помогне на екипите да спестят още повече време по време на етапа на осигуряване на качеството, което позволява на тестерите да включат повече проверки в графика си. Дори и без определена структура, от съществено значение е тестерите да работят за постигане на максимално покритие, а автоматизацията насърчава по-задълбочени проверки на този софтуер.
Автоматизираните ad-hoc проверки обикновено са по-точни от ръчните тестове поради способността им да избягват човешка грешка по време на повторни задачи – това е особено полезно, когато едни и същи тестове се изпълняват на различни итерации. Успехът на тази процедура обикновено зависи от инструмента за автоматизирано тестване, който екипът избира, и от неговата функционалност.
Въпреки това автоматизираното тестване има някои ограничения. Например основната сила на ad-hoc тестването е способността му да имитира потребителски вход и да извършва случайни проверки, когато тестващият ги измисли. Тези тестове могат да загубят своята случайност, ако програмата за тестване на организацията се справя трудно със сложните проверки.
Времето, необходимо за автоматизиране на тези много специфични задачи, също може да ограничи типичните икономии на време от този процес. Важно е екипите да проучат внимателно наличните инструменти за автоматизация, за да намерят подходящия за проекта на компанията.
Какво ви е необходимо, за да започнете Ad-Hoc тестване?
Ето основните предпоставки за ad-hoc тестване:
1. Квалифициран персонал
Тъй като ad-hoc тестовете са бързи, случайни проверки на вътрешната работа на софтуера, обикновено е полезно да имате тестери, които имат опит със софтуера. Те трябва също така да имат познания за основните принципи на тестване – това им позволява лесно да определят най-ефективните проверки.
2. Неструктуриран подход
Тестерите трябва да са готови да изоставят обичайните си стратегии за ad-hoc тестване; този начин на мислене е също толкова важен, колкото и самите проверки на качеството. Този метод може да бъде успешен само без структура или документация и е жизненоважно тестерите да помнят това на всеки етап.
3. Софтуер за автоматизация
Въпреки че ad-hoc тестването разчита повече на тестване на случайни входни данни и условия, автоматизацията все още е много ефективна техника във всеки контекст.
Поради тази причина при ad-hoc проверките все пак трябва да се използват инструменти за автоматизирано тестване, когато това е възможно, тъй като подходящото приложение може значително да оптимизира процеса.
4. Други форми на изпитване
Ad-hoc тестовете работят най-добре заедно с други проверки с по-формален подход, като помагат на екипа да гарантира значително покритие на софтуера. Изключително важно е тестерите да смесват различни техники, макар че това може да стане преди, по време или след като завършат ad-hoc тестването.
Процес на Ad-Hoc тестване
Обичайните стъпки, които тестващите трябва да следват, когато извършват ad-hoc тестване при тестването на софтуер, са:
1. Дефиниране на целите на ad-hoc теста
Този етап е ограничен поради липсата на документация и структура, но все пак е от първостепенно значение екипът да има ясен фокус. Тестерите могат да започнат да споделят неясни идеи за това кои предстоящи тестове да се проведат и кои компоненти да се приоритизират.
2. Избор на екип за ad-hoc изпитване
Докато екипът обмисля редица потенциални ad-hoc проверки, той определя и кои тестери биха били най-подходящи за този тип тестване. Те обикновено избират тестери, които разбират отблизо приложението, и могат да ги свържат с разработчик.
3. Изпълнение на ad-hoc тестове
След като решите кои тестери са подходящи за този етап, тези членове на екипа започват своите проверки в договорен момент от тестването. Тяхната цел е да извършат възможно най-много проверки ad hoc, които тестващите може и да не са измислили до този етап.
4. Оценяване на резултатите от тестовете
След приключване на тестовете (или дори между отделните проверки) тестерите оценяват резултатите, но без да ги документират официално в тестови случай. Ако открият някакви проблеми със заявлението, те ги регистрират неофициално и обсъждат следващите стъпки на екипа.
5. Докладване на открити грешки
След като оценят резултатите, тестерите трябва да информират разработчиците за наличните в софтуера грешки, за да имат достатъчно време да ги отстранят преди пускането му.
Екипът по тестването използва информацията и за да определи как да подобри своите официални процеси на тестване.
6. Повторно тестване, ако е необходимо
Екипът за тестване вероятно ще повтори процеса ad-hoc за новите итерации на приложението, за да провери доколко добре се справя с актуализациите. Тъй като тестващите ще са отстранили много от предварително установените пропуски в тестовите си случаи, бъдещите ad hoc проверки може да изискват различен подход.
Най-добри практики за Ad-Hoc тестване
Съществуват определени практики, които екипите за тестване трябва да прилагат по време на ad-hoc тестването, включително:
1. Насочване към потенциални пропуски в тестването
Макар че ad-hoc тестването включва много по-малко планиране от другите видове, екипът все пак се стреми да отстрани недостатъците в осигуряването на качеството. Ако ad-hoc тестерите имат съмнения за някакви специфични проблеми с тестовите случаи на екипа, те трябва да дадат приоритет на това при провеждането на проверките си.
2. Обмислете софтуер за автоматизация
Стратегиите за автоматизация, като например хиперавтоматизацията, могат да предложат много предимства на компаниите, които искат да провеждат ad-hoc тестове.
Успехът на това зависи от няколко ключови фактора, включително инструмента, който предприятието избира, както и от общата сложност на неговите ad hoc тестове.
3. Водете си подробни бележки
Липсата на документация при ad-hoc тестването е основно за по-нататъшно оптимизиране на този процес – екипът би могъл да се възползва от това да прави неофициални бележки в хода на работата си. Това дава на тестващите ясен запис на тези проверки и техните резултати, което повишава цялостната им повторяемост.
4. Продължавайте да усъвършенствате тестовете
Ad-hoc тестерите непрекъснато усъвършенстват своя подход, за да отчитат промените в стратегията за тестване на екипа. Например, когато разглеждат по-нови версии на софтуера на компанията, те могат да коригират тези проверки в отговор на по-нови и по-обхватни официални тестови случаи.
7 грешки и капани при внедряване
Ad-Hoc тестове
Както при всеки процес на тестване, има широк спектър от потенциални грешки, които екипът трябва да избягва, като например:
1. Неопитни тестери
За да се поддържа очакваното темпо на ad-hoc тестване, ръководителят на екипа трябва да разпредели тестерите въз основа на знанията и уменията, които притежават. Въпреки че много форми на тестване могат да се използват от служители за осигуряване на качеството на начално ниво, ad-hoc проверките изискват членове на екипа, които напълно разбират софтуера; за предпочитане е да имат опит в провеждането на тези тестове.
2. Нефокусирани проверки
Ad-hoc тестването може значително да подобри покритието на тестовете поради по-бързия си темп – екипът не трябва да попълва обширна документация преди и след всяка проверка.
Въпреки това тестващите ad hoc трябва да поддържат силен фокус; например, те могат да решат да дадат приоритет на определени компоненти с по-голям риск от повреда.
3. Без планиране
Избягването на какъвто и да е план може да ограничи ефективността на ad hoc тестването. Въпреки неструктурирания характер на този подход е важно екипът да има приблизителна представа за това кои тестове ще се изпълняват, преди да започне.
Времето по време на този процес е ограничено и знанието как да действате може да донесе много ползи.
4. Прекалено структуриран
В противоположния край на спектъра този подход обикновено се основава на липсата на планиране, тъй като това помага на тестерите активно да подкопават тестовите случаи и да откриват скрити грешки.
Ad hoc тестването е известно също като случайно тестване и налагането на структура може да попречи на тези проверки да открият грешки.
5. Без дългосрочни промени
Целта на ad-hoc тестването е да се идентифицират всички слабости в тестовите случаи на екипа; това проверява цялостната им стратегия също толкова, колкото и самия софтуер.
Това обаче означава, че ad-hoc тестовете обикновено са ефективни само ако екипът използва тази информация, за да усъвършенства с течение на времето своите официални проверки.
6. Несъвместими набори от данни
Почти всяка форма на тестване изисква симулирани данни, за да се оцени как реагира приложението; някои инструменти позволяват на тестващите автоматично да попълват програмата с имитационни данни.
Възможно е обаче това да не отразява начина, по който потребителят ще работи със софтуера – ad hoc проверките изискват набори от данни, с които софтуерът вероятно ще се сблъска.
7. Информационни силози
От съществено значение е тестерите и разработчиците да са в постоянна комуникация помежду си, дори ако последните не са част от процеса на ad-hoc тестване.
Това помага на всички да разберат кои тестове са били проведени – показва следващите действия, които трябва да се предприемат, като същевременно предотвратява ненужното повтаряне на определени проверки от страна на тестерите.
Видове резултати от Ad-Hoc тестове
Ad-hoc проверките дават няколко различни резултата, включително:
1. Резултати от тестовете
Отделните тестове дават различни резултати в зависимост от конкретния компонент и подход – те могат да бъдат под различни форми.
Обикновено отговорността за определяне на това дали резултатите представляват грешка е на тестващия, въпреки че липсата на документация затруднява сравняването на резултатите с неговите очаквания. Екипът предава тези резултати на разработчиците, ако те забележат някакви проблеми.
2. Протоколи от изпитвания
Самият софтуер използва сложна система от вътрешни логове, за да следи входните данни на потребителите и да подчертава редица проблеми с файлове или бази данни, които могат да възникнат.
Това може да насочи към вътрешна грешка, включително към конкретната част от софтуера, която причинява проблема. Благодарение на тази информация тестерите и разработчиците могат много по-лесно да се справят с откритите от тях проблеми.
3. Съобщения за грешки
Много от проверките ad hoc имат за цел да нарушат софтуера и да разкрият неговите ограничения, което означава, че съобщенията за грешки на приложението са един от най-често срещаните резултати от тези тестове.
Чрез умишлено предизвикване на съобщения за грешка екипът може да покаже какво вижда средният краен потребител, когато неочакваните действия, които предприема, оказват неблагоприятно въздействие върху работата на програмата.
Примери за Ad-Hoc тестване
Ето три сценария за ad-hoc тестване, които показват как един екип може да го приложи за различни приложения:
1. Уеб приложение за електронна търговия
Ако дадена компания желае да тества уеб приложение, базирано на електронна търговия, тя може да използва ad-hoc тестове – по-специално тестове с маймуни – за да провери доколко добре платформата се справя с неочаквани взаимодействия с потребителите.
Тестващите могат да се опитат да използват всяка функция до краен предел, като например да добавят в кошницата си нереалистични количества продукти или да се опитат да купят продукти, които не са налични. Те не са ограничени от тестовите задачи на екипа и има малко ограничения за проверките, които могат да извършат; тестерите могат дори да се опитат да извършат покупки, използвайки остарели URL адреси.
2. Настолно приложение
Тестващите ad hoc могат да приложат тези техники и за настолни приложения, като евентуално се фокусират върху различни машини и доколко всяка от тях се справя с програмата.
Членовете на екипа могат да извършват тези проверки многократно, за да видят как промяната на хардуерните или софтуерните настройки влияе върху цялостната производителност на приложението. Например определена графична карта може да има затруднения с визуализирането на интерфейса.
Алтернативно, тези тестери могат просто да подадат на програмата си невъзможни входни данни и да видят как тя реагира, например дали може правилно да покаже съобщения за грешка, които обясняват проблема по подходящ начин на крайния потребител.
3. Мобилно приложение
Един от начините, по които тестващите ad hoc могат да проверят дадено мобилно приложение, е да тестват неговите протоколи за сигурност – например могат да се опитат да получат директен достъп до инструментите за разработка на приложението.
Екипът може да се опита да провери дали е в състояние да извърши неразрешени действия, като открие често срещани пропуски и експлойти; той може специално да помоли служители с опит в областта на сигурността на приложенията да улеснят това.
Това може да включва и тестване по двойки с разработчиците, тъй като те са наясно с дизайна на приложението и позволяват на тестера да разбие софтуера и да покаже къде точно липсва сигурността му.
Видове открити грешки и бъгове
чрез Ad-Hoc тестване
Ad-hoc проверките могат да разкрият много проблеми с дадена програма, като например:
1. Грешки във функционалността
Използването на ad-hoc тестване за проверка на основните функции на дадено приложение може да разкрие сериозни грешки, които да повлияят на начина, по който крайните потребители могат да работят с него.
Например тестването на опциите за плащане на сайт за електронна търговия с маймуни ще илюстрира условията, които възпрепятстват транзакцията.
2. Проблеми с производителността
Тестерите могат да работят специално за създаване на проблеми с производителността на програмата – например като запълват базата данни с различни входящи данни за спам.
Това може да се прояви като значително забавяне или дори обща нестабилност на софтуера, което вероятно ще доведе до срив (потенциално на цялата система).
3. Проблеми с ползваемостта
Тези проверки могат също така да покажат грешки в интерфейса и общото потребителско изживяване. Например потребителският интерфейс на мобилно приложение може да се представя по различен начин на друга операционна система или резолюция на екрана. Лошият интерфейс може да доведе до затруднения на потребителите да работят с това приложение.
4. Недостатъци в сигурността
Случайният характер на ad hoc тестовете позволява да се обхванат редица често срещани и редки проблеми на сигурността; тестерът може да използва тези проверки, за да открие административните вратички на програмата.
В противен случай проверката може да покаже, че софтуерът няма криптиране на данни.
Общи показатели за ad-hoc тестване
Ad-hoc тестването използва различни показатели за улесняване на резултатите, включително:
1. Ефективност на откриване на дефекти
Този показател разглежда доколко ефективно процесът на тестване открива дефекти при всяка форма на тестване, включително ad hoc тестване. Ефективността на откриване на дефекти е процентът на откритите дефекти, разделен на общия брой проблеми – показва колко ефективни са тестовете.
2. Степен на покритие на теста
Допълнителна функция на ad-hoc тестването е да се увеличи покритието чрез проверка на компоненти по начин, който тестовите случаи не отчитат. Това означава, че тестерите ще се стремят да увеличат радикално покритието на тестовете при всяка проверка, доколкото могат.
3. Обща продължителност на теста
Ad-hoc тестването е много по-бързо от другите процеси за осигуряване на качеството – и е важно тестерите да работят, за да запазят това предимство. Показателите за продължителността на тестовете показват на членовете на екипа как могат да спестят време и да увеличат още повече предимствата на ad-hoc стратегиите.
4. Честота на катастрофите
Тези тестове често имат за цел да разбият софтуера и да предизвикат срив или сериозна грешка – това им позволява да надхвърлят типичните стратегии за тестване и да откриват неочаквани проблеми. За тази цел може да е полезно да знаете колко често софтуерът се срива и какви са причините за тези проблеми.
5 най-добри инструмента за Ad-Hoc тестване
Съществуват много безплатни и платени инструменти за тестване за ad-hoc тестване при тестването на софтуер – най-добрите пет са следните:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST е цялостна програма за тестване на софтуер, която осигурява високо ниво на функционалност за тестване + RPA както в безплатната, така и в корпоративната си версия.
Този пълен пакет за автоматизация на софтуер + RPA Suite позволява пълно тестване на различни настолни и мобилни платформи; технологията 1SCRIPT на софтуера също така позволява на потребителите да изпълняват многократно едни и същи проверки с лекота. Освен това инструментът използва най-съвременните технологии за компютърно зрение, което дава възможност на ZAPTEST да изпълнява ad hoc тестове от човешка гледна точка.
2. BrowserStack
BrowserStack е облачна платформа, която може да улесни тестването на повече от 3000 различни машини, с допълнителната функция за автоматизиране на скриптове Selenium. Въпреки че осигурява силно покритие за софтуерни проекти, той работи най-добре с браузърни и мобилни приложения.
Решенията за тестване на BrowserStack включват и безплатна пробна версия със 100 минути автоматизирано тестване – въпреки че тя може да има ограничена употреба.
Въпреки че подходът, базиран на облак, може да бъде полезен, той също така влияе отрицателно върху времето за реакция на платформата.
3. LambdaTest
LambdaTest също използва облачна технология и поставя силен акцент върху тестването на браузъри, което може да ограничи ефективността му за други приложения – въпреки че все още се справя добре с програми за iOS и Android. Това е полезна платформа, когато мащабируемостта е проблем, и се интегрира с много други тестови хостинг услуги.
Въпреки това някои потребители имат смесени реакции по отношение на цените на приложението в различните налични опции, които не са пробни, което потенциално ограничава достъпа на по-малките организации.
4. TestRail
TestRail като цяло е доста адаптивен, тъй като работи изцяло в браузъра, и въпреки силния фокус върху ефективните тестови случаи може да се похвали и с директна ad-hoc функционалност. Анализите, които предоставя след всеки тест, могат да помогнат и на екипи, които активно избягват да създават собствена независима документация, като същевременно им позволяват да валидират своя процес на тестване.
По-големите комплекти обаче могат да се затруднят с неговия формат, базиран на браузър, който може да ограничи значително икономията на време при ad hoc тестване.
5. Zephyr
Zephyr е платформа за управление на тестове от SmartBear, която помага на екипите за осигуряване на качеството да подобрят видимостта на тестовете си, като същевременно се интегрира добре с друг софтуер за проследяване на грешки.
Тази функция обаче е ограничена до определени приложения, като Confluence и Jira са тези, които се възползват най-много от Zephyr – това може да не са най-ефективните решения за всеки бизнес. Под марката Zephyr се предлагат няколко мащабируеми програми на различни цени.
Контролен списък, съвети и трикове за Ad-Hoc тестване
Ето допълнителни съвети за екипите, които трябва да се вземат предвид при провеждането на ad-hoc тестове:
1. Определяне на приоритетите на чувствителните компоненти
Някои функции или компоненти естествено са изложени на по-голям риск от грешки, отколкото други, особено ако са важни за цялостното функциониране на програмата.
Всеки подход към тестването трябва да идентифицира частите на приложението, на които може да се обърне по-задълбочено внимание. Това е особено полезно, когато общото време за тестване е ограничено.
2. Проучване на различни инструменти за тестване
Инструментът, който дадена организация прилага за улесняване на своите тестове, може да повлияе на обхвата и надеждността на тези проверки.
При ad-hoc тестването си струва да се разгледат възможно най-много програми, за да се намерят такива, които отговарят на неговия потребителски аспект. Софтуерът, който използва технология за компютърно зрение, като ZAPTEST, може да подходи към ad-hoc тестовете, използвайки стратегия, подобна на човешката.
3. Възприемете мислене ad-hoc
Ad-hoc тестването предлага огромна свобода на етапа на осигуряване на качеството, но екипът трябва да се ангажира с него, за да получи основните ползи от стратегията.
Например ad-hoc тестерите трябва да се откажат от всички обичайни документи, освен от основните бележки, и трябва да проверят софтуера от съвсем нова гледна точка.
4. Доверете се на инстинктите за изпитване
Опитът с ad-hoc тестване или общи проверки на софтуера може да помогне да се откроят общите точки на неизправност и това помага на тестерите да определят как да откриват грешки от всякакъв вид.
Изключително важно е тестерите да се доверяват на инстинктите си и винаги да използват тези знания в своя полза – те могат да разберат кои ad-hoc проверки биха били най-полезни.
5. Пълно записване на откритите грешки
Въпреки че при ad-hoc тестването няма официална документация и се разчита предимно на неофициални бележки, все пак е важно екипът да може да идентифицира и съобщи причината за софтуерна грешка.
Те трябва да записват всяка информация, която тестът предоставя и която е от значение за разработчиците, като например всички потенциални причини за тези проблеми.
6. Винаги се съобразявайте с потребителя
Всяка форма на тестване има за цел да адаптира цялостното преживяване на потребителя до известна степен – и ad-hoc тестването не е изключение. Въпреки че често разглежда по-дълбоко вътрешната работа на приложението и дори неговия вътрешен код, ad-hoc тестерите трябва да се опитат да разбият този софтуер по начини, по които потребителите теоретично биха могли.
7. Непрекъснато подобряване на процеса
Екипите за тестване трябва да усъвършенстват подхода си към ad-hoc тестването между няколко итерации на един и същи софтуер и от един проект към следващия.
Те могат да събират обратна връзка от разработчиците, за да разберат колко добре техните ad hoc тестове са помогнали на етапа на осигуряване на качеството и дали са успели значително да увеличат обхвата на тестовете.
Заключение
Ad-hoc тестването може да помогне на организациите от всякакъв вид да удостоверят своята стратегия за тестване на софтуер, но начинът, по който прилагат тази техника, може да бъде съществен фактор за нейната ефективност.
Балансирането на различните видове тестване е ключът към извличането на максимални ползи от ad hoc проверките – особено когато тази форма на тестване има за цел да допълни останалите, като запълни стратегически пропуск.
С приложение като ZAPTEST екипите могат да провеждат ad hoc тестове с по-голяма увереност или гъвкавост, особено ако прилагат автоматизация. Независимо от конкретния подход на екипа, ангажиментът му към ad hoc тестването може да доведе до революция в цялата програма или проект.
