„Uszanowanko Programowanko”: jak zostać koszmarem dewelopera

Liczba odsłon: 105

Można żar­tob­li­wie po­wie­dzieć, że naj­więk­szym wro­giem pro­gra­mis­ty jest użyt­kow­nik je­go opro­gra­mo­wa­nia. Na eta­pie roz­wo­ju apli­kac­ji jesz­cze groź­niej­szym prze­ciw­ni­kiem mo­że być jed­nak tes­ter. Prezentac­je przed­sta­wio­ne 12 wrześ­nia w ra­mach XXXI spot­ka­nia The Software House z cyk­lu „Uszanowanko Programowanko” po­świę­co­ne by­ły głów­nie te­mu, jak sku­tecz­nie wy­szu­ki­wać błę­dy w opro­gra­mo­wa­niu i pro­wa­dzić te­sty eks­plo­ra­cyj­ne i ak­cep­ta­cyj­ne. I choć zgod­nie z has­łem prze­wod­nim spot­ka­nia tes­ter mo­że być wi­dzia­ny ja­ko „kosz­mar de­we­lo­pe­ra”, osta­tecz­nie współ­pra­cu­je z pro­gra­mi­sta­mi i wspo­ma­ga ich w do­sko­na­le­niu pro­gra­mu.

Pierwszy wy­stą­pił Jacek Bugajny. Jego pre­zen­tac­ja za­ty­tu­ło­wa­na „Pięć twa­rzy kryp­to­grafii” sta­no­wi­ła szyb­kie, zgrub­ne, lecz mi­mo to dość kon­kret­ne wpro­wa­dze­nie w za­gad­nie­nia zwią­za­ne z szyf­ro­wa­niem da­nych. Prelegent wy­jaś­nił czym są kryp­to­lo­gia, kryp­to­gra­fia oraz kryp­to­ana­li­za i przed­sta­wił pod­sta­wo­we de­fi­ni­cje zwią­za­ne z ty­mi dzie­dzi­na­mi wie­dzy. W ra­mach wpro­wa­dze­nia przed­sta­wio­ne zo­sta­ły przy­kła­dy szy­frów prze­sta­wie­nio­wych i pod­sta­wie­nio­wych, w tym ROT13 oraz Cezara. Następ­nie pre­le­gent płyn­nie wpro­wa­dził uczest­ni­ków w prob­lem uzgad­nia­nia klu­czy w nie­za­ufa­nym śro­do­wis­ku oraz je­go roz­wią­za­nie, ja­kim jest pro­to­kół Diffiego-Hellmana, w prak­ty­ce uży­wa­ny w al­go­ryt­mie RSA.

Następ­nie pre­le­gent opi­sał funk­cje skró­tu ta­kie jak MD5SHA-1. Do te­go frag­men­tu moż­na by­ło mieć pew­ne za­strze­że­nia, gdyż za­sto­so­wa­nie funk­cji skró­tu nie zo­sta­ło do­brze wy­jaś­nio­ne, a z pre­zen­tac­ji moż­na by­ło wręcz od­nieść myl­ne wra­że­nie, że sta­no­wią one ko­lej­ną for­mę szy­fro­wa­nia da­nych.

Na ko­niec ja­ko prak­tycz­ne, co­dzien­ne za­sto­so­wa­nie przed­sta­wio­nych roz­wią­zań i tech­nik zo­stał wy­mie­nio­ny pro­to­kół SSL (nota bene za­stą­pio­ny już daw­no przez TLS).


Druga pre­zen­tac­ja, za­ty­tu­ło­wa­na „Testy eks­plo­ra­cyj­ne: lucky shot czy za­pla­no­wa­na ak­cja?”, zo­sta­ła przed­sta­wio­na przez Adama Nowrota. Testy eks­plo­ra­cyj­ne to tech­ni­ka tes­to­wa­nia po­le­ga­ją­ca na ba­da­niu funkcjo­nal­noś­ci „w ciem­no”, z mi­ni­mal­ną zna­jo­mo­ścią dzia­ła­nia funk­cji oraz szcząt­ko­wą do­stęp­ną do­ku­men­tac­ją. Powinien pro­wa­dzić je do­świad­czo­ny tes­ter, cha­rak­te­ry­zu­ją­cy się du­żą in­tu­icją oraz wnik­li­wo­ścią, zna­ją­cy do­me­nę biz­ne­so­wą tes­to­wa­nej funkcjo­nal­noś­ci.

