Праблемы з аўтаматызацыяй тэстаў і сучасным кантролем якасці

Якія агульныя праблемы аўтаматызацыі тэстаў у Agile і DevOps?

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

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


Нядаўна я наткнуўся на паведамленне ў сетцы сацыяльных сетак, дзе гаворыцца

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


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



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

У UAT карыстальнікі знаходзяць усё новыя і новыя памылкі, таму што тэставыя групы не могуць іх ідэнтыфікаваць на папярэдніх этапах.

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


І мая інтэрпрэтацыя ... гэта 'дрэнь'. :-)

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



Праблемы з сучасным кантролем якасці

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

нататка:Пад тэставай аўтаматызацыяй я ў асноўным маю на ўвазе ЦЫБУЛЬ Аўтаматызацыя выпрабаванняў.

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


Ці правяраюць тэсцеры ўсё яшчэ?

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

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

Часта можна пачуць такія рэчы, як: 'Я 100% інжынер па аўтаматызацыі', '80% аўтаматызацыі, 20% уручную', ці нават горш: 'Я ненавіджу ручное тэсціраванне'. Шакуе!

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


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

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

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

Зніжэнне ручнога тэсціравання

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


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

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

нататка:Пры ручным тэставанні я НЕ спасылаючыся на стары школьны спосаб выканання сцэнарыя і выканання этапаў. Я маю на ўвазе так званых 'даследчых выпрабавальнікаў' - тых, хто праводзіць сапраўднае тэсціраванне і цікавіцца вывучэннем паводзін сістэмы, ажыццяўляючы цікавыя і прадуманыя сцэнарыі.

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



Праблемы з аўтаматызацыяй тэстаў

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

Тыповыя памылкі, якія я бачу паўтарацца:

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

Няправільныя чаканні

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

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

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

Няправільны пласт, няправільныя інструменты і няправільны час

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

Сучасныя вэб-прыкладанні ў цяперашні час выразна падзелены на бэкэнд і інтэрфейс. Бэкенд у асноўным складаецца з шэрагу вэб-сэрвісаў REST і API з лёгкадаступнымі канчатковымі кропкамі.

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

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

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

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

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

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

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

Аўтаматызацыя бескарысных тэстаў

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

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

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

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

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

Таму кожны раз, праводзячы аўтаматызацыю 'тэсту', думайце пра час, які вы марнуеце, не тэстуючы!

Грэбаванне важнымі напрамкамі

Я бачу ўсё больш і больш гэтай нядбайнасці з моманту нараджэння культуры DevOps.

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

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

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

Мы проста прымаем іх як частку сучаснай пастаўкі праграмнага забеспячэння.

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

Адсутнічаюць ключавыя сцэнарыі

Сцэнарыі - гэта цар! У рэшце рэшт, гэта сцэнарыі, якія выяўляюць памылкі.

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

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



Праблемы з працэсам

Давайце паглядзім, як вышэйзгаданыя праблемы праяўляюцца ў тыповым сцэнарыі развіцця:

  • Уладальнік прадукту піша гісторыі карыстальнікаў з адсутнасцю альбо мінімальнымі крытэрыямі прыняцця.
  • Не хапае часу, прысвечанага сеансам удасканалення гісторыі, каб абмеркаваць розныя сцэнарыі гісторыі карыстальніка.
  • Крытэрыі прыёмкі інтэрпрэтуюцца як прыёмныя выпрабаванні - так, паміж імі ёсць розніца !
  • Тэстары аўтаматызуюць толькі крытэрыі прыняцця ў гісторыях карыстальнікаў, у асноўным з выкарыстаннем селену і / або агурка.
  • Аўтаматызаванае тэсціраванне амаль заўсёды адказвае «тэстарам аўтаматызацыі».
  • Распрацоўшчыкі не ўяўляюць, што ахоплена тэставымі пакетамі, і нават не ведаюць, як выконваць аўтаматызаваныя тэсты.
  • Аўтаматызаваныя тэсты дадаюцца да пастаянна пашыранага 'пакета рэгрэсіі', таму кожны раз запускаецца ўсё больш часу.
  • Аўтаматызаваныя функцыянальныя тэсты карыстацкага інтэрфейсу інтэграваны ў канвеер зборкі, што добра, але ...

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

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

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

Збоі ў інфраструктуры

Здаецца, няўдачы паказваюць падобную схему

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

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

У цэнтры ўвагі інжынераў па аўтаматызацыі выпрабаванняў - аўтаматызацыя функцыянальных выпрабаванняў. Няма ўвагі на прадукцыйнасці, бяспецы і ўстойлівасці. І тэсціравання інфраструктуры, безумоўна, няма!



Рэзюмэ

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

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

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

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

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

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

Калі вы займаецеся «Тэставай аўтаматызацыяй», калі ласка, не выкарыстоўвайце Selenium для тэставання функцыянальнасці API або кампанентаў карыстацкага інтэрфейсу. Замест гэтага выкарыстоўвайце Selenium для аўтаматызацыі толькі некалькіх карысных і крытычна важных для бізнесу сцэнарыяў, каб забяспечыць упэўненасць у бесперапыннасці бізнесу перад кожным выпускам.

І, нарэшце, кожны раз, калі вы праводзіце аўтаматызацыю 'тэсту', думайце пра час, які вы марнуеце, не тэстуючы!

Далейшае чытанне: