On 29/03/2015 00:13, Maciej Sobczak wrote:
>
>> 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ć.

W indywidualnym przypadkui nie wiemy, ale w skali dużej firmy jak
najbardziej można zbierać dane między wysiłkiem włożonym w testowanie s
stratami z fakapów.

Z tym że mnie np. nie przekonuje to, czy wiedza z takich danych jest
loepsza niż intuicja doświadczonego inżyniera oprogramowania.

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

To jest bezużyteczny poziom myślenia, sensowne kryterium to np. jakie
jest prawdopodobieństwo, że program w ciągu roku straci więcej niż 3
miliony, więcej niż 2 miliony, że w ogóle straci, że zyska więcej niż
milion, więcej niż dwa miliony itd. - i w ten rachunek wlicza się straty
spowodowane przez bugi. I takie rzeczy się jak najbardziej szacuje.

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

Na ile rozumiem, to jest dokładnie tak samo, jak w "branżach
krytycznych" - jeśli bug w oprogramowaniu kogoś zabije, to programista
na etacie może straci pracę a może nie, ale procesu karnego ani
cywilnego raczej nie musi się obawiać.

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

Oczywiście, że formalna zgodność programu z kryteriami zapisanymi w
języku formalnym nie oznacza, że program będzie rzeczywiście dobrze
realizował cel, do którego został stworzony.

Ale mnie ogólnie chodzi o to, że nawet w przypadku redukcji ryzyka
fakapu korzyść z tego będzie mniejsza niż całkowity koszt zastosowania
metod formalnych.

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

Jest wystarczająco dużo żeby wiedzieć, czy to się w ogóle zdarza. Na ile
rozumiem, w wielu rozwiniętych krajach konstrukcja prawa jest taka, że
praktycznie jest to niemożliwe.

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

Nic mi o takim konsensusie nie wiadomo (z wyjątkiem ogólnego "zbadać
przyczyny i zastanowić się czy i jak można temu zapobiegać w przyszłości")

> 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

Pamiętam, że nie tak dawno temu była afera z hamulcami w samochodach.

> właśnie z małej liczby takich przykładów wynika brak konsensusu, co
> dalej.

I - niech zgadnę - wychodzi na to, że niewiele się robi - jeśli chodzi o
osobiste konsekwencje dla programisty - może nawet stracić pracę?

> A teraz pytanie, z czego wynika mała liczba fakapów w takich
> branżach.

Z różnych rzeczy może wynikać, choćby z tego, że system sterowania
hamulcem w samochodzie zapewne jest ileś tam rzędów wielkości mniej
skomplikowany od systemu do odtwarzania muzyki czy nawigacji
satelitarnej w tym samym samochodzie. Albo np. że nie jest tak, że
drogowcy co dwa miesiące wymieniają nawierzchnię na taką, na której
stare oprogramowanie źle działa. Albo że program do startu rakiety który
jest dobry dzisiaj, za dwa tygodnie będzie do wyrzucenia z powodu
niemożliwych do przewidzenia zmian w składzie atmosfery, właściwościach
chemicznych ciekłego tlenu i stałej grawitacyjnej.

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

Firmy ubezpieczeniowe?

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

Nie wiemy w sensie że ja nie wiem i ty nie wiesz, to nie znaczy, że w
ogóle nie wiadomo.

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

No nie wiem, mówisz, że w inżynierii lądowej wiedzą dokładnie o ile
wzrośnie prawdopodobieństwo zawalenia mostu jeśli będą prowadzić 15%
mniej dokumentacji albo stosować 10% mniej norm?