Меню

Какво е изследователско тестване при тестване на софтуер (Пълно ръководство)

  • Основен
  • Други
  • Какво е изследователско тестване при тестване на софтуер (Пълно ръководство)

what is exploratory testing software testing

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

Какво е проучвателно тестване?

„Изследователско тестване“ - както подсказва името, е едновременно обучение, дизайн на тестове и процес на изпълнение на теста. Можем да кажем, че в това тестване планирането, анализът, дизайнът и изпълнението на теста се извършват заедно и незабавно.

Това тестване е за изследване на системата и насърчаване на реално време и практическо мислене на тестер.

В тази поредица разгледахме следните уроци:

Урок # 1: Какво е изследователско тестване при тестване на софтуер (Този урок)
Урок # 2: Използване на обиколки за осигуряване на цялостно изследователско тестване
Урок № 3: Проучвателно тестване срещу тестване по сценарий
Урок № 4: Проучвателно тестване с HP Sprinter
Урок № 5: Топ 17 инструменти за изследователско тестване

************************************
Изследователско тестване

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

Общ преглед

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

Това изисква минимално планиране. Тестерите непрекъснато вземат решение за следващата й стъпка от действие. Напълно зависи от мисловния процес на изпитателя.

Понякога това тестване може да бъде по-полезно от официалния подход за тестване за намиране на някои фини дефекти които липсват при официалното тестване.

Съзнателно или несъзнателно всеки тестер би направил проучвателно тестване в някакъв момент от кариерата си.

Както всички знаем, учащият ще се учи по-добре чрез практически опит, вместо да тъпче теорията.

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

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

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

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

Малко неща, които трябва да запомните, докато извършвате това тестване:

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

Препоръчителна услуга за изследователско изпитване

# 1) Digivante Direct

Digivante Direct Logo

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

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

Характеристика:

  • 24 работни дни за тестване само за 24 часа или 90 работни дни за 72 часа и ненадминато, всеобхватно ниво на тестване, постижимо с други средства.
  • Ниска цена , лесни за разбиране ценови пакети без скрити екстри.
  • Самообслужване онлайн портал, който не изисква постоянен ангажимент.
  • Реални хора, тестващи на реални устройства - далеч по-голямо покритие на устройства и браузъри, отколкото можете да постигнете вътрешно и всичко това за по-бързо време за изпълнение.
  • Пълно покритие на изследователския тест - намаляване на риска и подобряване на удовлетвореността на крайните потребители и процента на конверсия, като по този начин увеличава приходите, като същевременно намалява разходите.
=> Посетете уебсайта на Digivante Direct

Примери за изследователско тестване

Пример # 1:

Уебсайт на доставчика на услуги за домашна грижа със следните компоненти:

  • Влизам
  • Услуги
  • Количка
  • Плащане
  • История на поръчките
  • Разпределение на техник

Обща идея за начало изследователски тестването ще бъде за влизане или резервиране на услуга.

Как да обхванем тестови случаи?

Тестове за проучвателни тестове

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

В горното Пример, идеята е да започнете с функционалност, базирана на вашите познания. Докато научавате и наблюдавате повече за приложението, можете да управлявате следващия си набор от тестови случаи.

Пример # 2:

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

Поради ограничения срок и тежестта на тестването използвах изследователския подход на тестване. Целта ми беше да тествам нови функции и да открия нарушения на изискванията за съвместимост.

Гореспоменатата цел стана моя харта за тази тестова сесия.

По време на това тестване бяха разработени следните тестови случаи:

  • Тестване, за да се уверите, че новият Договорен фонд е добавен към заявлението.
  • Новият MF се купува успешно.
  • Оценката на новия MF е правилна.
  • Опитах се да купя нов MF за съществуващо портфолио.
  • Може ли нов MF да бъде добавен към всички портфейли?
  • Въздействие на новата МФ върху оценка на съществуваща.
  • Така че в други тестови случаи бяха развити.

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

