Robię to zawsze a naj­rza­dziej o tym pisze, bo to ​„takie oczy­wi­ste”, a co to takie­go? TESTY. Dobrze opra­co­wa­ne testy to cie­ka­wa i wyra­fi­no­wa­na for­ma spraw­dza­nia tego czy dosta­je­my to co chce­my dostać, to za co pła­ci­my (nie raz sło­no). Czym są (powin­ny być) kry­te­ria akcep­ta­cji? To wła­śnie wyma­ga­nia, pozo­sta­je pyta­nie: Które? Jeżeli to będą pier­wot­ne wyma­ga­nia biz­ne­so­we jest źle (patrz: Przypadki uży­cia to nie wyma­ga­nia). Wiec co? Wymaganiem jest model: zama­wia­na kon­struk­cja, mecha­nizm działania. 

V‑model czyli wprowadzenie

Ogólnym, naj­czę­ściej przy­ta­cza­nym mode­lem opi­su­ją­cym cykl wytwa­rza­nia w inży­nie­rii jest tak zwa­ny V‑model, pre­zen­to­wa­ny w poniż­szej ogól­nej postaci:

V‑model skła­da się z czę­ści: pro­jek­to­wa­nie, imple­men­ta­cja, testo­wa­nie, powtó­rze­nie tego cyklu to roz­wój (testy to kry­te­ria akcep­ta­cji). Model ten sta­no­wi fun­da­ment roz­wa­żań o testach, gdyż test to spraw­dze­nie, a spraw­dze­nie pole­ga na porów­na­niu z wzor­cem. Co jest wzor­cem? Obietnica. A co jest tą obiet­ni­cą? Model tego co ma (mia­ło) powstać. 

Ważne pyta­nie: Czym jest inżynieria? 

Engineering is the desi­gning, testing and buil­ding of machi­nes, struc­tu­res and pro­ces­ses using maths and scien­ce.
[Inżynieria to pro­jek­to­wa­nie, testo­wa­nie i budo­wa­nie maszyn, struk­tur i pro­ce­sów przy uży­ciu mate­ma­ty­ki i nauki.]