Jednym z wa­run­ków, by ses­ja te­stów eks­plo­ra­cyj­nych by­ła uda­na, jest usta­le­nie skoń­czo­ne­go bud­że­tu cza­su oraz do­bre przy­go­to­wa­nie się do te­stów. Można przy­jąć, że 20% za­ło­żo­ne­go cza­su po­win­no być po­świę­co­ne na przy­go­to­wa­nie do te­stów, 60% na sa­me te­sty, a po­zo­sta­łe 20% — na opra­co­wa­nie ra­por­tu. W ra­mach przy­go­to­wa­nia tes­ter ko­mu­ni­ku­je się z ar­chi­tek­ta­mi i pro­gra­mi­sta­mi, wy­szu­ku­je i gro­ma­dzi do­ku­men­tac­ję oraz okre­śla za­kres tes­to­wa­nia, któ­ry po­wi­nien obej­mo­wać funk­cje naj­bar­dziej istot­ne z punk­tu wi­dze­nia biz­ne­so­we­go.

Istotne jest, by tes­ter nie wpadł w utar­te ścież­ki i nie tes­to­wał de­ta­li apli­kac­ji, nie do­ty­ka­jąc kry­tycz­nych wąt­ków lo­gi­ki biz­ne­so­wej. Można to osiąg­nąć na przy­kład zle­ca­jąc te­sty eks­plo­ra­cyj­ne no­wym tes­te­rom, któ­rzy nie zaj­mo­wa­li się jesz­cze da­ną funkcjo­nal­noś­cią i nie uleg­ną po­ku­sie spraw­dza­nia ciąg­le tych sa­mych ope­rac­ji.

Wynikiem ses­ji te­stów eks­plo­ra­cyj­nych po­wi­nien być ra­port za­wie­ra­ją­cy in­for­mac­je o za­kre­sie cza­so­wym ses­ji, te­sto­wa­nym ob­sza­rze apli­kac­ji i zna­le­zio­nych de­fek­tach (wraz z do­kład­nym opi­sem spo­so­bu po­wtó­rze­nia, o ile to moż­li­we). W przy­pad­ku zna­le­zie­nia łat­wo po­wta­rzal­nych błę­dów war­to za­pro­po­no­wać w ra­por­cie no­we sce­na­riu­sze te­sto­we do uwzględ­nie­nia w ra­mach te­stów auto­ma­tycz­nych. Jeżeli tes­ter nie ma ja­sno­ści co do spo­so­bu dzia­ła­nia nie­któ­rych funk­cji, w ra­por­cie moż­na też umieś­cić py­ta­nia do kie­row­ni­ka ze­spo­łu.

Testy eks­plo­ra­cyj­ne naj­le­piej prze­pro­wa­dzi „świe­ży umysł”, nie za­tru­ty jesz­cze pra­cą z da­nym mo­du­łem apli­kac­ji. Doświad­czo­ny tes­ter du­żo szyb­ciej i le­piej przy­go­tu­je się jed­nak do ses­ji te­stów niż ktoś, kto do­pie­ro roz­po­czy­na pra­cę tes­te­ra. Dobre przy­go­to­wa­nie się do ses­ji po­zwo­li też unik­nąć po­wtór­ne­go wejś­cia na utar­te ścież­ki w przy­pad­ku tes­te­rów ma­ją­cych wcześ­niej kon­takt z tą lub po­dob­ną apli­kac­ją. Mimo to, oso­by świe­żo wcho­dzą­ce do no­we­go pro­jek­tu (blis­ko koń­ca sprin­tu, eta­pu lub ca­łe­go pro­jek­tu) mo­gą zy­skać dzię­ki „szczę­ściu po­cząt­ku­ją­ce­go”, spraw­dza­jąc sek­wen­cje po­le­ceń któ­re za­zna­jo­mio­na z pro­gra­mem oso­ba od ra­zu od­rzu­ci­ła­by ja­ko ab­sur­dal­ne.

