On Dec 18, 11:31 pm, Maciej Sobczak <s...@g...com> wrote:
> On Dec 18, 6:05 pm, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > > Dlatego dokumentację można np. powielić i dać do audytu. Nawet
> > > równoległego, przez wielu obserwatorów. OSCR takich ficzerów nie ma.
>
> > 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.

> 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. Zaskakująco, jeśli w twoim
procesie na punkt "istotna właściwość systemu" masz reakcję nie
"trzeba to udokumentować" tylko "trzeba napisać

> Zwłaszcza w sytemach, które opisuje się
> pod kątem ich całościowego działania a nie pod kątem działania
> pojedynczego programu - tak jest np. w systemach przemysłowych. Np.
> "system ma liczyć przejeżdżające samochody". Jedno takie zdanie w
> dokumentacji załatwia temat, którego implementacja obejmuje wiele
> różnych aspektów, łącznie z hardwarem. Wykonawca z doświadczeniem wie,
> jak to zrealizować.
> Jak do tego zrobić acceptance test?

Nie jestem wykonawcą z doświadczeniem, to po pierwsze, po drugie nie
da się odpowiedzieć na takie pytanie bez kontekstu. 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.
Oczywiście od różnych czynników będzie zależało, czy tych test case'ów
będzie kilka (0 samochodów, 1 samochód, 2 samochody, 5 samochodów, 137
samochodów), czy np. będą to dziesiątki tysięcy filmów zebranych z
kamer drogowych w całym kraju, z brzegowymi przypadkami typu kawalkada
5 motocykli albo furmanka. W każdym razie sam fakt, że system ma
liczyć przejeżdżające samochody, który w dokumentacji jest wyrażony
samym tylko zdanie "system ma liczyć przejeżdżające samochody", w
suicie acceptance tests jest wyrażony samym tylko istnieniem testu czy
grupy testów o nazwie "liczPrzejeżdzająceSamochody".

> 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. Nazywasz test
"testujPogłosZeZnanejSaliWFilharmoniiWKoluszkach". W momencie kiedy
test ci failnie, zanosisz wyprodukowane nową wersją programu sample do
OSCR-a i pytasz go, czy nadal brzmią jak znana sala w Koluszkach.

> > Testów, które powstały na podstawie rozmowy z OSCR-em i zostały przez
> > tego OSCR-a zatwierdzone.
>
> Tak to można okienka dialogowe w programie księgowym robić. Systemów
> przemysłowych ani nawet rozrywkowych w ten sposób nie widzę.

Przez "przemysłowe" rozumiesz staerowanie jakimiś maszynami w fabryce
czy coś takiego? Nie znam się na tym, ale chętnie dowiem się dlaczego
tak uważasz.

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'? Jeśli chodzi o
jakieś rzeczy typu oprogramowanie do wieży hifi, to znowu - nie mam
zdania, ale chętnie usłyszę dlaczego to miałoby nie działać.