On Dec 17, 7:12 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On 17/12/2011 17:00, Roman W wrote:
>
> > On Dec 17, 3:58 pm, Andrzej Jarzabek<a...@g...com>
> > wrote:
>
> >>> co jest bugiem, a co nie. Jak programista Agile ma eliminowac bugi,
> >>> kiedy nie wie, co jest prawidlowym zachowaniem budowanego systemu? "On-
> [...]
> >> Tak, generalnie polega to na tym, że programista rozmawia z OSCR tak
> >> długo, żeby zrozumieć co program ma robić, a jeśli nie jest w stanie
> >> zrozumieć czy ewentualne zachowanie jest prawidłowe, czy nie, to
> >> rozmawia z OSCR jeszcze trochę.
>
> > A co jest rezultatem tej rozmowy? Notatki pisane olowkiem na serwetce,
> > watem mailowy w firmowym Outlooku, czy cos bardziej
> > ustrukturyzowanego?
>
> Przede wszystkim rezultatem tej rozmowy jest to, że programista wie, co
> jest prawidłowym zachowaniem budowanego systemu.

Systemu jako calosci? Czyli jednak dokumentacja.

> Jeśli chodzi o
> artefakty, to może to być "user story" (czy inny "change control ticket)
> - jeśli objaśnienie się kwalifikuje, będzie to prawdopodobnie jeden lub
> kilka testów (acceptance test, unit tests),

Ale to opisuje wycinek systemu.

> no i przede wszystkim będzie
> to działający kod, który robi właśnie to, co trzeba.

Nie, bedzie to kod przechodzacy kilka testow. To nie to samo.

>
> >> Na podstawie takiej rozmowy programista razem z OSCR tworzą acceptance
> >> test, który weryfikuje istotne askpekty funkcjonalności.
>
> > Czy uwazasz, ze 100% funkcjonalnosci mozna udokumentowac w formie
> > testu?
>
> Nawet jeśli można udokumentować 99%, to praktycznie różnica jest niewielka.

Czyli uwazasz, ze osiagalne jest "99%" (czyli prawie kompletny opis)?
Tak/nie.

>
> > Zalozmy, ze projekt zawiera biblioteke numeryczna. Czy wystarczy
> > "acceptance test", czy nie nalezy rowniez udokumentowac algorytmow,
> > ktore biblioteka ma implementowac?
>
> Nie wiem konkretnie jak jest z bibliotekami numerycznymi.

Jest tak, ze nie wystarczy wiedziec, ze biblioteka przechodzi X
testow, zeby ocenic, czy design jest poprawny czy nie. Testy moga
sprawdzic skonczona liczbe przypadkow, ale wymagania stawiane
bibliotekom numerycznym jest ciezko zawrzec calkowicie w formie
testow.
Np. wymaganie moze brzmiec "procedura X ma implementowac algorytm
calkujacy Grubiediewa". Jak to sprawdzisz unit testem?

> Jeśli chodzi o
> to, że wykorzystujesz jakieś algorytmy z literatury i chcesz
> udokumentować fakt, że stosujesz algorytm Kamionnego-Łomonosowa z
> artykułu "Zastosowanie metod numerycznych przy wykopywaniu ziemniaków"
> publikowanego w miesięczniku Kołchoźnik nr 8/51? No to może faktycznie
> należy dać przypis w komentarzu.

A jesli algorytm nie zostal nigdzie opublikowany?

>
> >> Jeśli
> >> programista zmieni program tak, że przestaje przechodzić testy, które
> >> wcześniej przechodził, to może skonsultować się z OSCR w kwestii
> >> ustalenia, czy testy są błędne i należy je zmodyfikować.
>
> > A jezeli zmieni dzialanie programu w aspekcie nie objetym testami?
>
> To dobrze, że przynajmniej zdaje sobie sprawę, że zmieni.

Skad ma zdawac sobie sprawe? Przeciez nie ma dokumentacji, moze uznac,
ze zmiana w kodzie nie zmieni istotnych aspektow dzialania programu,
bo... unit testy przechodza.

> W takiej
> sytuacji, skoro aspekt nie jest objęty testami, to prawdopowodnie należy
> go objąć testami. No chyba że OSCR powie, że ten aspekt jest nieistotny,
> to wtedy nie ma problemu.

Ale skad programista ma *wiedziec*, ze zmiana ktora chce wprowadzic w
kodzie jest istotna i powinna byc skonsultowana z OSCR, skoro nie ma
dokumentacji? Ma trzymac OSCR non-stop przy sobie? A jesli nad
projektem pracuje wiecej niz 1 programista, to ile osob ze strony
klienta ma je nadzorowac?

RW