On Dec 19, 1:33 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> > > Acceptance tests mają takie ficzery.
>
> > Ale musiałoby ich być dokładnie tyle, ile byłoby tej dokumentacji,
> > której ma nie być.
>
> Dokładnie.

Nie tylko. Tych notatek z dyskusji też musi być dokładnie tyle samo
(bo informacji nie da się zredukować). I tego właśnie nie rozumiem.
Tradycyjna metoda polega na tym, że się pisze dokumentację, w której
zawarta jest wiedza nt. działania systemu. W agile piszemy notatki,
których jest *tyle samo* (nieredukowalność informacji, sorry, nie ja
stworzyłem świat). A przynajmniej w całej tej dyskusji nie padły żadne
przesłanki do stwierdzenia, że mogłoby ich być mniej.
I teraz okazuje się, że pomimo faktu, że będzie ich tyle samo i będzie
do tego potrzebny taki sam wysiłek pisarski, to musimy je koniecznie
wyrzucić do kosza i to najdalej parę godzin po napisaniu. To bardzo
ważne. Bo jeśli zapomnimy je wyrzucić i się zaczną nam zbierać, to
klient zobaczy plik kartek i jeszcze pomyśli, że my tu jakąś
dokumentację piszemy i okaże się, że król jest nagi a my wcale nie
jesteśmy agile.

Niech mi ktoś wytłumaczy, w czym napisanie notatek i wywalenie ich do
kosza jest lepsze od napisania ich i spięcia w segretatorze.

Pomijając fakt, że w kontekście biznesowym wyrzucanie *czegokolwiek*
do kosza to czysta głupota i zwykle się srogo mści w późniejszym
terminie.
To nie jest żadna metodologia, to jest usankcjonowana
nieodpowiedzialność.

> > Sęk w tym, że nie wszystko, co można napisać w dokumentacji, można
> > zdefiniować w formie testu.
>
> Bywa. Dlatego też zasada nie jest taka, że się w ogóle nie produkuje
> dokumentacji, tylko że dokumentuje się tylko to, czego absolutnie nie
> da się zapisać w postaci testu lub kodu.

Acha - czyli niektóre notatki zachowujemy w segregatorze. Wyrzucamy
(koniecznie!) tylko te, dla których udało nam się napisać acceptance
test.

Sorki, nie kupuję tego.

> Zakładając
> przykładowo, że masz jakiś system, który liczy przejeżdżające
> samochody na podstawie wejścia z jakichś sensorów, to można budować
> testy w oparciu o rzeczywiste lub symulowane dane z tych sensorów.

Ale klienta równo wali, czy to liczenie robi program, czy hardware,
czy krasnoludki. I w ogóle jaki sensor?
Właśnie w tym jest problem, że systemy przemysłowe opisuje się
całościowo, bo tylko w całości one są potrzebne. Wydzielanie granicy
pomiędzy sensorami a programem, jest sztucznym krokiem, który z punktu
widzenia klienta nic nie wnosi - dlatego nie wierzę, że OSCRowi będzie
się chciało robić taki test. OSCR tego nie widzi. On widzi samochody.

W ogóle mam wrażenie, że agile wraz z całą swoją kulturą testowania
jest bardzo nakierowany na założenie, że produktem jest jakiś program.
Pewnie działa to jakość w kontekście np. serwisu internetowego, ale w
większej skali produktem nie jest program, tylko system, w którym
granice pomiędzy jego technicznymi składnikami (np. sensor vs.
program) są niewidoczne dla klienta. I na tym się agile wyłoży.

> > Albo np. chciałbym, żeby "procesor dźwięku robił pogłos taki jak w
> > znanej sali pewnej filharmonii". Znowu jedno zdanie. Jak do tego
> > zrobić acceptance test?
>
> Bardzo prosto: dajesz OSCR-owi do odsłuchania ileś tam dźwięków
> przetworzonym z takim pogłosem, on ci potwierdza, że to brzmi jak
> odpowiednia filharmonia, piszesz test, który przetwarza dźwięk tym
> efektem i sprawdza, czy wyjście się zgadza.

Złapałeś się. :-) W przypadku pogłosu z filharmonii wyjście za każdym
razem się może nie zgadzać (i na tym polega jego urok) a stwierdzenie,
że coś brzmi tak samo jak coś innego jest subiektywne. Ten problem nie
dotyczy tylko akustyki, jest cała masa takich miejsc. Np. ekspres do
kawy ma robić dobrą kawę. Znowu nie ma jak zrobić acceptance testu.

> Przez "przemysłowe" rozumiesz staerowanie jakimiś maszynami w fabryce
> czy coś takiego?

Tak.

> Nie znam się na tym, ale chętnie dowiem się dlaczego
> tak uważasz.

Właśnie dlatego, że w takich systemach ich działanie opisuje się
całościowo. Agile jest za bardzo intruzywny i za bardzo zakłada, że
klient będzie chciał być zaangażowany (poprzez OSCRów) w definiowanie
tak drobno określonch szczegółów implementacyjnych.

> Jeśli chodzi o "rozrywkowe", to na pewno wiem, że testy automatyczne,
> jak i różne metodologie agile, stosuje się przy tworzeniu gier
> komputerowych - chyba się kwalifikują jako 'rozrywka'?

A tutaj to akurat ja się nie znam. Może profesor fir będzie wiedział.

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