Pozytyw­nym skut­kiem pro­wa­dze­nia te­stów eks­plo­ra­cyj­nych jest lep­sze po­zna­nie apli­kac­ji oraz jej za­cho­wa­nia w róż­nych sytu­acjach. W efek­cie prze­pro­wa­dzo­nych te­stów two­rzo­ne są no­we sce­na­riu­sze te­sto­we oraz znaj­do­wa­ne miej­sca war­te pod­da­niu tes­tom auto­ma­tycz­nym. Do wad moż­na za­li­czyć z kolei trud­ność w od­two­rze­niu nie­któ­rych ście­żek pro­wa­dzą­cych do błę­dów oraz brak in­for­mac­ji o sto­pniu po­kry­cia funkcjo­nal­noś­ci te­sta­mi. Tester mo­że bo­wiem nie wie­dzieć, któ­re miej­sca są szcze­gól­nie wraż­li­we na po­wsta­wa­nie błę­dów lub istot­ne z punk­tu wi­dze­nia klienta. Dlatego właś­nie tak istot­ne jest przy­go­to­wa­nie się do te­stów, by za­cząć je nie od de­ta­li, lecz funk­cji naj­bar­dziej in­te­re­su­ją­cych klienta.


Ostatnia pre­zen­tac­ja, za­ty­tu­ło­wa­na „Testy ak­cep­ta­cyj­ne: for­mal­ność czy dro­ga przez mę­kę?” i przed­sta­wio­na przez Joannę Zembaczyńską, mia­ła na ce­lu przed­sta­wie­nie środ­ków pro­wa­dzą­cych do te­go, by te­sty ak­cep­ta­cyj­ne fak­tycz­nie sta­ły się for­mal­no­ścią zwień­cza­ją­cą pro­jekt, a nie po­wo­dem zja­wi­ska no­szą­ce­go naz­wę crunch, sta­no­wią­ce­go po­strach ze­spo­łów pro­gra­mis­tycz­nych. Testy ak­cep­ta­cyj­ne prze­pro­wa­dza się na eta­pie od­bio­ru pro­duk­tu by klient miał pew­ność, że otrzy­my­wa­ny pro­gram speł­nia je­go ocze­ki­wa­nia. Realizu­je się je na ser­we­rze pro­duk­cyj­nym lub zbli­żo­nym do pro­duk­cyj­ne­go, by jak naj­bli­żej od­zwier­cied­lić śro­do­wis­ko, w któ­rym ma póź­niej dzia­łać pro­gram.

Poziom istot­no­ści uste­rek znaj­do­wa­nych na eta­pie te­stów ak­cep­ta­cyj­nych mo­że sta­no­wić kość nie­zgo­dy po­mię­dzy pro­gra­mi­sta­mi a klien­tem. Usterki w sty­lu błę­dów li­te­ro­wych, moż­li­we do usu­nię­cia w cią­gu kil­ku mi­nut, dla klienta mo­gą sta­no­wić błąd kry­tycz­ny, de­cy­du­ją­cy o od­rzu­ce­niu pro­duk­tu i skie­ro­wa­niu go do po­praw­ki. Dlatego te­sty ak­cep­ta­cyj­ne mu­szą być do­sto­so­wa­ne do wy­ma­gań biz­ne­so­wych klienta, a wa­run­ki ak­cep­tac­ji do­kład­nie okreś­lo­ne przez sa­me­go klienta w for­mie za­dań wpi­sa­nych do sys­te­mu ty­pu Jira, ar­ku­sza kal­ku­la­cyj­ne­go lub przy­naj­mniej pod­pi­sa­nej i opie­czę­to­wa­nej kart­ki. Istotne jest, by kry­te­ria by­ły za­twier­dzo­ne, bez­dy­sku­syj­ne i nie pod­le­ga­ły ani za­wę­ża­niu przez wy­ko­naw­cę, ani roz­sze­rza­niu przez za­ma­wia­ją­ce­go. Musimy też zwra­cać uwa­gę na ele­men­ty nie­funk­cjo­nal­ne, częs­to nie­wpi­sa­ne bez­po­śred­nio do wy­ma­gań, ta­kie jak łat­wość ob­słu­gi funkcjo­nal­noś­ci lub lo­gicz­ne dzia­ła­nie na­rzę­dzi.

Dla pro­jek­tu naj­le­piej jest, by te­sty ak­cep­ta­cyj­ne pro­wa­dził we­wnętrz­ny ze­spół tes­te­rów. Tester po­wi­nien brać udział w pra­cach już na eta­pie usta­la­nia wy­ma­gań, ko­mu­ni­ku­jąc się z klien­tem i na­wią­zu­jąc z nim re­la­cję poz­wa­la­ją­cą do­brze po­znać ce­le biz­ne­so­we pro­jek­tu oraz wy­eli­mi­no­wać nie­uf­ność i agres­ję, któ­re mo­gą wy­stą­pić na eta­pie od­bio­ru. Pamiętanie o tes­tach ak­cep­ta­cyj­nych od sa­me­go po­cząt­ku pro­jek­tu po­zwo­li stwo­rzyć ba­zę wie­dzy dla sce­na­riu­szy te­sto­wych, przy­go­to­wać te­sty auto­ma­tycz­ne oraz wy­eli­mi­no­wać część błę­dów na dłu­go przed od­bio­rem. W efek­cie zna­czą­co skra­ca się czas tes­to­wa­nia na koń­cu pro­jek­tu.

