Калі аўтаматызаваць гісторыі карыстальнікаў?

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

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



Паўтаральнасць

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




Надзейнасць

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



Час

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




Ахоўная сетка

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





Калі гісторыі павінны быць аўтаматызаваны?

Скажам, у звычайным спрынце ёсць 7 гісторый, прысвечаных спрынту, з якіх 5 з'яўляюцца добрымі кандыдатамі для аўтаматызацыі на аснове вышэйзгаданых крытэрыяў. Але калі лепшы час для аўтаматызацыі гэтых гісторый? Ці варта пісаць аўтаматызаваныя тэсты па меры распрацоўкі функцый? Ці варта пачакаць, пакуль функцыя будзе распрацавана, а потым напісаць аўтаматызаваныя тэсты? Пачакаем да канца спрынту, а потым аўтаматызуем гісторыі?

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

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


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

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

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

Некаторыя арганізацыі нават навязваюць строгае правіла, паводле якога гісторыя не «робіцца», пакуль яна не будзе цалкам аўтаматызавана! Ці збіраемся мы спыніць важную функцыю, якая будзе выпушчана, таму што кантроль якасці не мог альбо не мог своечасова забяспечыць аўтаматызацыю па розных прычынах? Або гісторыя не 'зроблена', таму што ў нас няма аўтаматызаванага сцэнарыя для праверкі наяўнасці кнопкі на старонцы. Сур'ёзна?


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

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