Сцрум минус план тестирања је једнак ПОЦ на стероидима.
Данас најуспешнији пројекти почињу са Прооф оф Цонцепт (ПОЦ), релативно малом проценом идеје, где ће изабрана технологија и пакет функција прво бити верификовани, процењени за потенцијални утицај на пословне кориснике, а затим, када се докаже вредан улагања, пројектни тим у пуној величини је додељен да дизајнира и испоручи производ са свим функцијама и да га примени у производњу.
Ово је савршен случај за Сцрум тим. Тим може брзо да развије прототип, додајући значајне нове функције сваког спринта, док пословни корисници могу да гледају брз напредак у реалном времену и како се идеја гради од нуле у року од само 10 спринта. Оставља снажан утисак (што је ионако главна мета ПОЦ-а), али има и једно значајно својство – минималне или никакве активности тестирања, па би чак и размишљање о процесу тестирања била права шала.
То није забавна активност унутар Сцрум тима, а људима ће се углавном допасти идеја да се развијају без процеса који би их успорили. То је у основи оно што ће свака активност тестирања учинити имплицитно. А ко жели непотребну спорост током времена које нам је потребно да највише импресионирамо крајњег корисника?
Стање које се дешава ако пројектни тим настави на исти начин након завршетка ПОЦ периода је нешто што користим да зовем ПОЦ на стероидима – производни систем који расте по величини и карактеристикама, али се и даље понаша као ПОЦ – ваннабее комплетан производ са скривени недостаци и неистражени кутови, само чекају на озбиљан пад.
Али пре него што се тамо преобрати, тиму ће бити теже из спринта у спринт да прати стабилна издања, јер ће решавање текућих проблема постати само сложеније.
Ево неких техника које су се показале да раде када сам се бавио сличним проблемима и за које верујем да се могу назвати најбољом праксом за имплементацију солидних процеса тестирања, а да ипак не ометају напредак развоја превише – јер то је оно за шта сви желимо да будемо Сцрум тим.
Преглед садржаја
Дистрибуирајте бол
Одакле да почнемо када се бавимо непотребним мукама него од цепања бола :).
И оно што мислим под овим је креирање плана који ће захтевати мале додатне активности програмера ту и тамо, али који ће током времена у великој мери допринети заједничком циљу, постепено, али доследно.
#1. Развијте код за јединични тест за сваки креирани део новог кода
Ако успете да убедите своје скрам тимове да у своју клаузулу Дефинитион Оф Доне додају развој јединичних тестова за сваки нови код креиран у оквиру спринта, онда ће то из дугорочне перспективе бити велико достигнуће.
Разлози су прилично очигледни:
То ће приморати програмере да размишљају о различитим нестандардним путевима кода. –
- Такви тестови јединица се могу укључити у аутоматизоване ДевОпс цевоводе и извршити са сваком појединачном имплементацијом у окружење за развој или тестирање. Такође, метрике из цевовода могу се лако извести и затим користити за демонстрацију пословним корисницима процентуалне покривености тест случајева директно везаних за изворни код.
Најважније је почети врло брзо. Што касније почну да се развијају јединични тестови, то ће програмерима бити више ометајуће да их додају у спринту.
- Биће потребан значајан напор да се развију тестови јединица за већ постојећи код. Неке делове кода може креирати други програмер и тренутном програмеру није сасвим јасно како би требало да функционише у сваком поједином делу кода. У неким случајевима може доћи тако далеко да ће додавање јединичног теста модификованом коду потрајати више времена него развој промене функције за спринт (што је стање које нико сигурно није израчунао током планирања спринта).
#2. Направите рутину извршавања свих делова тестова јединица у развојном окружењу
Чак и пре креирања захтева за повлачење за спајање новог кода у Мастер грану, биће стандардна активност тестирања и кода функције и кода јединичног теста у дев окружењу. Тиме ће се осигурати да:
- Код за јединични тест заправо ради за сваки део (на крају је то само још један код који мора бити верификован). Овај корак се врло често потпуно прескаче. Некако се претпоставља да ако је јединични тест ипак укључен у ДевОпс цевовод, он ће на крају бити извршен и тестиран негде подразумевано. Међутим, ово није ништа друго него гурање проблема на више нивое спринтерских активности, где тим обично има мање времена и више стреса да заврши сваку посвећену причу.
- Програмер тестира основну функционалност новог кода функције. Очигледно, од овог теста се не може очекивати да ће пословна функционалност бити у потпуности верификована, али ће барем овај тест потврдити да се код понаша онако како га је програмер замислио (занемарујући, за сада, чињеницу да би пословна логика могла бити погрешно схваћен док се развија).
#3. Очекујте извршење јединичног теста након спајања кода у главну грану
Једна је ствар имати функционални код на локалној грани (где нико осим власника гране не развија нову функцију), али је сасвим друга ствар имати исти код који ради након захтева за повлачење и спајања у главну грану.
Главна грана садржи измене других чланова Сцрум тима, па чак и ако су конфликти решени и све изгледа у реду, код након спајања и решавања конфликата је у суштини још увек непроверен део кода и ризично је слати га даље без претходне провере и даље ради добро.
Дакле, оно што се показало ефикасним овде је само једноставно тражење да се изврши исто тестирање јединица – већ урађено у дев окружењу – такође у окружењу које је изграђено од верзије главног кода гране.
За програмере, то би могао бити још један корак који треба да унесу у свој живот, али то није велики напор, јер у овом случају ништа ново не мора да се измишља – само поново извршите оно што је већ једном урађено.
Сада, овај корак би се могао прескочити у једном конкретном случају:
- Аутоматизовани јединични тестови у ДевОпс цевоводима су толико свеобухватни да већ покривају читаво ручно тестирање које се изводи поврх тога.
Иако је постизање овог стања дефинитивно изводљиво, никада нисам доживео такво стање у стварном животу. За програмере би вероватно било чак и превише времена да креирају тако дубоко детаљне аутоматизоване тестове јединица. За власника производа би могло постати неприхватљиво да дозволи тиму да посвети толико времена овој активности, јер би то имало експлицитан утицај на број испоручених прича у спринту.
Међутим, преференција садржаја спринта никада неће бити изговор да се не раде јединични тестови, па чак ни да се они минимизирају. Радећи ово, тим ће се поново конвертовати у такво стање да коду недостаје превише покривености јединичним тестом, а онда би за надокнађивање могло бити већ прекасно (опет, већи напор за завршетак теста јединице од стварног промена кода за спринт).
Из свих тих разлога, препоручио бих поновно извођење јединичних тестова на верзији главног кода без оклевања. То је тако мали напор у поређењу са вредношћу коју ће донети.
Он ће извршити коначну проверу спремности главне гране за фазу тестирања издања. Такође, помоћи ће да се пронађе већина техничких грешака (нпр. грешака које спречавају да се изворни код успешно изврши до успешног краја), остављајући следећу фазу да се концентрише искључиво на верификацију пословне функционалности.
Припремите се за функционално тестирање
Све претходне активности тестирања довешће до једног специфичног закључка – главни код гране је без техничких грешака и може се извршити без проблема за функционалне токове од краја до краја.
Ово је фаза коју може лако да покрије само једна особа, а та особа чак и не мора да има техничку позадину.
У ствари, много је боље ако ово изврши неко ко није повезан са програмерима, али са функционалном свешћу о томе како пословни корисници очекују да се код понаша. Постоје две главне активности које треба завршити:
#1. Нове приче о спринту циљале су функционални тест
Сваки спринт ће у идеалном случају донети неку нову функционалност (повећање циља спринта) која раније није постојала, и стога ће бити верификована. Важно је обезбедити да нови комад софтвера функционише у толикој мери да ће пословни корисници бити срећни што га сада имају, јер су му се очигледно радовали минимално цео последњи спринт :).
Тако је тужно искуство када је коначно објављена (дуго) обећана функционалност, да би се пре неки дан сазнало да заправо не функционише добро.
Стога је правилно тестирање нове спринт функционалности кључно. Да би ово било успешно, добра је пракса да се унапред сакупе важни случајеви тестирања и од релевантних заинтересованих страна (било од власника производа или чак од крајњих корисника) и да се направи листа свих таквих тест случајева потребних за садржај унутар спринт.
Ово би могло изгледати неодољиво на први поглед, али из мог искуства, опет је потпуно подесно само једној особи. Пошто су спринтови углавном прилично кратки (као што је кратак период од две недеље), ионако скоро никада није превише новог садржаја, јер спринт садржи и додатне активности као што су техничке приче о дуговима, документација, дизајн/спике приче, итд.
Тестни случајеви се затим извршавају са циљем пре свега верификације жељене функционалности. Ако дође до било каквог проблема са резултатима, обраћа се само релевантном програмеру (онај који поседује промене у вези са овим дефектом) како би се проблем решио брзо.
На овај начин, програмери ће провести минимално време повезано са функционалним тестирањем и још увек могу да се концентришу на активности које им се највише допадају.
#2. Извођење регресионих тестова
Други део функционалног тестирања ће бити да се осигура да ће све што је до сада функционисало функционисати и након следећег издања. Томе служе регресијски тестови.
Тест случајеви за регресијске тестове су најбољи ако се редовно одржавају и прегледавају пре сваког издања. На основу специфичности конкретног пројекта, најбоље је да буду једноставни, а да покрију већину основних функционалности и важних токова од краја до краја који пролазе кроз цео систем.
Обично сваки систем има такве процесе који се дотичу много различитих области, они су најбољи кандидати за случајеве регресијског теста.
У неким случајевима, регресиони тестови чак имплицитно покривају и нове карактеристике у спринту, на пример, ако нова прича у спринту мења неки одређени део постојећег тока.
Дакле, у већини случајева уопште није много сложено завршити регресионе тестове заједно са тестовима функционалности нових прича о спринту, посебно ако се то ради редовно пре сваког производног издања, а периодичност продукционих издања није премала.
Инсистирајте на извршавању тестова осигурања квалитета пре сваког издања производње
Тест обезбеђења квалитета (КА) је последњи корак пре пуштања у производњу и често се овај тест прескаче као неважан. Нарочито ако се сцрум тимом агресивно управља за нови садржај.
Чак и пословни корисници ће рећи да су заинтересовани за нове функције, а не толико за очување функционалности или смањење броја недостатака. Али опет – током времена, ово је главни разлог зашто ће развојни тим на крају морати да успори, а онда пословни корисници ионако неће добити оно што траже.
КА тест ће спроводити искључиво људи изван Сцрум тима, у идеалном случају сами пословни корисници у наменском окружењу, које је што ближе будућој производњи. Алтернативно, власник производа може да замени крајње кориснике.
У сваком случају, ово би требало да буде чист, функционалан тест из перспективе крајњег корисника, без икакве везе са дев Сцрум тимом. Он ће представити један коначни поглед на производ и бити коришћен на начин на који нико из сцрум тима није очекивао (уопште није идеалан случај, али се дефинитивно може догодити). Још увек има времена за исправке у последњем тренутку.
Алтернативно, могло би постати јасно да сцрум тим није добро разумео очекивања, и у том случају, барем можемо да се договоримо о плану за праћење, још много пре стварног издавања производње. Ово опет није идеалан случај, али је ипак много боље као да признате неуспех одмах након што се пријави успешно издање.
Куда даље?
Примена ових пракси у свакодневном сцрум раду може вас озбиљно довести до стабилизованијих и предвидљивијих навика за издавање спринта, без одлагања продукционих издања или трошења целог спринта само на припрему за следеће издање, или чак без присиљавања свих у сцрум тиму да ураде нешто што раде. ионако не волим или не знам како да урадим ефикасно већи део спринта, тј.
Али сигурно не морате стати овде.
Укључивање тестова перформанси је једна тема коју овде треба навести. Оне се често занемарују или сматрају непотребним, што се у првом кругу „оптимизације сцрум активности“ избацује. Међутим, увек сам био у недоумици око тога како се може очекивати да ће производни систем еволуирати током времена ако се не проверава редовно за перформансе.
Полазак за један ниво више значи и увођење аутоматизованих тестова.
Већ сам покрио једну групу аутоматизованих тестова (јединични тестови у припреми). Међутим, можете развити потпуне енд-то-енд регресионе тестове потпуно аутоматизоване и извршене сами након сваког постављања у окружење за тестирање. Ово би још више ослободило развојни сцрум тим, али је за развој и одржавање таквих аутоматизованих тестова потребан наменски тим. То би постао стални рад, јер кад год се производни код промени, неки постојећи аутоматизовани тестови могу постати неважећи, па се морају ажурирати да би наставили да раде у току. То је напор који је само неколицина спремна да плати, али би користи за дев сцрум тим биле велике.
То су теме које су далеко изнад обима овог чланка и проналажење правог распореда и времена за сваки тип теста који се овде помиње – тако да можете да га урадите у оквиру спринта. Следећи пут ћу радо заронити!