Robię to zawsze a najrzadziej o tym pisze, bo to “takie oczywiste”, a co to takiego? TESTY. Dobrze opracowane testy to ciekawa i wyrafinowana forma sprawdzania tego czy dostajemy to co chcemy dostać, to za co płacimy (nie raz słono). Czym są (powinny być) kryteria akceptacji? To właśnie wymagania, pozostaje pytanie: Które? Jeżeli to będą pierwotne wymagania biznesowe jest źle (patrz: Przypadki użycia to nie wymagania). Wiec co? Wymaganiem jest model: zamawiana konstrukcja, mechanizm działania.

V-model czyli wprowadzenie

Ogólnym, najczęściej przytaczanym modelem opisującym cykl wytwarzania w inżynierii jest tak zwany V-model, prezentowany w poniższej ogólnej postaci:

V-model składa się z części: projektowanie, implementacja, testowanie, powtórzenie tego cyklu to rozwój (testy to kryteria akceptacji). Model ten stanowi fundament rozważań o testach, gdyż test to sprawdzenie, a sprawdzenie polega na porównaniu z wzorcem. Co jest wzorcem? Obietnica. A co jest tą obietnicą? Model tego co ma (miało) powstać.

Ważne pytanie: Czym jest inżynieria?

Engineering is the designing, testing and building of machines, structures and processes using maths and science.
[Inżynieria to projektowanie, testowanie i budowanie maszyn, struktur i procesów przy użyciu matematyki i nauki.]

