Dnia Mon, 13 Aug 2012 10:53:55 -0500, A.L. napisal:

> On Mon, 13 Aug 2012 08:22:11 +0200, Paweł Kierski <n...@p...net>
> wrote:
>
>>W dniu 2012-08-10 14:39, A.L. pisze:
>>> On Fri, 10 Aug 2012 09:32:36 +0200, Paweł Kierski<n...@p...net>
>>> 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
>>>
>>> Nie ma bezblednego oprogramowania ani metod pozwalajacych stwierdzic
>>> ze oprogramowanie jest bezbledne (pomijajakc oczywiscie PROSTE
>>> programy 5 linijkowe)
>>
>>No i pytanie - w czym "urzędowe" testy będą lepsze? Czy zwiększą
>>pokrycie - zmniejszą liczbę błędów? Z chęcią zobaczyłbym argument
>>inny niż "bo będzie ich w sumie więcej", albo "urząd/państwo lepiej
>>się zna".
>
> Nie wiem co to sa "uzredowe testy". Klient okresla co system ma robic,
> w jakim czasie, itede, daje problemy do testowania i tak dalej.
> Kryteria odbioru sa sformulowane tak mniej wiecej: ma rozwiazac
> problem ze 100 jednostkami w czasie godziny a z 500 jednostkami w
> czasie nie dluzszym niz 2 godziny". To sa testy dotyczace globalnej
> funkcjonalnosci a nie tego czy nacisniecie guzika daje prawidlowy
> efekt.
>
> W nromalnej firmie robiacej systemy "w rodzaju" mission critical - "w
> rodzaju" - to znaczy moga spowodowac strate duzych pieneidzy ale
> nikogo nei zabija, testowanie i QA pochlania 75% zasobow i kosztow
> produkcji. I przeprowadzane jest przez duza i dosyc skomplikwoana
> organizacyjnie grupe wedle dosyc sformalizowanych i drakonsko
> przestzreganych procedur. Te testy nei wkluczaja "unit testing" ktore
> sa odpowiedzalnoscia programisty (ale to ktore unit tests tez sa
> kontrlowoane pzrez owa grupe, w szczegolnosci zapuszczane co noc).

To nie wyklucza czegoś w rodzaju "acceptance tests", zrobione dla
urzędu przez jakąś firmę. Mogą symulować wszelkie skrajne i nieskrajne
sytuacje na rynku, taki NYSE Compatibility Toolkit ;-) - jak nie
przechodzi to nie ma wstępu na rynek.

Z technicznego punktu widzenia, sens praktyczny zupełnie pomijam.

Edek