Основната стратегия на изследователските тестове е да има план за атака. Започнете да тествате с вашата идея и импровизирайте нови тестови казуси въз основа на вашите знания и наблюдения.

Пример # 3:

Проучвателно тестване на уебсайта на IRCTC

=> Щракнете тук, за да изтеглите примерните тестови случаи на изследователско тестване на уебсайта на IRCTC.

Подход за тестване

  • Използвайте евристиката за насочване на тестването.
  • Изпълнението на тестови случаи и създаването на тестови казуси вървят ръка за ръка.
  • Тестовите случаи продължават да се развиват въз основа на наблюдение и обучение на тестери.
  • Различни техники за тестване като Анализ на гранична стойност , изпитване за еквивалентност и др. може да се приложи към ET.
  • Сесийният ET може да се използва, за да го направи по-структуриран и целенасочен.
  • Тестерите могат да разклоняват идеи, но никога да не се отклоняват от вашата мисия.
  • ET тестването не използва скриптове, а зависи от интуицията, уменията и опита на тестера.

Ползи

Предимствата на това тестване включват:

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

Демерити

По-долу са посочени недостатъци:

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

Сесийно проучвателно тестване

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

По принцип е трудно да се определи количествено работата и прекараното време. Във всеки проект обаче трябва да предоставим метрики, оценки и отчет за напредъка на ръководителите на екипи и мениджърите. Както се казва, „ако не можете да го определите количествено, не можете да го управлявате“.

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

Приближаване:

Тестовите задачи са разделени на сесии.

Следват компонентите на базираното на сесии тестване (SBT):

  • Мисия: Мисията извиква целта на сесията и по някакъв начин осигурява фокуса на тестера. Той също така ще включва продължителност на сесията.
  • Харта: Включва обхвата на тестването. По принцип, дневен ред с подробности за целите, които трябва да бъдат изпълнени по време на сесията.

Пример за тестова харта за функционалност за влизане на уебсайта на услугата за домашни грижи:

Пример за тестова харта за функционалност за влизане

  • Сесия: Предварително дефинирана сесия за тестване без прекъсване. Всяка сесия може да има следната продължителност:
    • „Кратко“ (60 минути)
    • 'Нормално' (90 минути)
    • „Дълго“ (120 минути)
  • Доклад за сесията: Включете бележки и лек доклад, за да предоставите показатели на лидерите и мениджърите. Той дава подробности за оставащата или извършена чартърна сесия, време за настройка на сесията, тестван сценарий, за процеса на тестване, списък с грешки и намерени проблеми и друга информация за показателите.
  • Обобщение на сесията: Кратка среща или изправяне между тестера и ръководителя на теста / мениджъра за преглед на резултатите от тестовата сесия.

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

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

За да обобщим горното:

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

Двойно изследователско тестване

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

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

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

Предимства на тестване на двойки

  • Помага на тестера да се съсредоточи върху разглежданата задача.
  • Насърчавайте взаимното доверие и уважение сред партньорите.
  • Мозъчната атака между сдвоени тестери обикновено води до по-конструктивни идеи.
  • Избягвайте тунелното зрение.
  • Има по-малък шанс другите да ги прекъснат.

Техники за изследователско тестване

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

Туристът може да предприеме следните обиколки:

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

Докато правите обиколка, винаги имате избор да вземете всеки маршрут. Можете да навигирате през софтуера и да намерите уникален път за тестване на функцията.

По-долу са дадени някои съвети / трикове, които можете да използвате в ET:

  • Разделете приложението на модули и разделете модулите на различни страници. Започнете вашия ET от страниците. Това ще даде правилното покритие.
  • Направете контролен списък с всички функции и поставете отметка, когато това е покрито.
  • Започнете с основен сценарий и след това постепенно го подобрете, за да добавите още функции, за да го тествате.
  • Тествайте всички полета за въвеждане.
  • Тест за съобщението за грешка
  • Тествайте всички негативни сценарии.
  • Проверете GUI спрямо стандартите.
  • Проверете интеграцията на приложението с други външни приложения.
  • Проверете за сложна бизнес логика.
  • Опитайте се да направите етично хакване на приложението.