Istnieje wie­le spo­so­bów, by mi­mo wszyst­ko te­sty ak­cep­ta­cyj­ne zmie­nić w dro­gę przez mę­kę. Pierwszym błę­dem jest brak ja­snych za­sad współ­pra­cy z klien­tem. Jeżeli klient nie usta­li li­sty osób od­po­wie­dzial­nych za zgła­sza­nie uste­rek, za­sy­pią nas róż­nej ja­koś­ci, po­wie­la­ją­ce się zgło­sze­nia po­cho­dzą­ce od wszyst­kich pra­cow­ni­ków bio­rą­cych udział we wdro­że­niu. Utrudni to od­twa­rza­nie prob­le­mów oraz zwięk­szy kosz­ty ob­słu­gi ko­mu­ni­kac­ji z klien­tem. Z kolei je­że­li po stro­nie wy­ko­naw­cy nie bę­dzie oso­by (lub osób) zaj­mu­ją­cych się ob­słu­gą zgło­szeń, nie­któ­re zgło­sze­nia mo­gą po­zo­stać bez ob­słu­gi lub bez właś­ci­wej we­ry­fi­ka­cji ich zrea­li­zo­wa­nia.

Kolejnym błę­dem jest brak we­ry­fi­ko­wa­nia speł­nie­nia kry­teriów ak­cep­tac­ji po każ­dym eta­pie roz­wo­ju pro­duk­tu (lub każ­dym sprin­cie w przy­pad­ku sto­so­wa­nia me­to­do­lo­gii scrum). Sprawdzanie kry­teriów ak­cep­tac­ji do­pie­ro na eta­pie od­bio­ru opóź­nia wy­kry­cie błę­dów i po­wo­du­je, że na tak istot­nym eta­pie za­awan­so­wa­nia pro­jek­tu na­stę­pu­je zna­czą­ce prze­su­nię­cie da­ty go­to­wo­ści do od­bio­ru.

Trzecia ka­te­go­ria prob­le­mów wy­ni­ka pa­ra­dok­sal­nie z du­żej dba­ło­ści, z ja­ką klient chce po­dejść do te­stów ak­cep­ta­cyj­nych. Do tes­to­wa­nia mo­że zo­stać od­de­le­go­wa­na bar­dzo licz­na gru­pa pra­cow­ni­ków za­in­te­re­so­wa­nych no­wym pro­duk­tem, z któ­rych część mo­że nie mieć cza­su, chę­ci lub pre­dys­po­zy­cji do tes­to­wa­nia. W efek­cie nie­któ­re błę­dy mo­gą zo­stać nie­wy­kry­te. Z kolei nie­któ­rzy „tes­te­rzy z przy­pad­ku” mo­gą zbyt gor­li­wie wy­peł­niać no­wy obo­wią­zek i zgła­szać ja­ko błąd każ­dą naj­drob­niej­szą zna­le­zio­ną nie­do­god­ność. Przy tak du­żej licz­bie tes­te­rów mo­że też dojść do sytu­acji, w któ­rej po­praw­ka błę­du zo­sta­je zgło­szo­na ja­ko no­wa uster­ka, gdyż dwie róż­ne gru­py pra­cow­ni­ków ma­ją od­mien­ne po­glą­dy na spo­sób, w ja­ki po­win­na dzia­łać pew­na funkcjo­nal­ność.

