Сучаснае тэсціраванне - эвалюцыя ролі кантролю якасці
Распрацоўка праграмнага забеспячэння ператварылася ў часы вадаспаду Agile і DevOps. Натуральна, тэсціраванне як дысцыпліна таксама мела некалькі асноўных зрухаў, каб прыстасаваць новыя спосабы працы і дастаўкі праграмнага забеспячэння.
Аднак па-ранейшаму існуе велізарнае непаразуменне і няправільнае ўспрыманне ролі тэстараў і забеспячэння якасці ў цэлым.
У гэтым пасце мы разгледзім, як развівалася тэставанне, асабліва за апошняе дзесяцігоддзе, і тое, што трэба зрабіць спецыялістам па кантролі якасці, каб быць наперадзе гульні.
Тэставанне можа стаць толькі больш цікавым!
Хоць дзейнасць па тэсціраванні праграмнага забеспячэння змянілася, каб адаптавацца да новых спосабаў працы, я ўсё яшчэ бачу шмат старамодных поглядаў на тэсціраванне і ролю кантролю якасці.
Непрыемна бачыць, што ў ІТ-індустрыі па-ранейшаму шмат людзей, якія разглядаюць пытанні якасці і тэсціравання як асноўны вынік. Тэстары часта разглядаюцца як проста функцыянальныя тэстары, якія тэстуюць толькі пасля таго, як распрацоўшчыкі скончаць працу над функцыяй. 'Забеспячэнне якасці' ўспрымаецца як тэставанне, пошук і паведамленне пра памылкі і прадастаўленне зялёнага святла для выпуску.
Яшчэ больш турбуе тое, што такое ўспрыманне ролі забеспячэння якасці з'яўляецца галоўным сярод тэсціроўшчыкаў і саміх спецыялістаў па кантролі якасці.
Традыцыйнае тэсціраванне праграмнага забеспячэння
Гістарычна склалася так, што, прымаючы вядучую ролю ў заключнай фазе праекта вадаспада, тэставанне будзе трымацца справа ад жыццёвага цыкла праекта. Пасля папярэдняга вызначэння патрабаванняў тэсціроўшчыкі прымуць эстафету каманды распрацоўшчыкаў па заканчэнні фазы распрацоўкі і запусцяць працяглыя, падрабязныя сцэнарыі тэстаў, часта ўручную, і звычайна праз закрытыя групы і групы МСП.
Справы тэстаў былі старанна спланаваны загадзя, сцэнарыі выконваліся спецыялістамі, дэфекты былі выяўлены і паведамляліся, а цыклы выпрабаванняў запускаліся і паўтараліся да дасягнення зададзеных узроўняў якасці.
У першую чаргу паміж распрацоўшчыкамі і тэсціроўшчыкамі заўсёды было дакладнае раздзяленне, без перакрыцця абавязкаў і мерапрыемстваў. Сапраўды, падчас асобнага, абгрунтаванага этапу тэсціравання дзейнасць была сканцэнтравана выключна на функцыянальнай праверцы праграмнага забеспячэння з асноўнай мэтай пошуку і паведамлення пра дэфекты.
QA ў эру спрытнасці
З'яўленне гнуткіх метадалогій і спосабаў працы зліло дзейнасць па распрацоўцы і тэсціраванні да такой ступені, што тэставанне праграмнага забеспячэння ўжо не было самастойнай фазай. Замест гэтага тэсціраванне стала імпліцытнай дзейнасцю падчас кадавання і распрацоўкі праграмнага забеспячэння.
У некаторых выпадках бывае цяжка зразумець адрозненне паміж 'выпрабавальнікам' і 'распрацоўшчыкам', паколькі кожны з іх зможа бесперашкодна ажыццяўляць дзейнасць адзін аднаго.
'Якасць' перастала стаць выключнай адказнасцю тэсціроўшчыкаў і стала агульнай адказнасцю ўсіх, хто ўдзельнічае ў распрацоўцы і пастаўцы прадукту.
Разам з гэтай эвалюцыяй адбыўся перанос тэставых абавязкаў злева ад распрацоўкі, па сутнасці, якасць выпечкі з самага пачатку.
Фокус перайшоў ад пошуку дэфектаў убудаванага праграмнага забеспячэння да прадухілення траплення дэфектаў у праграмнае забеспячэнне.
З агульнай мэтай забяспечыць не толькі тое, каб прадукт ці функцыя функцыянавалі і адпавядалі патрабаванням, але і адпавядалі мэты і забяспечвалі высокі ўзровень задавальнення карыстальнікаў.
Звязаныя:
Удзел тэстараў у дапрацоўцы матэрыялаў, аглядах кодаў, адзінкавым тэсціраванні і такіх практыках, як TDD, BDD і бесперапыннае тэсціраванне, гарантавала, што тэсціраванне і якасць былі на першым плане і былі ўбудаваны ў распрацоўку.
Але, нягледзячы на тое, што Agile прайшоў доўгі шлях, спалучаючы дзейнасць і практыку распрацоўкі і тэсціравання, каманда аператараў па-ранейшаму была засланена. Два напрамкі працы (Dev & Ops) часта не ведалі пра дзейнасць адзін аднаго.
Калі што-небудзь пойдзе не так на вытворчасці, расследаванне зойме шмат часу. Распрацоўшчыкі не мелі ўяўлення пра тое, як эфектыўна працуе іх дадатак у вытворчасці ў больш доўгай перспектыве; не было ні празрыстасці, ні яснасці супрацоўніцтва паміж дзвюма камандамі.
Сардэчна запрашаем у DevOps
DevOps мае на ўвазе супрацоўніцтва каманд распрацоўшчыкаў і аператараў пры стварэнні, пастаўцы, абслугоўванні і падтрымцы праграмнага забеспячэння. Ён мае на ўвазе бесперапыннае аб'яднанне рэсурсаў, працэсаў і самога прадукту.
DevOps дазваляе метады пастаяннай інтэграцыі і дастаўкі каштоўнасці для канчатковага карыстальніка.
Рух DevOps прывёў новы погляд на тэставанне і стварыў новыя магчымасці для саміх тэстараў.
У гэтую новую эру тэстары павінны быць узгоднены як з распрацоўкай, так і з аперацыямі.
Кампанія тэсціравання больш не абмяжоўваецца прадуктам, але і тэсціраваннем інфраструктуры, у якой прадукт у канчатковым выніку выконваецца.
Бесперапынная інтэграцыя (CI) і пастаянная дастаўка (CD) сталі дэ-факта стандартам у распрацоўцы і пастаўцы праграмнага забеспячэння, і таму вялікая колькасць высілкаў цяпер ідзе на забеспячэнне канвеера CI / CD, асяроддзя і інфраструктуры.
Гэта пазваночнік, які падтрымлівае развіццё і роды.
Калі правесці іх грэбаванне грэбаваннем, гэта можа прывесці да нестабільнага асяроддзя, шмат намаганняў будзе выдаткавана на расследаванне неаднаразовых праблем інфраструктуры і, у канчатковым рахунку, высокая рызыка для развіцця і хуткай дастаўкі.
Сучаснае тэсціраванне - кіраванне якасцю
Нягледзячы на тое, што шмат зроблена для ўбудавання якасці на кожным этапе распрацоўкі, і, як следства, тэставанне мае значна шырэйшы спектр, я ўсё яшчэ лічу, што службы забеспячэння праводзяць большую частку свайго часу ў пошуках функцыянальных праблем і канцэнтрацыі на праверцы праграмнага забеспячэння.
Большасць служб якасці не разумеюць важнасці сваёй ролі і ўплыву, які яны могуць аказаць на развіццё і пастаўкі.
Нягледзячы на значныя зрухі ў практыцы распрацоўкі за апошнія дзесяць гадоў, я адчуваю, што тэстыроўшчыкі па-ранейшаму па-старому глядзяць на сваю ролю і, такім чынам, застаюцца замацаванымі ў старой эпосе тэсціравання.
Тэсціраванне як прафесія і роля выпрабавальніка падвяргаецца небяспецы на працягу некаторага часу з ростам 'аўтаматызаванага тэсціравання'. І сапраўды, многія прафесіяналы галіны па-ранейшаму лічаць, што роля тэстара заключаецца ў простай праверцы прыкладання, якое ствараюць распрацоўшчыкі, і ўсё гэта можна аўтаматызаваць.
Калі распрацоўшчыкі лепш падыходзяць і больш кемлівыя пісаць код, неабходны для аўтаматызаванага тэсціравання, то якая ўвогуле патрэба ў тэстары ў камандзе?
Прыйшоў час, калі мы змянілі гэтае ўспрыманне. Мы павінны прызнаць розніцу ў кошце і навыках паміж 'тэставаннем' і 'забеспячэннем якасці', паколькі, калі тэставанне - гэта функцыянальная праверка і праверка праграмнага забеспячэння, забеспячэнне якасці - гэта не адна дзейнасць. Якасць кантролю - гэта шэраг працэсаў, уключаючы тэсціраванне, і перадавыя практыкі для забеспячэння якаснага прадукту для карыстальнікаў.
Мы павінны імкнуцца да якаснага развіцця і разглядаць прафесію кантролю якасці як асноўную і асноўную функцыю ў распрацоўцы і пастаўцы праграмнага забеспячэння, такім чынам, Сучаснае тэсціраванне .
Якасць кантролю цяпер з'яўляецца ключавым кампанентам распрацоўкі ад пачатку да канца працы на працягу ўсяго працэсу. І, нягледзячы на тое, што звычайная мова кажа, што ўсе ў камандзе дастаўкі нясуць адказнасць за пастаўку якаснага прадукту, я цвёрда веру, што адказнасць за кантроль за тым, каб каманда прытрымлівалася практыкі якасці.
Хто такі сучасны кантроль якасці
Там, дзе тэставая прафесія часта разглядалася як шлях доступу да распрацоўкі, кіравання праектамі альбо іншых - звычайна больш прыбытковых - дысцыплін, новы кантроль якасці - гэта высокакваліфікаваная роля, якая патрабуе цэласных ведаў пра практыку распрацоўкі.
Гэта патрабуе шырокага разумення праблем практыкі кадавання, ацэнкі метадаў і асяроддзя разгортвання, а таксама стандартаў прадукцыйнасці і бяспекі, метадаў і праблем.
Гэта Т-вобразная роля, якая дазваляе рэсурсу не толькі прымяніць свае глыбокія веды і вопыт для выканання сваіх асноўных задач, але і прымяніць больш шырокія кантэкстныя веды ў галіне архітэктуры і развіцця.
Размяшчаючыся ў цэнтры любога праекта, сучасны кантроль якасці павінен добра разумець архітэктуру, прадукцыйнасць, бяспеку і воблачныя прапановы, быць тэхнічна спраўным і мець прагу вывучэння новых тэхналогій, каб заставацца ў гульні.
нататка:Яшчэ адна вобласць, якая хутка становіцца вельмі папулярнай і важнай тэставаннем якасці дадзеных, тэставаннем вялікіх дадзеных, азёр і сховішчаў дадзеных.Прыйшоў час змяніць уяўленне пра ролю кантролю якасці і пра тое, што робяць тэсціроўшчыкі. Гэта павінна пачацца з саміх выпрабавальнікаў. Адпраўной кропкай з'яўляецца глыбокая клопат аб якасці.
Тэстары не толькі для таго, каб правесці функцыянальнае тэсціраванне і паведаміць пра памылкі. Роля кантролю якасці значна большая. Нас ставяць на праект забяспечыць якасную практыку .
Калі мы глыбока тэстуем прыкладанне, мы павінны мець глыбокія веды пра ўсю працу сістэмы, а не проста глядзець на прыкладанне як на чорную скрыню.
Каб мець гэтыя глыбокія веды, мы павінны пастаянна вучыцца і ісці ў нагу з новымі тэхналогіямі і спосабамі працы. Самае галоўнае, што пытанні якасці павінны быць адаптыўнымі.
Калі службы кантролю зразумеюць іх мэту ў праекце і пачнуць верыць, што іх роля з'яўляецца цэнтральнай часткай распрацоўкі і пастаўкі праграмнага забеспячэння, калі мы прымаем сучасныя прынцыпы тэсціравання, толькі тады мы можам змяніць успрыманне навакольных.