(żr.: https://​www​.bath​.ac​.uk/​c​a​m​p​a​i​g​n​s​/​w​h​a​t​-​i​s​-​e​n​g​i​n​e​e​r​i​ng/)

Tak więc mówi­my o pro­jek­to­wa­niu. Na eta­pie prac inży­nier­skich powsta­ją: kon­cep­cja i zakres pro­duk­tu (Concept of Operations), następ­nie wyma­ga­nia (Requirements and Architecture) i w koń­cu pro­jekt (Detailed Design). Kolejny etap to imple­men­ta­cja czy­li pro­ces opra­co­wa­nia tech­no­lo­gii wyko­na­nia i wyko­na­nie pro­duk­tu (pro­duk­tem nazy­wa­my przed­miot jaki ma powstać). Powyższe doty­czy każ­de­go pro­duk­tu inżynierii. 

Powstaje więc czę­sto pyta­nie: Czy to co nam dostar­czo­no jest tym co chcie­li­śmy dostać?

Przedmiot testowania a podmiot testujący

Kluczowe poję­cia w tym wpi­sie (źr.: sł. j. pol­skie­go PWN):

test: próba, której poddaje się urządzenie, produkt, preparat itp. w celu sprawdzenia jego składu, właściwości i działania; też: to, co służy do przeprowadzenia takiej próby
scenariusz: zaplanowany lub przewidywany rozwój wydarzeń
przedmiot: rzecz, materialny element świata
podmiot:
1. ?nadrzędna część zdania nazywająca osobę, rzecz lub zjawisko, o którym się w zdaniu orzeka?
2. ?osoba aktywna, uczestnicząca w czymś?
3. filoz. ?umysł poznawczy w przeciwieństwie do przedmiotu, który jest poznawany?
4. ?osoba fizyczna lub prawna mogąca mieć prawa i obowiązki?
projekt:
1. ?plan działania?
2. ?wstępna wersja czegoś?
3. ?dokument zawierający obliczenia, rysunki itp. dotyczące wykonania jakiegoś obiektu lub urządzenia?
komputer: ?urządzenie elektroniczne automatycznie przetwarzające dane zapisane cyfrowo, służące do szybkiego wykonywania obliczeń, przechowywania, porządkowania i wyszukiwania danych oraz sterowania pracą innych urządzeń? (definicja sprawozdawcza)
komputer: urządzenie zawierające procesor, pamięć i program (definicja realna)
mechanizm: 
1. ?zespół współpracujących ze sobą części maszyny lub przyrządu, wykonujących jakąś pracę?
2. ?sposób, w jaki coś powstaje, przebiega lub działa?
wymaganie: ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?

Pojęcia wie­lo­znacz­ne zosta­ły pozo­sta­wio­ne z defi­ni­cja­mi uży­wa­ny­mi w dzie­dzi­nie inży­nie­rii. Dla lep­sze­go zro­zu­mie­nia i zara­zem prze­te­sto­wa­nia spój­no­ści tego zesta­wu pojęć, two­rzy­my model poję­cio­wy w posta­ci dia­gra­mu opi­su­ją­ce­go poję­cia i związ­ki mię­dzy nimi (onto­lo­gia wyra­żo­na graficznie):

Model poję­cio­wy jak ten powy­żej, to test jed­no­znacz­no­ści zdań budo­wa­nych z pojęć, któ­rych spój­ność, kom­plet­ność i nie­sprzecz­ność chce­my wyka­zać. Każda para pojęć połą­czo­nych pre­dy­ka­tem powin­na two­rzyć zda­nie praw­dzi­we w ana­li­zo­wa­nej dzie­dzi­nie (taki model powin­na zawie­rać każ­da ana­li­za biz­ne­so­wa i spe­cy­fi­ka­cja wymagań!)

Tak więc przed­mio­tem testo­wa­nia jest kom­pu­ter, a nie – jak sie potocz­nie mówi – opro­gra­mo­wa­nie. Oprogramowanie to tekst (zestaw instruk­cji dla pro­ce­so­ra), któ­ry umiesz­czo­ny w pamię­ci kom­pu­te­ra, inte­pre­to­wa­ny przez pro­ce­sor jako pro­gram do wyko­na­nia. To z cze­go korzy­sta­my to urzą­dze­nie jakim jest kom­pu­ter, ten zaś jako całość reali­zu­je okre­ślo­ny mecha­nizm (patrz arty­kuł Prawo autor­skie w pro­jek­tach IT). Nawet sie­dząc i czy­ta­jąc ten arty­kuł korzy­stasz czy­tel­ni­ku z kom­pu­te­ra a nie z ​„opro­gra­mo­wa­nia”. Dlatego w nauce (tu infor­ma­tion scien­ce) mówi się, że kom­pu­ter to «uni­wer­sal­ny mecha­nizm» .

Badanym (testo­wa­nym) przed­mio­tem jest więc kom­pu­ter (ten zawie­ra opro­gra­mo­wa­nie), któ­ry musi speł­niać wyma­ga­nia, a wyma­ga­niem jest pro­jekt mecha­ni­zmu jaki reali­zu­je. Dlaczego wyma­ga­niem jest pro­jekt a nie ​„wyma­ga­nia”? Bo V‑model to tak­że pętla zarzą­dza­nia jako­ścią, tę pętlę zamy­ka ​„strzał­ka w lewo”: wery­fi­ka­cja i wali­da­cja. Jest to tak zwa­na Pętla Cyklu Życia Oprogramowania (ang. SDLC):

Z per­spek­ty­wy inży­nie­rii Zamawiający (pod­miot) zama­wia pro­dukt (przed­miot). Aby wyra­zić to co zama­wia, musi okre­ślić swo­je wyma­ga­nia. Wymagania moż­na okre­ślić na trzy typo­we sposoby:

1. potrze­ba (chce przed­miot któ­ry pomo­że mi w.…, posłu­ży do…)
2. warun­ki (przed­miot powi­nien mieć wyma­ga­ne cechy:…)
3. pro­jekt (to jest opis tego jak jest zbu­do­wa­ny i jak ma dzia­łać przed­miot, cza­sa­mi moż­na użyć ana­lo­gii: chce coś takie­go jak …)

Powyższe to nic inne­go jak lewa stro­na V‑modelu: to są wzor­ce, a testo­wa­nie to oce­na zgod­no­ści tego co powsta­ło z wzor­cem tego co mia­ło powstać, czy­li z tym co zapro­jek­to­wa­no (z pro­jek­tem). Te trzy eta­py są zgod­ne z MDA: ana­li­za biz­ne­so­wa (CIM, Computation Independent Model), okre­śle­nie zakre­su pro­duk­tu (przy­pad­ki uży­cia), opra­co­wa­nie mecha­ni­zmu dzia­ła­nia (PIM, Platform Independent Model). Model PSM (Platform Specific Model) jest pierw­szym eta­pem imple­men­ta­cji .

W pro­jek­tach z zakre­su inży­nie­rii opro­gra­mo­wa­nia V‑model jest czę­sto przed­sta­wia­ny jak poniżej:

A jak to widzi i czuje w kieszeni klient

Bo pyta­nie brzmi: kto, co i kie­dy, tak na praw­dę testu­je. Popatrzmy na to od koń­ca, czy­li od momen­tu gdy dosta­je­my goto­wy pro­dukt:
1. Dostawca opro­gra­mo­wa­nia udzie­la rękoj­mi (musi zgod­nie z pra­wem)
2. Dostawca opro­gra­mo­wa­nia może udzie­lić gwa­ran­cji
3. Zamawiający ocze­ku­je opro­gra­mo­wa­nia zgod­nie z zamó­wie­niem
4. W dniu odbio­ru Zamawiający doko­nu­je pod­sta­wo­we­go prze­glą­du na zgod­ność z zamó­wie­niem (taka jaz­da prób­na przy odbio­rze samo­cho­du), pod­sta­wą odbio­ru jest LISTA POTRZEB.
5. Z uwa­gi na zło­żo­ność opro­gra­mo­wa­nia (podob­nie jak i samo­cho­du) w okre­sie rękoj­mi (i gwa­ran­cji) wady mozna zgła­szać do dostaw­cy przez usta­lo­ny okres cza­su od dnia odbio­ru, tu pod­sta­wą zgła­sza­nia wad jest doku­men­ta­cja opi­su­ją­ca mecha­ni­zmy i algo­ryt­my dzia­ła­nia (czy­li co i jak powin­no zostać poli­czo­ne i jaki powi­nien poka­zać się wynik).
6. Po zakoń­cze­niu okre­su rękoj­mi i gwa­ran­cji prze­cho­dzi­my do fazy utrzy­ma­nia i roz­wo­ju na wła­sny koszt (dla­te­go tak waż­ne jest zabez­pie­cze­nie przed zja­wi­skiem zwa­nym ven­dor lock-in!).

Od góry (przy­ta­czam ponow­nie V‑model po prawej): 

1. Po doko­na­niu odbio­ru i przej­ścia do fazy eks­plo­ata­cji sys­te­mu, wery­fi­ko­wa­na jest (przez życie) kon­cep­cja i cele wdrożenia.
2. Na eta­pie odbio­ru sys­te­mu wery­fi­ku­je­my zgod­ność z wyma­ga­nia­mi i archi­tek­tu­rą HLD
3. Na eta­pie wytwa­rza­nia wery­fi­ku­je­my wewnętrz­ną spój­ność i popraw­ność działania.
4. Etap imple­men­ta­cji to cała pra­ca nad dobo­rem tech­no­lo­gii, kon­fi­gu­ra­cją śro­do­wi­ska i napi­sa­niem bra­ku­ją­ce­go kodu (wbrew pro­por­cjom na dia­gra­mie, jest to naj­kosz­tow­niej­sza część projektu). 

Rękojmia i gwa­ran­cja to usu­wa­nie wad i nie­zgod­no­ści odpo­wied­nio na koszt dostaw­cy i pro­du­cen­ta, po doko­na­niu odbio­ru. Sam odbiór to testy zgod­no­ści: cze­go i z czym? I teraz pyta­nie do Zamawiającego:
a. czy masz aktu­al­ną dla pro­jek­tu listę potrzeb i kto jej jej auto­rem?
b. czy masz doku­men­ta­cją mecha­ni­zmu dzia­ła­nia apli­ka­cji i kto jest jej auto­rem?
c. kto ma pra­wa mająt­ko­we do tych dokumentów?

Testy odbior­cze to sce­na­riu­sze. kto je opra­co­wał? Sprawdzany czy spraw­dza­ją­cy? Czy wiesz więc za co pła­cisz? Czy jesteś pewien że tre­ści i licz­by na gene­ro­wa­nych z sys­te­mu doku­men­tach są popraw­ne? Czy może czy­tel­ni­ku dałeś sobie wmó­wić, że jedy­na praw­dzi­wa doku­men­ta­cja opro­gra­mo­wa­nia to dzia­ła­ją­cy kod? A czy TY jesteś w sta­nie z takiej ​„doku­men­ta­cji” sko­rzy­stać? Więc za co Wy pła­ci­cie? Za to, że kaza­li Wam zapłacić?

Kilka słów o mechanizmie

Przypomnijmy defin­ci­ję:

mecha­nizm: 1. ?zespół współ­pra­cu­ją­cych ze sobą czę­ści maszy­ny lub przy­rzą­du, wyko­nu­ją­cych jakąś pra­cę? 2. ?spo­sób, w jaki coś powsta­je, prze­bie­ga lub działa?

Innymi sło­wy, jeże­li chce­my świa­do­mie uzy­skać okre­ślo­ny efekt, to musi­my okre­ślić mecha­nizm jego powsta­wa­nia. Model-based System Engineering (MBSE) to meto­dy­ka podej­ścia do pro­jek­to­wa­nia i inży­nie­rii opar­ta na mode­lo­wa­niu . Poniżej czę­sto przy­ta­cza­ny model obra­zu­ją­cy zwią­zek wyma­gań z mecha­ni­zmem (mode­lem) dzia­ła­nia systemu:

Mamy trzy ści­śle powią­za­ne per­spek­ty­wy: wyma­ga­nia, struk­tu­ra (archi­tek­tu­ra) sys­te­mu oraz jego zacho­wa­nie. Jeżeli wyra­zi­my je jako mode­le, to powsta­ną trzy ści­słe z soba powią­za­ne: model wyma­gań, model struk­tu­ry i model zacho­wa­nia. W przy­pad­ku inży­nie­rii sys­te­mów sto­su­je­my od lat nota­cję SysML (jest to spe­cjal­ny pro­fil nota­cji UML). Te trzy mode­le muszą być spój­ne, kom­plet­ne i nie­sprzecz­ne, bez cze­go sys­tem, jaki na ich pod­sta­wie powsta­nie, będzie wyka­zy­wał błę­dy. Dlatego tak na praw­dę model sys­te­mu to te trzy mode­le i ich TESTY w posta­ci macie­rzy zgod­no­ści (cho­dzi o kon­tro­le tych czar­nych punk­tów na dia­gra­mie powy­żej) .

Po co nam model na eta­pie wyma­gań? Same wyma­ga­nia to tak zwa­ny opis ​„czar­nej skrzyn­ki”: wie­my jaki efekt obser­wu­je­my ale nie wie­my jak powstał. Czy to groź­ne? Bardzo, bo np. zegar jaki obser­wu­je­my na pul­pi­cie kom­pu­te­ra to może być pro­sty mecha­nizm poka­zu­ją­cy zmie­nia­ją­ce się co sekun­dę kolej­ne obra­zy tar­czy zega­ra (43.200 obra­zów i pro­sty mecha­nizm ich kolej­ne­go wyświe­tla­nia) lub model opi­su­ją­cy mecha­nizm pomia­ru cza­su i dyna­micz­ne­go gene­ro­wa­nia obra­zu poka­zu­ją­ce­go aktu­al­ną godzi­nę (patrz arty­kuł o zega­rze: Model dzie­dzi­ny jako mecha­nizm). Ten pierw­szy będzie tanim w wyko­na­niu i kosz­mar­nie kosz­tow­nym w utrzy­ma­niu i roz­wo­ju sys­te­mem, dru­gi – mimo kosz­tów pro­jek­to­wa­nia – będzie nie­wie­le droż­szy na eta­pie wyko­na­nia ale będzie o całe rzę­dy tań­szy na eta­pie utrzy­ma­nia i roz­wo­ju. Proste testy odbio­ru ​„czar­nej skrzyn­ki” nicze­go złe­go nie poka­żą, sys­tem zosta­nie ode­bra­ny. Gehenna zacznie się przy pró­bie pierw­szej zmia­ny np. kolo­ru tar­czy… Dlatego MBSE to podej­ście nazy­wa­ne czę­sto: ​„pro­jekt sys­te­mu jako wyma­ga­nie” (pamię­ta­my żar­ty o maszy­nie do obie­ra­nia ziem­nia­ków, w któ­rej był zamknię­ty człowiek). 

Podsumowanie

Testy to spraw­dze­nie, a tu mamy (powin­ni­śmy mieć) jasny podział na spraw­dza­ją­ce­go i spraw­dza­ne­go. Typowe dla ryn­ku IT jest wma­wia­nie klien­tom, że nie mają żad­nych kom­pe­ten­cji do ana­liz, testów, pro­jek­to­wa­nia, że wszyst­ko to zro­bi dostaw­ca opro­gra­mo­wa­nia. Tak więc u tego same­go, jed­ne­go, dostaw­cy opro­gra­mo­wa­nia zama­wia­na jest: ana­li­za biz­ne­so­wa, ana­li­zy wyma­gań, pro­jek­to­wa­nie, imple­men­ta­cja, pisa­nie testów odbior­czych i testy. Podmiot jakim jest Zamawiający w zasa­dzie tyl­ko patrzy, i pła­ci tyle ile chcą dostaw­cy (pro­jek­ty T&M to brak kon­tro­li). W efek­cie spraw­dza­ją­cy i spraw­dza­ny to ten sam pod­miot. Czy to ma sens?

Ostatecznym testem jest to ​„jak to wszyst­ko dzia­ła w prak­ty­ce” czy­li śred­nio i dłu­go ter­mi­no­we efek­ty wdro­że­nia. To zaś zale­ży od dwóch klu­czo­wych rzeczy: 

• pier­wot­nej kon­cep­cji biz­ne­so­wej: wpływ wdro­żo­ne­go opro­gra­mo­wa­nia na biz­nes, oraz 
• wewnętrz­nej archi­tek­tu­ry opro­gra­mo­wa­nia: wpływ na kosz­ty utrzy­ma­nia i rozwoju. 

Oba powyż­sze ele­men­ty to lewa stro­na V‑modelu. Biorąc pod uwa­gę fakt, że kosz­ty utrzy­ma­nia i roz­wo­ju to kon­se­kwen­cja wewnętrz­nej archi­tek­tu­ry, dostaw­cy sys­te­mów bar­dzo czę­sto for­su­ją rezy­gna­cje z rękoj­mi i gwa­ran­cji (wte­dy nie pono­szą finan­so­wych skut­ków niskiej jako­ści pro­jek­tu i imple­men­ta­cji). Co to zna­czy? Że jeże­li mamy mieć fak­tycz­ny podział na spraw­dza­ją­ce­go i spraw­dza­ne­go, ana­li­za i pro­jek­to­wa­nie powin­na mieć miej­sce po stro­nie Zamawiającego przed wybo­rem dostaw­cy. Jak? Po pro­stu zatrud­nić inży­nie­ra do ana­liz i pro­jek­to­wa­nia oraz do nad­zo­ru, bo prak­ty­ka poka­zu­je, że wte­dy może być znacz­nie szyb­ciej i nawet 10-krot­nie taniej.

A teraz pyta­nie: co i jak testo­wać gdy ska­sto­mi­zu­jesz kupio­ny duży goto­wy sys­tem z tysią­cem tabel w bazie danych? Pamiętaj też, że kasto­mi­za­cja kodu to utra­ta gwa­ran­cji producenta.

Źródła