Z po­wyż­szym prob­le­mem łą­czy się zja­wi­sko „de­fek­tu fał­szy­wie po­zy­tyw­ne­go”, zgła­sza­ne­go przez klienta, jed­nak tak na­praw­dę nie sta­no­wią­ce­go uster­ki w ro­zu­mie­niu kry­teriów ak­cep­tac­ji. Czasem bo­wiem kry­te­ria ak­cep­tac­ji al­bo są za­pi­sa­ne nie­po­praw­nie, al­bo są róż­nie ro­zu­mia­ne przez róż­ne gru­py tes­te­rów, al­bo wręcz nie są zna­ne nie­któ­rym pra­cow­ni­kom klienta. W tym ostat­nim przy­pad­ku błę­dy mo­gą po­zo­sta­wać w kon­flik­cie z kry­teria­mi ak­cep­tac­ji, gdyż zgło­sze­nia po­wsta­ją na pod­sta­wie ocze­ki­wań tes­te­rów, a nie po­rów­na­nia dzia­ła­nia pro­gra­mu z za­pi­sa­mi umow­ny­mi.

Klienta na­le­ży dys­cyp­li­no­wać nie tyl­ko w za­kre­sie licz­by i ja­koś­ci tes­te­rów oraz spo­so­bu, w ja­ki inter­pre­tu­ją oni kry­te­ria ak­cep­tac­ji. Częstym zja­wi­skiem jest też prze­my­ca­nie przez klienta roz­sze­rzeń funkcjo­nal­noś­ci ja­ko błę­dów w dzia­ła­niu pro­duk­tu. Zdarza się też, że klient na póź­nych eta­pach pro­jek­tu wręcz zmie­nia kry­te­ria ak­cep­tac­ji na pod­sta­wie do­tych­cza­so­wych do­świad­czeń z tes­to­wy­mi wer­sja­mi pro­duk­tu. Można to przy­jąć, je­że­li zmia­ny uściś­la­ją lub uprasz­cza­ją pew­ne kwe­stie, lecz na­le­ży prze­ciw­sta­wić się zmia­nom któ­re mo­gą spo­wo­do­wać zwięk­sze­nie za­kre­su po­trzeb­nych prac lub cał­ko­wi­tą prze­bu­do­wę już stwo­rzo­nych częś­ci pro­duk­tu.

Nie jest też do­brym po­mys­łem wy­dzie­la­nie cza­su (lub od­ręb­ne­go sprin­tu) na wy­szu­ki­wa­nie i usu­wa­nie uste­rek. Powoduje to, że ze­spół nie przy­kła­da wa­gi do tes­to­wa­nia pro­duk­tu oraz usu­wa­nia zna­nych błę­dów, cze­ka­jąc na wy­dzie­lo­ny etap pro­jek­tu ma­ją­cy na ce­lu po­pra­wę ja­koś­ci. Nawarstwie­nie się wie­lu uste­rek mo­że spo­wo­do­wać, że etap ten zna­czą­co się prze­dłu­ży, ni­we­cząc wy­sił­ki zwią­za­ne z prze­wi­dy­wa­niem cza­su reali­zac­ji i ter­mi­nu od­bio­ru.

Jako kwe­stie naj­waż­niej­sze dla po­myśl­ne­go prze­trwa­nia te­stów ak­cep­ta­cyj­nych pre­le­gent­ka wska­za­ła ja­sne usta­le­nie i wią­żą­ce za­twier­dze­nie kry­teriów ak­cep­tac­ji pro­duk­tu, zbu­do­wa­nie moż­li­wie zwar­tych i do­brze współ­pra­cu­ją­cych ze­spo­łów te­sto­wych po oby­dwu stro­nach, kla­row­ne i czy­tel­ne za­pi­sy­wa­nie za­dań do zrea­li­zo­wa­nia przez pro­gra­mis­tów, a prze­de wszyst­kim do­bre, od­po­wie­dzial­ne i wszech­stron­ne te­sto­wa­nie pro­duk­tu przez tes­te­rów.


Jak zwyk­le po spot­ka­niu z se­rii „Uszanowanko Programowanko” po ostat­niej pre­zen­tac­ji uczest­ni­cy mie­li czas na wspól­ne roz­mo­wy, w tym na za­da­wa­nie py­tań pre­le­gen­tom. Wszyscy zo­sta­li też po­czę­sto­wa­ni pizzą oraz na­po­ja­mi. Poziom or­ga­ni­za­cyj­ny i me­ry­to­rycz­ny by­ły jak zwyk­le bar­dzo wy­so­kie. Poruszane by­ły kwe­stie istot­ne dla pro­gra­mis­tów, tes­te­rów oraz kad­ry za­rzą­dza­ją­cej i choć na pew­no te­ma­ty te nie zo­sta­ły wy­czer­pa­ne, to przed­sta­wio­ne in­for­mac­je sta­no­wią pod­sta­wę dla dal­szych po­szu­ki­wań lub szko­leń.