Факторите, които влияят върху ЕТ, са както следва:

  • Целта на проекта
  • Стратегия за тестване
  • Целта на теста на определена фаза
  • Налични инструменти и съоръжения
  • Роля и умения на тестерите
  • Свободно време
  • Подкрепа за управление
  • Подкрепа от връстници
  • Налични ресурси (учебни материали, условия за изпитване и т.н.)
  • Интерес на клиентите
  • Разбираемост на продукта.
  • Потребителският интерфейс на приложението
  • Функционалността на приложението
  • Предишни резултати от теста
  • Рискове, свързани с приложението
  • Предишни дефекти
  • Последни промени
  • Видове данни, които да се използват за тестване
  • Тип потребител, който ще го използва

Вместо да питаме тестерите какво да изпълняват, ние оставяме на преценката на тестера да реши какво искат да тестват и как искат да тестват.

Разлика между изследователско тестване и ad hoc тестване

Не бъркайте ET с Ad-hoc тест .

  • Ad-hoc тестването се отнася до процес на нескриптирано, непланирано и импровизирано търсене на дефекти, докато изследователското тестване е обмислена методология за Ad hoc тестване.
  • Ad-hoc тестването е хитов и пробен метод за намиране на грешка, докато ET не е така. При подхода на ЕТ тестерът научава за системата, докато те изследват и евентуално развиват тестовете, използвайки придобитите знания.
  • Ad-hoc тестването е неструктурирана дейност, докато ET е донякъде структурирана дейност.

Изследователски автоматизирани тестове (EAT)

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

Има два типа EAT подход:

  • Пасивно ЯДЕТЕ
  • Активно ядене

Пасивно ЯДЕТЕ

Пасивното ядене може да се извършва от един тестер или също по двойка. В тази методология обикновено се използва инструмент, който улавя и записва всяка отделна дейност, извършена от тестващ ресурс (и) и се инсталира на компютъра на ресурса.

Пасивното EAT е подобно на ET, което се извършва ръчно, тъй като няма промяна в начина, по който се изпълняват тестовете, освен създаването на резултата от теста въз основа на уловената сесия. Тези резултати от теста могат да се използват за докладване и възстановяване на записани действия по-късно във времето.

Инсталираният видеоинструмент помага на тестер при запис на тестови случаи и докладване на дефекти.

Той има и няколко други предимства като:

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

Ето няколко други точки, които трябва да се вземат предвид преди пасивното ядене:

  • Препоръчително е да извършите пилотен тест, преди да адаптирате напълно инструмента за автоматизирано ядене. Това е да се гарантира, че времето, необходимо за препроектиране на тестовите дневници, създадени по време на тестовата сесия, не е повече от изпълнението на теста. Ако е така, тогава екипът трябва да вземе взаимно решение относно следното:
    • Ако изобщо се изисква автоматизация на теста за конкретния проект.
    • Ако използваният инструмент трябва да бъде променен.
    • Ако ефективността на използвания инструмент може да бъде оптимизирана.
  • Инструментът, използван за извършване на автоматизирано EAT, трябва да бъде инсталиран на всеки ресурс за тестване, участващ в тестването. Също така е добра идея да включите разработчиците, което може да бъде постигнато чрез предоставяне на разработчиците VPN или отдалечен достъп до тестови машини или чрез инсталиране на инструмента в средата за разработка.
  • Винаги е добра идея да имате GUI обект на приложението, организиран в тестовия инструмент, така че когато дойде време за анализ на грешката или проблем, обектът да бъде разпознаваем поради значимо име.
  • Страхотна практика е да давате смислено име на GUI обекта, използван в AUT, и да ги поддържате организирани за по-късна употреба.

