Пераход ад вадаспаду да спрытнага тэсціравання

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

Як тэставанне ў Agile параўноўваецца з тэстам мадэлі Waterfall? Які набор мерапрыемстваў важна ведаць і рабіць тэсціроўшчыкам?



Тэставанне на працягу ўсяго развіцця

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


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

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


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



Удзел распрацоўшчыка ў тэставанні

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

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

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




Інтэграваныя і шматфункцыянальныя каманды

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

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

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

У спрытнай камандзе выпрабаванняў няма.




Якаснае мысленне, падыход цэлай каманды

Імкніцеся да прадухілення дэфектаў, а не да выяўлення дэфектаў.

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

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

Усе ўдзельнічаюць і нясуць адказнасць за якасць прадукцыі.




Менш дакументацыі, больш супрацоўніцтва

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

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

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

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


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