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. 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), no i przede wszystkim będzie
to działający kod, który robi właśnie to, co trzeba.

>> 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.

> 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. 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.

>> 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. 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.