Сега да преминем към втория подход.

Активно ядене

Препоръчително е да се извърши Active EAT с тестване на двойки. При този подход тестването с ключови думи се използва в синхрон с тестване на сесия. Единият тестер създава автоматизирания тестов скрипт, а вторият тестващ изпълнява тестовите скриптове, създадени от първия тестер.

Създаването на скриптове за тестове за автоматизация при този подход заема различен път от този при конвенционалното тестване. По време на тестването се правят автоматизирани тестови скриптове и това, което е открито в предишните тестове, определя техния дизайн.

Фаза на затваряне се изпълнява в края на тестовата сесия. И трябва да има следните задачи:

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

Предимства на EAT

  • В началото на всяка сесия се изпълняват вече създадени автоматизирани тестови скриптове, като по този начин се подобрява тестовото покритие всеки път.
  • По-добро докладване на грешки и документация за възпроизвеждане на дефекти.
  • EAT предоставя достатъчно доказателства и документация, за да може заинтересованата страна да види напредъка.

Видове изследователски изпитвания

По-долу са дадени няколко вида ET:

1) Свободен стил И:

Проучване на приложението в ad-hoc стил.

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

2) ET базиран на сценарий:

Както подсказва самото име, извършените тестове са базирани на сценарии. Започва с реални потребителски сценарии, сценарии от край до край или тестови сценарии. След първоначалното тестване тестерите могат да инжектират вариации според своето обучение и наблюдение.

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

3) Стратегиябазирани ET:

Известни техники за тестване като анализ на гранична стойност, техника на еквивалентност и техника, базирана на риска, които се комбинират с изследователски тестове. За този тип тестване се назначава опитен тестер или тестер, който е запознат с приложението.

Пъргаво изследователско тестване

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

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

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

Предимства на изследователската работа в Agile

  • Доказване на обратна връзка с разработчиците възможно най-скоро.
  • Разкрити са по-голямо разнообразие от дефекти.
  • Разнообразна група от ресурси като разработчик, тестер, BA, дизайнери могат да изпълняват ET, тъй като няма скриптове за тестване и всеки носи различна перспектива.
  • Скаутирането, направено в ET, помага за проучване на нови територии и излагане на критични грешки.
  • В случай на повторно кодиране на приложение, ET може да се съсредоточи върху тестване на нови функции, докато автоматизацията прави регресия и тестване за обратна съвместимост.
  • В случай на нестабилно изискване, ET може да помогне за тестване на ново изискване в рамките на ограничен период от време.

Точки за запомняне:

1. Изисква различни умения: Тестерите, извършващи ЕТ, трябва да имат добри умения за слушане, четене, мислене и докладване. Необходим е опит с домейн, тъй като няма скриптове и тестови случаи.

2. Понякога е трудно докладвайте за грешка: Докато сме в ET поток, може да срещнем дефект, но може да не успеем да го възпроизведем. Това е така, защото не проследяваме стъпките за тестване и може да забравим точните стъпки за възпроизвеждане на този проблем.

3. Може да се извършва като развлекателна дейност: Аз лично правя ET, когато искам почивка от моя редовен цикъл на изпълнение на теста. Но много отбори имат ET като отделна фаза от техния цикъл на тестване.

4. Може да се направи за всички фази на тестване: Можем да приложим ET преди началото на всяка фаза на тестване. Можете да извършите ET дори преди фаза на функционално тестване.

5. Бърза обратна връзка: ET изисква бърза обратна връзка по проблемите и възникналите аномалии.

6. Критично мислене и разнообразни идеи: Това тестване изисква критично мислене. Тестерите трябва да могат да възпроизвеждат, преглеждат и изразяват своите идеи по логичен начин. Тестерът може да внедри своя опит в различните технологии и области, върху които са работили.

Как да мислим отвъд традиционните граници на тестване в изследователското тестване

