Як пераадолець спрытныя выпрабаванні

Якія найбольш часта сустракаюцца праблемы гнуткага тэсціравання, з якімі сутыкаюцца тэстары праграмнага забеспячэння або кантроль якасці ў гнуткіх праектах? Як гэта быць QA ў спрытнай камандзе?

З тых часоў, як у распрацоўцы праграмнага забеспячэння былі ўведзены гнуткія метадалогіі распрацоўкі, роля кантролю якасці ў гнуткіх праектах значна змянілася. Гэта больш не каманда кантролю якасці седзячы ў куце, далей ад распрацоўшчыкаў і дызайнераў, чакаючы, пакуль каманда распрацоўшчыкаў перадасць працу для тэставання.

Адным з найбольш важных элементаў кантролю якасці ў гнуткіх праектах з'яўляецца добрае разуменне гнуткіх метадалогій і працэсаў распрацоўкі. Шмат спрытных кампаній прытрымліваюцца рамак Scrum для пастаўкі якаснага праграмнага забеспячэння, таму пераканайцеся, што вы знаёмыя з Scrum.




Выклікі тэставання Agile

Сама сутнасць спрытнага развіцця частая пастаўка працоўнага праграмнага забеспячэння , кожны раз дадаючы альбо паляпшаючы невялікую функцыю, якая ўяўляе каштоўнасць для кліента. Гэта само па сабе стварае вялікую праблему не толькі для тэсціроўшчыкаў, але і для распрацоўшчыкаў, а таксама для ўсіх, хто ўдзельнічае ў дастаўцы прыкладанняў.

У гэтым артыкуле я пералічваю некаторыя найбольш распаўсюджаныя выклікі тэсціравання кантролю якасці ў гнуткіх праектах і спосабы іх пераадолення.


Змена патрабаванняў / змены ў апошнюю хвіліну

Змена патрабаванняў альбо падзенне гісторый у сярэдзіне спрынту не рэдкасць у гнуткіх праектах. Гэта можа стаць кашмарам для ўсёй каманды, бо гэта азначае, што ўжо праведзеная праца можа быць цалкам скасавана альбо неабходна ўнесці змены ў тое, што ўжо зроблена напалову.



Гэтыя змены патрабаванняў і запыты ў апошнюю хвіліну могуць паўплываць на аб'ём тэсціравання, што можа сарваць тэстараў.

Як пераадолець:

Тэсціроўшчыкі павінны мець магчымасць рэагаваць на змены, ведаючы, што ў гнуткіх праектах змены непазбежныя. Калі патрабаванні мяняюцца асабліва да канца спрынту, калі для адэкватнага тэсціравання не хапае часу, тэстыроўшчыкі павінны прадаставіць як мага больш інфармацыі пра тое, якія тэсты былі праведзены і якая частка прыкладання не была праверана добра, каб каманда можа прыняць абгрунтаванае рашэнне (магчыма, зыходзячы з рызыкі), выпускаць функцыю ці не.


Паспрабуйце таксама прыцягнуць распрацоўшчыкаў да тэсціравання, бо тэсціраванне і якасць павінны ляжаць на ўсёй камандзе.

Не хапае інфармацыі пра гісторыю

Бываюць выпадкі, калі ўладальнік прадукту, які піша гісторыі карыстальнікаў, мае нейкае ўяўленне пра новую функцыю, але не мае ўсіх дэталяў, каб напісаць добры набор крытэрыі прыёмкі для поўнага вызначэння паводзін функцыі. Яны просяць каманду распрацоўшчыкаў стварыць прататып, каб яны маглі атрымаць больш уяўленняў аб функцыянальнасці і паводзінах функцыі.

Гэта стварае праблемы для тэсціроўшчыкаў, бо не хапае разумення і патрабаванняў, таму нельга стварыць належныя тэставыя прыклады.

Як пераадолець:


Вам не патрэбныя вельмі падрабязныя патрабаванні, каб пачаць тэставанне, таму пачніце з разважанняў пра сцэнарыі высокага ўзроўню, якія правяраюць канцэпцыю гісторыі, а не чакаць, каб атрымаць поўнае тлумачэнне аб функцыі. Пры складанні сцэнарыяў выпрабаванняў высокага ўзроўню, нават калі дэталі змяняюцца, кантэкст усё роўна павінен быць нязменным.

Бесперапыннае тэсціраванне

У спрытным рэжыме тэставанне - гэта не фаза, гэта дзейнасць. Тэставанне пачынаецца з самага пачатку, яшчэ да пачатку распрацоўкі.

Для бесперабойнай язды падчас спрынту гісторыі падчас адставання павінны былі быць распрацаваны падчас сеансаў грумінгу. Гэта азначае, што служба якасці павінна супрацоўнічаць з уладальнікамі прадуктаў, каб даведацца падрабязнасці гісторыі, а потым дапамагчы напісаць добрыя крытэрыі прыняцця.

