Меню

Проучвателно тестване срещу тестване по сценарий: кой печели?

exploratory testing vs scripted testing

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

Реални ползи от изследователските тестове:

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

Проучвателно тестване срещу тестване по сценарий

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

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

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

колко използваеми хоста са на разположение при даден ip адрес на клас c с маската на подмрежата по подразбиране?

Контекстно базирани (Изследователски тестове) срещу скриптове тестващи екипи

Два отбора, два подхода:

Започнахме, като разделихме тестерите на два отбора по трима. Тестерите във всеки екип са имали едни и същи сравними знания за приложението. Същите определения за тежест на дефекта (основни, второстепенни) бяха създадени и за двата отбора. И двата отбора им бяха доставени еднакви компилации на приложения. Единият екип („по сценарий“) ще прилага традиционния подход, базиран на скриптове, а другият екип („изследователски“) ще възприеме подход, основан на контекста на тестване. Тестовите дейности ще бъдат разделени на две фази от по три дни.

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

Изследователският екип създаде две визуални карти на ума , единият, който идентифицира тестовото покритие и тестовите харти, а другият обхваща продуктовите компоненти / модули. Процесът създаде общо 24 тестови харта. Определените харти бяха на високо ниво и позволяваха контекстуална интерпретация, разширявайки обхвата на тестовата сесия за тестерите.

Фаза 1:

Екипът по сценарий успя да завърши 6 тестови случая за дадените три дни. По това време те съобщават за 6 основни дефекта.

Изследователският екип успя да завърши 13 тестови сесии, вариращи от 30 минути до 180 минути всяка. Те отчетоха 10 големи дефекта и 5 малки дефекта.

сценарий срещу изследователско тестване 1

Интересното е, че изследователският екип съобщава за всички дефекти, които екипът по сценарий е докладвал.

Фаза 2:

Екипът по сценарий успя да завърши 9 тестови случая този път. Те докладваха 10 основни дефекта и 8 незначителни дефекта .

Изследователският екип завърши 18 сесии. Те докладваха 14 основни дефекта и 5 малки дефекта.

сценарий срещу изследователско тестване 2

Във фаза 2 екипът по сценарий съобщи за 2 големи и 1 незначителен дефект, които изследователският екип не откри, но изследователският екип отчете 3 основни и 1 незначителен дефект, които сценарият не докладва.

Това не отчита относителната сложност на работните процеси, които може да са избрани от тестерите в рамките на тези сесии и тестовите случаи, но все пак можем да направим някои интересни заключения.

Какво означава?

Изглежда, че изследователският подход и породената от него отговорност и гъвкавост водят до по-ефективна форма на тестване. Може да е възможно да обхванете повече основи чрез разработване и адаптиране на вашите тестови харти с напредването на тестовите сесии, въз основа на това, което има смисъл в контекста. Тази свобода липсва при тестване на базата на скриптове и може да предотврати откриването на дефекти.

тестване на уеб услуги, използвайки въпроси за интервю за soapui

Придържайки се твърдо към скриптове, се създават износени пътеки и само чрез отклоняване от тези пътища ще разкрием всички дефекти. Както беше споменато няколко пъти от лидерите на мисли в тестващата общност, „Ако си представяте даден продукт като поле на наземни мини и всяка наземна мина е дефект, тогава е съвсем ясно, че стъпването по един и същ път отново и отново не е начинът да ги намерите всичко.'

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

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

Заключение

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

за автора

Муш Хонда е директор по качеството на Технология KMS , доставчик на ИТ услуги през жизнения цикъл на разработката на софтуер с офиси в Атланта, Джорджия и Хошимин, Виетнам. Преди това е бил тестер в Ernst & Young, Nexidia, Colibrium Partners и Connection. Услугите на KMS включват управление на приложения, тестване, поддръжка, професионални услуги и увеличаване на персонала.

Съгласен ли си? Чувствайте се свободни да публикувате вашите коментари, въпроси по-долу.

PREV Урок | СЛЕДВАЩ Урок # 4: Проучвателно тестване с HP Sprinter

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

^