context driven testing
7 основних принципа контекстуалног тестирања са примером:
љуска скрипта за упоређивање две датотеке
Када се возим до аеродрома, обично идем аутопутем којим ћу стићи тамо за минимално време и избегавам путарину. Али тог дана кренуо сам дужим путем локалног пута са путарином. Зато што сам желео неколико додатних минута са пријатељем у вожњи, који је путовао на велику удаљеност да проведе викенд са нашом породицом. У овом случају се показало да је најбољи најгори избор.
Али, узмите у обзир ово.
Шта ако бих имао мало горива?
Шта ако бих имао мало новца?
Ја бих изабрао другачију опцију. Зашто? Контекст.
(слика кредит )
Када доносите одлуке на основу, то је одлука заснована на контексту:
- Укључени људи
- Околности
- Циљеви
- Доступне опције
- Емоције итд.
Дакле, шта је тестирање засновано на контексту?
Тестирање засновано на контексту је промена начина размишљања (или Школа тестирања) коју су развили Цем Канер, Јамес Бацх и Брет Петтицхорд. Детаље о томе можете пронаћи у њиховој познатој књизи: Лекције научене из тестирања софтвера .
Постоји 7 основних принципа. Следеће је директно одабрано из њихове књиге:
# 1) Вредност сваке праксе зависи од њеног контекста.
#два) У контексту постоје добре праксе, али нема најбољих пракси.
# 3) Људи, који раде заједно, најважнији су део контекста било ког пројекта.
# 4) Пројекти се временом одвијају на начине који често нису предвидљиви.
# 5) Производ је решење. Ако проблем није решен, производ не ради.
# 6) Добро тестирање софтвера изазовни је интелектуални процес.
# 7) Само расуђивањем и умећем, које се заједнички спроводе током целог пројекта, у могућности смо да урадимо праве ствари у право време како бисмо ефикасно тестирали своје производе.
Нећу објашњавати сваког од њих, јер то за нас чини сами стручњаци овде .
Једноставно ћу направити објашњење засновано на сценарију мог става о тестирању заснованом на контексту.
Пример тестирања на основу контекста:
Рецимо да започињем пројекат тестирања - пројекат А који укључује тестирање од краја до краја за веб-апликацију.
Која би била моја стратегија?
уређаји оси модела користе сваки слој
Према стандардним процесима, ово ће бити редослед догађаја:
- Прикупите захтеве и разумејте апликацију
- Направите тест план
- Направите тест документацију - Тест сценарији, Тест случајеви, Матрица сљедивости итд.
- Нека се сва документација прегледа и одобри
- Подесите КА окружење и тест податке
- Извршите тест извршавање
- Направите извештаје о грешкама
- Генеришите и делите извештаје о статусу извршења теста итд.
Ако себи поставим питање: „Како сам закључио да ово треба да радим?“ Мој одговор би био, најбоља пракса, стандарди квалитета, смернице за индустрију, основне претпоставке из претходног искуства итд., Зар не?
Понављам оно што сам научен да радим или оно што сам видео да други раде.
Сад, да ли нешто није у реду с тим? Нимало. Ово би чак могло и упалити, јер постоји одређени осећај поновљивости и временске провере овог приступа. Међутим, да ли то отвара пут за оптималне резултате?
Сумњиво. Зашто?
Јер са сваким пројектом суочићете се са различитим околностима:
- Документирани и недокументирани захтеви
- Тимови који уско раде у односу на географски распоређене тимове
- Тимови за развој и тестирање који припадају истој компанији у односу на конкуренцију
- Довољно времена вс. Збијени распореди
- Састав вашег тима - Новопридошли против искусних. Обучени наспрам необучених.
- Доступност алата - Приручник у односу на употребу алата за управљање тестом
- Тип пројекта - Потребно је стриктно придржавање правила (ФДА или банкарство) насупрот експерименталним (попут друштвених медија)
- Технологија пројекта.На пример:не бисте тестирали веб и Виндовс апликацију на исти начин
- Захтеви клијената (Неки желе дневне детаљне извештаје, неки само најважније)
- Процес је следен (агилно наспрам традиционалног, скриптирано насупрот истраживачком тестирању)
Ова листа није исцрпна и знате као и ја да постоји много променљивих за сваки пројекат.
Контекстуално тестирање је када овим околностима допуштате да одлуче о вашим праксама, техникама, па чак и дефиницијама, а не о стандардним, индустријским перцепцијама најбоље праксе' .
Рецимо сада, ово су детаљи са којима радим на пројекту А:
- Радим са тимом од 5 - 4 новајлије и 1 искусним тестером.
- Немам документоване захтеве.
- Мој тим је у Индији, а развојни тим у САД-у, тако да радимо у супротним временским зонама.
- Клијент жели дневни детаљни извештај о статусу
- Користимо веб алатку за праћење грешака, као што су Мантис или Бугзилла, и то је све што имамо.
- Морам да обавим 2 круга тестирања за 10 дана са 3 дана за документацију о испитивању
Ево грубог плана игре:
1) Будући да је у тиму пуно новака, треба нам пуно рецензија.
два) Такође су нам потребна најмање 2 састанка за дискусију са БА и развојним тимом. Ово мора бити формално, јер су тимови лоцирани негде другде и мало ми је простора да одем до њих са питањима.
3) То је агресиван временски оквир за тестирање документације. Што више документације напишемо, више рецензија нам треба, што се изједначава са више времена. Дакле, мораћемо да водимо минималну документацију. Ми ћемо документовати само главно Енд-то-Енд ТЦ-ови а остало ће бити тестирано истраживачким путем .
4) Дневни извештаји о статусу током извршавања теста креираће се и слати ЕОД-у сваког дана.
5) Већина тестирања је истраживачка, па саветујте време да покушате да направите кратки преглед сваког извршеног теста. На овај начин знамо шта се тестира, а шта не.
6) Кварови ће се пријављивати у Мантису у реалном времену. Будући да тим ради у другој временској зони, можда ће морати да сачекају цео дан пре него што се чују са КА тимом, у случају да им затреба појашњење. Стога, успоставите свакодневни позив са прикладним тимом, где ће КА тим демонстрирати рекреацију грешака. На тај начин неће бити потребе за чекањем или праћењем.
И тако даље.
Једном када направите општу стратегију, напишите основни план испитивања који ће објаснити ове тачке. Сада сте спремни за улазак у пројекат тестирања након пажљивог разматрања и прилагођене стратегије успеха.
Укратко:
Ово је Тестирање на основу контекста; чинећи ваше околности (а не стандарде) примарним инпутима и утицајима за вашу стратегију тестирања. Подстиче нас да се осврнемо и узмемо у обзир све око себе.
Лично сам заљубљен у овај концепт јер се пречесто праксе тестирања доживљавају као круте и засноване на имитацији. Неко је то учинио и био је успешан, па ћу и то учинити. Ово је врста слике која плаши људе да покушају и остану у тестној каријери.
Али, довољно је простора за креативно размишљање, аналитичке вештине и доношење одлука. Да бисте сазнали више, прочитајте тему на горе наведеним везама.
Срећно тестирање засновано на контексту
Препоручено читање
- Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
- Преузимање е-књиге за тестирање буквара
- 20 једноставних питања за проверу софтвера за тестирање основног знања (мрежни квиз)
- 7 основних савета за тестирање вишејезичних веб локација
- Испитивање оптерећења помоћу ХП ЛоадРуннер водича
- Разлика између тестирања радне површине, клијентског сервера и веб тестирања
- Шта је гама тестирање? Завршна фаза испитивања
- Шта је испитивање усаглашености (испитивање усаглашености)?