(żr.: https://www.bath.ac.uk/campaigns/what-is-engineering/)

Tak więc mówimy o projektowaniu. Na etapie prac inżynierskich powstają: koncepcja i zakres produktu (Concept of Operations), następnie wymagania (Requirements and Architecture) i w końcu projekt (Detailed Design). Kolejny etap to implementacja czyli proces opracowania technologii wykonania i wykonanie produktu (produktem nazywamy przedmiot jaki ma powstać). Powyższe dotyczy każdego produktu inżynierii.

Powstaje więc często pytanie: Czy to co nam dostarczono jest tym co chcieliśmy dostać?

Przedmiot testowania a podmiot testujący

Kluczowe pojęcia w tym wpisie (źr.: sł. j. polskiego 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 wieloznaczne zostały pozostawione z definicjami używanymi w dziedzinie inżynierii. Dla lepszego zrozumienia i zarazem przetestowania spójności tego zestawu pojęć, tworzymy model pojęciowy w postaci diagramu opisującego pojęcia i związki między nimi (ontologia wyrażona graficznie):

Model pojęciowy jak ten powyżej, to test jednoznaczności zdań budowanych z pojęć, których spójność, kompletność i niesprzeczność chcemy wykazać. Każda para pojęć połączonych predykatem powinna tworzyć zdanie prawdziwe w analizowanej dziedzinie (taki model powinna zawierać każda analiza biznesowa i specyfikacja wymagań!)

Tak więc przedmiotem testowania jest komputer, a nie – jak sie potocznie mówi – oprogramowanie. Oprogramowanie to tekst (zestaw instrukcji dla procesora), który umieszczony w pamięci komputera, intepretowany przez procesor jako program do wykonania. To z czego korzystamy to urządzenie jakim jest komputer, ten zaś jako całość realizuje określony mechanizm (patrz artykuł Prawo autorskie w projektach IT). Nawet siedząc i czytając ten artykuł korzystasz czytelniku z komputera a nie z “oprogramowania”. Dlatego w nauce (tu information science) mówi się, że komputer to ‘uniwersalny mechanizm’ .

Badanym (testowanym) przedmiotem jest więc komputer (ten zawiera oprogramowanie), który musi spełniać wymagania, a wymaganiem jest projekt mechanizmu jaki realizuje. Dlaczego wymaganiem jest projekt a nie “wymagania”? Bo V-model to także pętla zarządzania jakością, tę pętlę zamyka “strzałka w lewo”: weryfikacja i walidacja. Jest to tak zwana Pętla Cyklu Życia Oprogramowania (ang. SDLC):

Z perspektywy inżynierii Zamawiający (podmiot) zamawia produkt (przedmiot). Aby wyrazić to co zamawia, musi określić swoje wymagania. Wymagania można określić na trzy typowe sposoby:

1. potrzeba (chce przedmiot który pomoże mi w…., posłuży do…)
2. warunki (przedmiot powinien mieć wymagane cechy:…)
3. projekt (to jest opis tego jak jest zbudowany i jak ma działać przedmiot, czasami można użyć analogii: chce coś takiego jak …)

Powyższe to nic innego jak lewa strona V-modelu: to są wzorce, a testowanie to ocena zgodności tego co powstało z wzorcem tego co miało powstać, czyli z tym co zaprojektowano (z projektem). Te trzy etapy są zgodne z MDA: analiza biznesowa (CIM, Computation Independent Model), określenie zakresu produktu (przypadki użycia), opracowanie mechanizmu działania (PIM, Platform Independent Model). Model PSM (Platform Specific Model) jest pierwszym etapem implementacji .

W projektach z zakresu inżynierii oprogramowania V-model jest często przedstawiany jak poniżej:

A jak to widzi i czuje w kieszeni klient

Bo pytanie brzmi: kto, co i kiedy, tak na prawdę testuje. Popatrzmy na to od końca, czyli od momentu gdy dostajemy gotowy produkt:
1. Dostawca oprogramowania udziela rękojmi (musi zgodnie z prawem)
2. Dostawca oprogramowania może udzielić gwarancji
3. Zamawiający oczekuje oprogramowania zgodnie z zamówieniem
4. W dniu odbioru Zamawiający dokonuje podstawowego przeglądu na zgodność z zamówieniem (taka jazda próbna przy odbiorze samochodu), podstawą odbioru jest LISTA POTRZEB.
5. Z uwagi na złożoność oprogramowania (podobnie jak i samochodu) w okresie rękojmi (i gwarancji) wady mozna zgłaszać do dostawcy przez ustalony okres czasu od dnia odbioru, tu podstawą zgłaszania wad jest dokumentacja opisująca mechanizmy i algorytmy działania (czyli co i jak powinno zostać policzone i jaki powinien pokazać się wynik).
6. Po zakończeniu okresu rękojmi i gwarancji przechodzimy do fazy utrzymania i rozwoju na własny koszt (dlatego tak ważne jest zabezpieczenie przed zjawiskiem zwanym vendor lock-in!).

Od góry (przytaczam ponownie V-model po prawej):

1. Po dokonaniu odbioru i przejścia do fazy eksploatacji systemu, weryfikowana jest (przez życie) koncepcja i cele wdrożenia.
2. Na etapie odbioru systemu weryfikujemy zgodność z wymaganiami i architekturą HLD
3. Na etapie wytwarzania weryfikujemy wewnętrzną spójność i poprawność działania.
4. Etap implementacji to cała praca nad doborem technologii, konfiguracją środowiska i napisaniem brakującego kodu (wbrew proporcjom na diagramie, jest to najkosztowniejsza część projektu).

Rękojmia i gwarancja to usuwanie wad i niezgodności odpowiednio na koszt dostawcy i producenta, po dokonaniu odbioru. Sam odbiór to testy zgodności: czego i z czym? I teraz pytanie do Zamawiającego:
a. czy masz aktualną dla projektu listę potrzeb i kto jej jej autorem?
b. czy masz dokumentacją mechanizmu działania aplikacji i kto jest jej autorem?
c. kto ma prawa majątkowe do tych dokumentów?

Testy odbiorcze to scenariusze. kto je opracował? Sprawdzany czy sprawdzający? Czy wiesz więc za co płacisz? Czy jesteś pewien że treści i liczby na generowanych z systemu dokumentach są poprawne? Czy może czytelniku dałeś sobie wmówić, że jedyna prawdziwa dokumentacja oprogramowania to działający kod? A czy TY jesteś w stanie z takiej “dokumentacji” skorzystać? Więc za co Wy płacicie? Za to, że kazali Wam zapłacić?

Kilka słów o mechanizmie

Przypomnijmy definciję:

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?

Innymi słowy, jeżeli chcemy świadomie uzyskać określony efekt, to musimy określić mechanizm jego powstawania. Model-based System Engineering (MBSE) to metodyka podejścia do projektowania i inżynierii oparta na modelowaniu . Poniżej często przytaczany model obrazujący związek wymagań z mechanizmem (modelem) działania systemu:

Mamy trzy ściśle powiązane perspektywy: wymagania, struktura (architektura) systemu oraz jego zachowanie. Jeżeli wyrazimy je jako modele, to powstaną trzy ścisłe z soba powiązane: model wymagań, model struktury i model zachowania. W przypadku inżynierii systemów stosujemy od lat notację SysML (jest to specjalny profil notacji UML). Te trzy modele muszą być spójne, kompletne i niesprzeczne, bez czego system, jaki na ich podstawie powstanie, będzie wykazywał błędy. Dlatego tak na prawdę model systemu to te trzy modele i ich TESTY w postaci macierzy zgodności (chodzi o kontrole tych czarnych punktów na diagramie powyżej) .

Po co nam model na etapie wymagań? Same wymagania to tak zwany opis “czarnej skrzynki”: wiemy jaki efekt obserwujemy ale nie wiemy jak powstał. Czy to groźne? Bardzo, bo np. zegar jaki obserwujemy na pulpicie komputera to może być prosty mechanizm pokazujący zmieniające się co sekundę kolejne obrazy tarczy zegara (43.200 obrazów i prosty mechanizm ich kolejnego wyświetlania) lub model opisujący mechanizm pomiaru czasu i dynamicznego generowania obrazu pokazującego aktualną godzinę (patrz artykuł o zegarze: Model dziedziny jako mechanizm). Ten pierwszy będzie tanim w wykonaniu i koszmarnie kosztownym w utrzymaniu i rozwoju systemem, drugi – mimo kosztów projektowania – będzie niewiele droższy na etapie wykonania ale będzie o całe rzędy tańszy na etapie utrzymania i rozwoju. Proste testy odbioru “czarnej skrzynki” niczego złego nie pokażą, system zostanie odebrany. Gehenna zacznie się przy próbie pierwszej zmiany np. koloru tarczy… Dlatego MBSE to podejście nazywane często: “projekt systemu jako wymaganie” (pamiętamy żarty o maszynie do obierania ziemniaków, w której był zamknięty człowiek).

Podsumowanie

Testy to sprawdzenie, a tu mamy (powinniśmy mieć) jasny podział na sprawdzającego i sprawdzanego. Typowe dla rynku IT jest wmawianie klientom, że nie mają żadnych kompetencji do analiz, testów, projektowania, że wszystko to zrobi dostawca oprogramowania. Tak więc u tego samego, jednego, dostawcy oprogramowania zamawiana jest: analiza biznesowa, analizy wymagań, projektowanie, implementacja, pisanie testów odbiorczych i testy. Podmiot jakim jest Zamawiający w zasadzie tylko patrzy, i płaci tyle ile chcą dostawcy (projekty T&M to brak kontroli). W efekcie sprawdzający i sprawdzany to ten sam podmiot. Czy to ma sens?

Ostatecznym testem jest to “jak to wszystko działa w praktyce” czyli średnio i długo terminowe efekty wdrożenia. To zaś zależy od dwóch kluczowych rzeczy:

• pierwotnej koncepcji biznesowej: wpływ wdrożonego oprogramowania na biznes, oraz
• wewnętrznej architektury oprogramowania: wpływ na koszty utrzymania i rozwoju.

Oba powyższe elementy to lewa strona V-modelu. Biorąc pod uwagę fakt, że koszty utrzymania i rozwoju to konsekwencja wewnętrznej architektury, dostawcy systemów bardzo często forsują rezygnacje z rękojmi i gwarancji (wtedy nie ponoszą finansowych skutków niskiej jakości projektu i implementacji). Co to znaczy? Że jeżeli mamy mieć faktyczny podział na sprawdzającego i sprawdzanego, analiza i projektowanie powinna mieć miejsce po stronie Zamawiającego przed wyborem dostawcy. Jak? Po prostu zatrudnić inżyniera do analiz i projektowania oraz do nadzoru, bo praktyka pokazuje, że wtedy może być znacznie szybciej i nawet 10-krotnie taniej.

A teraz pytanie: co i jak testować gdy skastomizujesz kupiony duży gotowy system z tysiącem tabel w bazie danych? Pamiętaj też, że kastomizacja kodu to utrata gwarancji producenta.

Źródła