Ранняе прадастаўленне водгукаў распрацоўшчыкам вельмі важна і складана для тэстараў. Як тэсціроўшчыкі, мы не толькі павінны пераканацца, што новая функцыя працуе ў адпаведнасці з крытэрыямі прыняцця, мы павінны таксама пераканацца, што новы код не парушае існуючую функцыянальнасць, гэта значыць, мы не рэгрэсавалі і каб хутка даць гэтую інфармацыю.


Як пераадолець:

Перад пачаткам працы над распрацоўкай пераканайцеся, што кожная гісторыя мае адэкватныя крытэрыі прыняцця і каб усе добра разумелі кантэкст гісторыі.

Пачніце ствараць тэсты (аўтаматызаваныя або ручныя) як мага хутчэй, каб, калі функцыя стане даступнай для тэставання, вы маглі пачаць адразу.

Тэстары павінны заахвочваць распрацоўшчыкаў даваць магчымасць бачыць функцыю на ранніх тэрмінах, рэгулярна разгортваючы яе ў тэставай асяроддзі, дзе тэсціроўшчыкі і / або ўладальнікі прадуктаў могуць запускаць свае тэсты, а не чакаць, пакуль функцыя завершыцца перад тэставаннем.


Аўтаматызуйце рэгрэсійныя тэсты, каб палегчыць некаторыя намаганні і вызваліць час на пошукавыя выпрабаванні.

Тэхнічныя навыкі / Аўтаматызацыя выпрабаванняў

Праца ў гнуткім асяроддзі азначае, што тэсціроўшчыкі павінны быць тэхнічна кампетэнтнымі, каб дапамагчы распрацоўшчыкам у тэставанні інтэграцыі і тэсціраванні API, а таксама правядзенні сцэнарыяў праверкі аўтаматызацыі карыстацкага інтэрфейсу з дапамогай селену альбо аналагічнага інструмента.

Калі выпрабавальнікі атрымліваюць выключна ручную або пошукавую гісторыю, ім будзе складана ісці ў нагу з тэмпамі дастаўкі, паколькі ім трэба праверыць на пастаянным тэсціраванні.

Тэставанне прадукцыйнасці таксама важна, асабліва для вэб-прыкладанняў, каб гарантаваць, што прыкладанне можа вытрымліваць вялікую нагрузку ў час пік. Калі ў вашай кампаніі няма спецыяльнага тэстара прадукцыйнасці, чакаецца, што функцыянальныя тэстары таксама будуць удзельнічаць у тэставанні прадукцыйнасці.

Як пераадолець:

Пачніце з вывучэння некалькіх моў сцэнарыяў альбо праграмавання, такіх як Ruby і Java - гэта самыя папулярныя мовы ў супольнасці тэхнічнага тэсціравання.

Калі вы ўжо знаёмыя з праграмаваннем, і вы затрымаліся, звярніцеся за дапамогай да распрацоўшчыкаў.

Інструмент селен - самы папулярны інструмент тэсціравання аўтаматызацыі браўзэраў, таму, калі праект заснаваны на Інтэрнэце, добрае веданне інструмента - гэта вялікая каштоўнасць.

JMeter - гэта яшчэ адзін выдатны інструмент, пра які можна ведаць. Гэта інструмент тэсціравання прадукцыйнасці з адкрытым зыходным кодам і адносна просты ў засваенні, таму запампуйце яго і пачніце гуляць з некаторымі яго асаблівасцямі.

Некалькі браўзэраў / некалькі прылад

У наш час архітэктура многіх вэб-сайтаў складаецца з 'інтэрфейсу' і 'інтэрфейсу'. Пачатковая частка ў асноўным заснавана на JavaScript і CSS, якія патэнцыйна могуць паводзіць сябе па-рознаму пры праглядзе з розных браўзэраў і прылад.

Забеспячэнне таго, каб вэб-сайт працаваў належным чынам ва ўсіх асноўных браўзэрах і папулярных мабільных прыладах альбо планшэтах, сапраўды з'яўляецца галоўнай задачай для тэстараў у гнуткіх праектах.

Як пераадолець:

Тут важная аўтаматызацыя. Самае лепшае ў аўтаматызацыі напісанне тэсту і яго запуск у некалькіх браўзэрах.

Вы можаце выкарыстоўваць селену сетку с Докер кіраваць і запускаць аўтаматызаваныя тэсты паралельна ў некалькіх браўзэрах.

Яшчэ адзін выдатны інструмент для тэсціравання некалькіх браўзэраў BrowserSync .

Сувязь

Незалежна ад таго, наколькі добры працэс праходзіць альбо наколькі якасна выконваюцца вышэйпералічаныя элементы, пры недахопе сувязі паміж членамі каманды альбо з уладальнікамі прадуктаў, дызайнерамі і г. д. Нічога не атрымаецца.

Як пераадолець:

Пераканайцеся, што каманда падтрымлівае эфектыўную камунікацыю. Узаемадзейнічайце з распрацоўшчыкамі і ўладальнікамі прадуктаў на пастаяннай аснове.

Пераканайцеся, што існуе працэс і што кожны член каманды прытрымліваецца гэтага працэсу. Даволі часта асноўныя праблемы альбо памылкі не выяўляюцца на ранніх тэрмінах, паколькі працэс не выконваўся, і каманда не магла мець зносіны паміж сабой.