W dniu 2012-08-12 21:22, Roman W pisze:
> On Friday, August 10, 2012 9:07:18 AM UTC+1, Paweł Kierski wrote:
>> W dniu 2012-08-10 09:42, Roman W pisze:
>>
>>> On Friday, August 10, 2012 8:32:36 AM UTC+1, Paweł Kierski wrote:
>>
>>>> W dniu 2012-08-09 19:34, Andrzej Jarzabek pisze:
>>
>>>>
>>
>>>>> On 09/08/2012 12:23, Roman W wrote:
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>> Procesem nie podniesie sie umiejetnosci deweloperow, ale moze da sie
>>
>>>>
>>
>>>>>> uniknac tego:
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>> http://www.nanex.net/aqck2/3525.html
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>> "We believe Knight accidentally released the test software they used
>>
>>>>
>>
>>>>>> to verify that their new market making software functioned properly,
>>
>>>>
>>
>>>>>> into NYSE's live system."
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Teoretycznie tak, ale równie dużą masz szansę na to, że sama procedura
>>
>>>>
>>
>>>>> "urzędowego testowania" spowoduje w pewnym momencie błąd polegający na
>>
>>>>
>>
>>>>> wpuszczeniu testowych programów lub danych do produkcji.
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>> Jeszcze jeden możliwy scenariusz - "urzędowe testowanie" zmniejszy
>>
>>>>
>>
>>>> ciśnienie na testowanie własne. Skoro celem będzie nie bezbłędne
>>
>>>>
>>
>>>> oprogramowanie, a oprogramowanie zgodne z urzędowymi testami, to takie
>>
>>>>
>>
>>>> będzie produkowane.
>>
>>>
>>
>>> Bezbledne oprogramowanie nigdy nie bylo celem, wiec ten scenariusz mozemy
spokojnie wykluczyc.
>>
>>
>>
>> Nie o to mi chodziło. Jeśli tworzę oprogramowanie, to staram się je
>>
>> testować w tych kierunkach, w których spodziewam się problemów. Jeśli
>>
>> dokładam nowy ficzer, to mniej więcej wiem, co się może stać, jakie nowe
>>
>> przypadki wygeneruje. I na tym się skupiam.
>
> No i tu jest pierwsze bledne zalozenie. Doswiadczenie pokazalo, ze ludzie budujacy
systemy do handlu na gieldzie czesto nie przewidywali, albo lekcewazyli mozliwosc
zajscia problemow ktore maja niskie prawdopodobienstwo zajscia, ale jak juz zajda, to
sa drastyczne w skutkach. Niekoniecznie dlatego ze sa glupi, ale dlatego, ze korzysci
krotkoterminowe przeslaniaja im dlugoterminowe zagrozenia.
>
> Inaczej mowiac: postaw sobie kolesia, ktory pisze taki system dla firmy Knight.
Jezeli system zadziala, koles dostanie duzego tlustego bonusa. Jezeli system nie
zadziala, kara nie bedzie symetryczna do nagrody -- worst case, koles straci prace i
bedzie mial "ciekawa historie" do opowiedzenia. Nawet jezeli straty beda siegaly w
setki milionow dolarow. Zewnetrzne regulacje musza poprawic asymetrie motywacji.

Jest tu jedno milczące założenie - testy "urzędowe" są dobre, a może
i lepsze w pewnych zakresach od "zwykłych". Owszem, mogą być czasem,
ale umówmy się - gdyby kolesie piszący testy dla "urzędu" byli naprawdę
tak dobrzy, to raczej by w tym "urzędzie" nie pracowali. W Polsce to
w tej chwili pewnik, może A.L. wypowie się USA, ale podejrzewam, że też
to w taką stronę idzie.

>> Jeśli mam narzucone z góry
>>
>> testy "urzędowe", to spełnieniem tych testów głównie się zajmę. Jeśli
>>
>> zabraknie mi czasu (a zawsze brakuje), to wiadomo, z czego będę
>>
>> rezygnował.
>
> Jezeli korzysci z systemu nie sa dostatecznie duze, zeby Ciebie zmotywowac do
wlozenia dodatkowego wysilku w zrobienie i testow, i funkcjonalnosci, to widac nowa
funkcjonalnosc nie byla warta ryzyka.
>
> Ja bm sie bal czego innego, ze testy "urzedowe" zastapia wewnetrzne, zamiast je
uzupelniac. "Jestemy kryci, spelniamy wymagania Basel III" -- LOL :)

Innymi słowy, ale właśnie to miałem na myśli. Stopniowo "urzędowe"
będzie zastępować zdrowy rozsądek. Stopień pokrycia testami w sumie
raczej spadnie niż wzrośnie.

--
Paweł Kierski
n...@p...net