„Наистина оценявам загрижеността ви за продукта и ни помагате в разбирането на перспективата за крайния потребител. Ще бъде много полезно. Благодаря за добрата работа и продължете така !!! ”

Това беше последният имейл на имейл верига с 21 имейла от нашия клиент. Беше полунощ и пускането на нашия продукт се забави поради критична грешка, която открихме. Може би си мислите, какво ново има в това? Може да се случи много пъти. Но това беше наистина различно, тъй като критичната грешка, за която съобщихме, не е резултат от документиран тестов случай.

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

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

Като фен на изследователските тестове, обичам да изследвам продукта по различни начини. За мен дефиницията на софтуера е:

„Трябва да прави това, което трябва да прави, и не трябва да прави това, което не би трябвало да прави.“

как да сортирам масив от цели числа в java

Процес на изследователско тестване

Ограничаването на границите на тестване, за да проверите дали продуктите, които трябва да работят, ви прави непълен тестер. Всъщност животът на тестера започва, когато документираното тестване за регресия приключи и резултатите се актуализират. Разглеждането на продуктите от различни гледни точки и разбирането на изискванията на крайните потребители в различните сценарии имат голямо значение. Така че днес, нека да разберем заедно, как може да се направи тази разлика:

Как да гледаме на продукт от различни гледни точки?

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

# 1. Разберете клиент / краен потребител

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

Като софтуерен тестер трябва да проверим целта на продукта, а не обекта или аспекта му.

Позволете ми да ви дам няколко реални практически примера:

  • Ножиците никога не са били ограничени само до изрязване на хартия. Рязането е целта, а не хартията (обектът).
  • Клетъчните телефони никога не са били ограничени само до разговори, но „способността да се обаждате“ винаги е била основната цел.
  • Кутиите за съхранение се използват за съхранение, но безопасността на съхранявания материал е също толкова важна, колкото и съхранението.

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

# 2. Мислене

Докато търсите (да кажем) обява за работа за работа, виждате ли този джакпот и между страниците с удебелен шрифт? Повечето от нас не го правят (повярвайте ми, вярно е). Защото сме инструктирали ума си да търси полезното или да бъде проверено. Всичко друго няма полза, така че умът ни отрича да го разпознаваме.

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

Спомням си един класически пример:

В Linux командата ‘cat’ се използва за проверка на съдържанието на файл, а командата ‘ls’ - за проверка на съдържанието на директорията. Работейки с Linux и в продължение на пет години в тестване на софтуер, никога не съм мислил да се занимавам с котки, защото ми е нагласен умът; ако имах нужда от дир съдържание, трябва да използвам „ls“. Това работи, но обратната страна на очакванията е, че продуктът не трябваше да се държи по начина, по който не трябваше, беше погрешно. Един от нашите клиенти, който не познаваше добре Linux, погрешно направи котка и системата се срина. Платихме за това мислене.

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

Помислете за тези сценарии и предоставете обратна връзка за тестване. Животът на софтуера и на вашия (като тестер) ще се разтърси.

# 3. Познавайте състезателите

Докато тествате някакво софтуерно приложение за вашия клиент, опитвали ли сте се да познавате и разбирате друг софтуер със същата цел? Предлагали ли сте някога полезна функционалност, която сте наблюдавали в продукта на конкурента? Това не попада в нашата длъжностна характеристика, е типичният отговор. Но знаете ли ползата от това?

Ето няколко примера от реалния живот, които да ви накарат да разберете смисъла:

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

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

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

Заключение

Експлораторът не се подлага на конвенционален начин за тестване, но все пак е много мощен начин за тестване.

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

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

Наложително е да запомните, че ET е по-скоро адаптивен, отколкото предсказващ процес и е от съществено значение да се поддържа здравословен баланс между изследователски и скриптов или редовен тест.

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

Следващ урок # 2: Как да използваме обиколки, за да осигурим цялостно изследователско тестване

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

^