Меню

Контекстно управлявано тестване: 7 основни принципа с пример

context driven testing

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

7 основни принципа на контекстуално тестване с пример:

топ 10 шпионски приложения за android

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

Но помислете за това.

Ами ако бях с малко бензин?

Ами ако нямах пари в брой?

Бих избрал различния вариант. Защо? Контекстът.

Какво представлява тестването, управлявано от контекста

(изображение кредит )

Когато вземате решения въз основа на, следното е решение, основано на контекста:

  • Участващите хора
  • Обстоятелства
  • Цели
  • Налични опции
  • Емоции и т.н.

И така, какво е тестването, управлявано от контекста?

Контекстното тестване е промяна в начина на мислене (или Училище за тестване), разработена от Cem Kaner, James Bach & Bret Pettichord. Подробности за него можете да намерите в известната им книга: Уроци, научени от тестването на софтуер .

В него има 7 основни принципа. Следното се избира директно от тяхната книга:

# 1) Стойността на всяка практика зависи от нейния контекст.

# две) В контекста има добри практики, но няма най-добри практики.

# 3) Хората, които работят заедно, са най-важната част от контекста на всеки проект.

# 4) Проектите се развиват с течение на времето по начини, които често не са предвидими.

# 5) Продуктът е решение. Ако проблемът не е решен, продуктът не работи.

# 6) Доброто тестване на софтуера е предизвикателен интелектуален процес.

# 7) Само чрез преценка и умения, упражнявани съвместно през целия проект, ние можем да правим правилните неща в точното време, за да тестваме ефективно нашите продукти.

Няма да обяснявам всеки един от тях, защото това се прави за нас от самите експерти тук .

Просто ще направя обяснение, базирано на сценарий, на моето мнение за контекстно тестване.

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

Да кажем, че стартирам проект за тестване - Проект А, който включва тестване от край до край за уеб базирано приложение.

Каква би била моята стратегия?

Според стандартните процеси това ще бъде последователността на събитията:

  • Съберете изискванията и разберете приложението
  • Създайте план за тест
  • Създаване на тестова документация - Тестови сценарии, Тестови случаи, Матрица за проследяване и др.
  • Нека цялата документация бъде прегледана и одобрена
  • Настройте QA среда и тестови данни
  • Изпълнете тестово изпълнение
  • Създайте отчети за грешки
  • Генерирайте и споделяйте отчети за състоянието на изпълнението на теста и др.

Ако си задам въпроса: „Как реших, че това е, което трябва да правя?“ Моят отговор би бил, най-добри практики, стандарти за осигуряване на качеството, насоки за индустрията, изходни данни от миналия опит и т.н., нали?

Повтарям това, което съм научен да правя или това, което съм виждал да правят други.

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

Съмнително. Защо?

Защото с всеки проект ще се справяте с различни обстоятелства:

  • Документирани срещу недокументирани изисквания
  • Тесно работещи срещу географски разпределени екипи
  • Екипи за разработка и тестване, принадлежащи на една и съща компания срещу конкуренция
  • Достатъчно време срещу Тесни графици
  • Съставът на вашия екип - Новодошли срещу опитни. Обучени срещу нетренирани.
  • Наличност на инструменти - Ръководство срещу използване на инструменти за управление на тестове
  • Тип на проекта - Необходимо е стриктно спазване на правилата (FDA или банково дело) срещу експериментални (като социалните медии)
  • Технологията на проекта.Например:не бихте тествали мрежата и приложението за Windows по същия начин
  • Изисквания на клиентите (Някои искат ежедневни подробни отчети, други искат само акцентите)
  • Следван процес (пъргав срещу традиционен, сценарий срещу изследователско тестване)

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

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

основни Java програми, зададени в интервюта

Нека да кажем, че това са подробностите, с които работя за Проект А:

  • Работя с екип от 5- 4 новодошли и 1 опитен тестер.
  • Нямам документирани изисквания.
  • Екипът ми е в Индия, а екипът за разработки - в САЩ, така че работим в противоположни часови зони.
  • Клиентът иска ежедневен подробен доклад за състоянието
  • Използваме уеб базиран инструмент за проследяване на грешки, като Mantis или Bugzilla и това е всичко, което имаме.
  • Трябва да направя 2 кръга тестове за 10 дни с 3 дни за тестова документация

Ето груб план за игра:

1) Тъй като в екипа има много новодошли, имаме нужда от много партньорски проверки.

2) Също така се нуждаем от поне 2 срещи за дискусии с изисквания с екипа на BA и Dev. Това трябва да е формално, тъй като екипите са разположени другаде и нямам много възможности да отида да отида до тях с въпроси.

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

4) Ежедневните отчети за състоянието по време на изпълнението на теста ще се създават и изпращат EOD всеки ден.

5) Повечето тестове са изследователски, така че посъветвайте времето да се опитате да направите кратко описание на всеки изпълнен тест. По този начин знаем какво е тествано и кое не.

6) Дефектите ще бъдат докладвани в реално време в Mantis. Тъй като екипът работи в различна часова зона, може да се наложи да изчакат цял ​​ден, преди да се чуят от екипа за QA, в случай че се нуждаят от разяснения. Затова организирайте ежедневен разговор с удобен екип, където екипът за QA ще демонстрира развлечението на бъговете. По този начин няма да има нужда от чакане или последващи действия.

И така нататък.

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

В обобщение:

Това е Контекстно управлявано тестване; превръщайки вашите обстоятелства (а не стандартите) в основни фактори и фактори, влияещи на вашата тестова стратегия. Настоява ни да се огледаме и да вземем предвид всичко около вас.

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

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

Честито контекстно-управлявано тестване

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

^