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

A.L.