> > Czyli biznes typu "wicie rozumicie". Jedna wielka szara strefa.
>
> Nie rozumiem o co ci chodzi.

O świadomość. Tzn. o świadomość ograniczeń metod, którymi się posługujemy.
Ta świadomość zanika np. wtedy, gdy optymistycznie uznajemy, że coś przetestowaliśmy,
chociaż w rzeczywistości nie mamy nawet miary, która by ustaliła, w jakim stopniu to
zrobiliśmy i ostatecznie wiemy tylko jaki wysiłek w to włożylismy (np. ile godzin
poszło na testy) a nie ile przez to uzyskaliśmy.
Szukam metody, która byłaby bardziej obiektywna, niż "akceptowalność przez
konsensus".

> Przecież mierzymy - to właśnie testy są pomiarami.

Nie, chodzi mi o pomiar skuteczności testów. Tak naprawdę nie wiemy, w jakim stopniu
są skuteczne a przez to nie wiemy, kiedy przestać.

Spróbujmy tak: chcę, żeby system miał co najwyżej 1 buga na 10k linii kodu. Ile
dolarów mam wydać na pisanie testów? Ciemność.

To jest inny poziom myślenia, niż "akceptowalna jakość za akceptowalną cenę".

> No to policz taki wariant:
>
> Jeśli zrobisz tak, jak opisałem, to dostaniesz normalną pensję, której
> co nikt nie zabierze. Jeśli program zarobi pieniądze, dostaniesz jakąś
> premię, ale bez szału. Jeśli bugi spowodują, że program straci dużo
> kasy, nie dostaniesz premii, a może nawet wylecisz z pracy.

Podoba mi się słowo "może". Ale zgadza się.

> Jeśli wprowadzisz użyjesz metod formalnych i się nie powiedzie,

Co się nie powiedzie? Że program będzie poprawny ale jednak nie będzie?

> No i co? Jak sprzęt medyczny czy samochód kogoś zabije, to programista,
> etatowy pracownik producenta idzie siedzieć?

Dobre pytanie. Problem z odpowiedzią jest taki, że w tych branżach takich wypadków
jest zdumiewajaco mało, więc trudno mówić o powszechnie panujących regułach
postępowania. Sam napisałeś, że fakapy na kilka milionów w systemach finansowych nie
są niczym niezwykłym - rozumiem, że jest ich na tyle dużo, że istnieje jakiś
konsensus nt. tego, co należy wtedy zrobić. No i wychodzi na to, że niewiele się robi
("może nawet wylecisz z pracy" - z akcentem na "może"). Natomiast w branżach
krytycznych fakapów jest bardzo mało. Było kilka spektakularnych, ale powiedzmy, że
potrafimy znaleźć jeden przykład medyczny, jeden rakietowy, jeden yyy no nie wiem
jaki i właśnie z małej liczby takich przykładów wynika brak konsensusu, co dalej.
A teraz pytanie, z czego wynika mała liczba fakapów w takich branżach.

> Nie wyobrażam sobie zresztą, jak firma ubezpieczniowa miałaby szacować
> ryzyko dla takiego programu

No patrz, a w branżach krytycznych szacują.

I właśnie o tym piszę.

> > Widziałem też przypadek, kiedy skończyły się pieniądze na testy.
>
> No właśnie o to chodzi, że jeśli po zrobieniu np. 75% testów, które się
> zakładało zrobić, skończą się pieniądze, to te 75% testów nadal coś daje.

Ile daje? Tego właśnie nie wiemy. A czy lepiej by było zrobić wtedy inne testy, tzn.
inne 75%? Też nie wiemy. I nawet nie wiemy, co byśmy zyskali, gdybyśmy zrobili 100%
*założonych*. Intuicyjnie dałoby nam "coś" więcej, ale to jest taka sama intuicja,
jak to, że jak dam żebrakowi więcej, to spotka mnie większe szczęście.
Wiemy, ile nas to kosztowało ale nie wiemy, ile zyskaliśmy. Bo nie mamy jak zmierzyć.
I to jest ta szara strefa, która nie bardzo pasuje do inżynierskiego charakteru
naszej profesji. O tym właśnie piszę.

--
Maciej Sobczak