On 23 Maj, 08:01, Andrzej Jarzabek <a...@g...com> wrote:

> A ja się jeszcze nigdy nie spotkałem przy żadnym większym produkcie
> kompercyjnym żeby nie było procesu wymuszającego testy.

Ależ proces może sobie wymuszać. I testy są. Za wyjątkiem miejsc,
gdzie ich nie ma i wszyscy te miejsca omijają milczeniem, bo ani
zleceniodawca ani wykonawca nie wie, jak się zabrać za ich testowanie.
Jak w przykładowym "ruch komunikatów ma być płynny".
Właśnie dlatego odbiór projektu wcale nie polega na uruchomieniu
testów "z automata".
Skoro widziałeś większe produkty komercyjne, to przypomnij sobie, jak
wyglądał ich odbiór. Dry-runs, "wygrzewanie", mniej lub bardziej
ochotniczy beta-testerzy, itd. I na koniec jeszcze okres gwarancyjny.
Te wszystkie rzeczy istnieją i są praktykowane właśnie dlatego, że
testy z automata to pikuś, nawet jeśli masz 100% pokrycia.

Nikt nie kupuje samochodu na podstawie kwitu z automatycznej stacji
diagnostycznej.

> > Automatycznego testu nie ma sensu
> > robić, bo jest to zbyt kosztowne (albo w praktyce w ogóle niemożliwe)
> > w stosunku do efektu. Takie rzeczy testuję przy użyciu paczki czipsów,
> > czyli robię testowy system, który wizualizuje mi się na ekranie, kładę
> > nogi na stole i przy ostatnim czipsie wiem, czy działa poprawnie.
>
> A możesz wyjaśnić, dlaczego tych danych, które wizualizujesz nie da się
> przetestować automatycznie? To, o czym pisałeś nie da się powiązać z
> jakąś mierzalną np. statystyczną właściwością danych?

Oczywiście, że się da. Z wieloma mierzalnymi miarami, zwłaszcza z ROI
(Return On Investment). Ta miara mówi, że nie ma sensu tego robić,
nawet jeśli teoretycznie jest to możliwe. Dlatego nie robię i nie dam
sobie tego wcisnąć "bo agile tak mówi" (a "Słowacki wielkim poetą
był").

Inne przykłady:

1. Jakiś czas temu jeden z naszych grupowych kolegów (Sebastian Biały?
bardzo przepraszam, jeśli nie pamiętam dokładnie) pokazywał efekty
swojego programu do wyostrzania zdjęć. Wyniki są fantastyczne.
Obstawiam, że nie robił tego przez TDD. Nie interesuje mnie, czy
jakość tych algorytmów da się powiązać z czymkolwiek mierzalnym, bo
*to nie ma sensu*. Miarą jakości jest tutaj opad szczęki a nie test "z
automata".

2. Algorytm pogłosowy dla muzyków. Albo automatyczny aranżer w stylu
wczesny japoński jazz alternatywny. TDD? Bez jaj.

Takich przykładów oczywiście jest więcej. A ponieważ informatyka służy
do poprawiania nam życia, to takich wymagania są praktycznie w każdym
systemie, może poza projektami studenckimi typu "napisać AVL".
Oczywiście te wszystkie systemy w skali mikro składają się z
drobiazgów, które da się pojedynczo objąć przez TDD, ale to jest skala
mikro i żabia perspektywa. Dla takich wymagań ostatecznym arbitrem od
strony konsumenta nie są testy z automata, tylko jazda próbna, albo
paczka czipsów.

Są też projekty, które można i warto jak najpełniej formalizować
(najczęściej ogólnie rozumiane sterowanie procesami fizycznymi) - tam
nie ma miejsca na elementy psychologiczne w ocenie jakości a działanie
systemu da się dobrze opisać matematycznie. Ale uwaga, bo to jest
ciekawe: właśnie w takich projektach waterfall sprawdza się bardzo
dobrze.

Paru gości usiłuje pogodzić nurt agile z realiami systemów krytycznych
(które zwykle dotyczą sterowania), dobre hasło to "Continuous
Certification":

http://www.open-do.org/

ale z tego co wiem, to bardzo opornie im to idzie.

[...]

> Tak, automatyczne testowanie GUI to sprawdzanie czy naciśnięcie
> przycisku powoduje pokazanie się odpowiedniego okienka, czy w gridzie są
> odpowiednie dane itd. Pożytek z tego jest duży.

A taki np. mBank nie potrafi nawet zaakceptować wartości, którą sam
wyświetla (np. jeśli na koncie jest "1 234,56", to nie można tego
przelać przez copy-paste).
Może robią automatycznie testy tego "GUI". A może nie robią. Nie ma to
znaczenia, bo testy tego typu mają złą granulację.

(to tylko przykład tego, że testy GUI nie działają na odpowiednim
poziomie)

> "Display" to monitor do komputera.

"Display" w tym sensie, w jakim to użyłem, to ogół środków
technicznych służących do wyświetlenia czegoś. JButton należy do tej
grupy.

> Alternatywa jest taka, że klient ufa, że twoi specjaliści rozpoznają
> jego potrzeby biznesowe i że ty będziesz te potrzeby implementował tak,
> żeby zmaksymalizować wartość programu dla niego, i to zaufanie też ma
> odzwierciedlenie w umowie.

No właśnie. Nie mówmy "robimy agile, więc będzie dobrze". Mówmy
"potrafimy rozpoznać Twoje potrzeby, więc będzie dobrze". Jedno i
drugie to prymitywny marketing, ale przynajmniej w tym drugim
przypadku stajemy się odpowiedzialnymi właścicielami końcowego efektu/
klęski i nie zwalamy tego na jakiś proces.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com