On Jan 21, 9:48 am, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:
> Andrzej Jarzabek pisze:
>
> > oprogramowaniu przy testowaniu laboratoryjnym są znacznie mniejsze niż
> > przy podobnym nakładzie środków przy testowaniu przez QA. Bo dział QA
> > testuje tylko produkty tej firmy, być może jest zespół, który testuje
> > tylko dany produkt, dodatkowo mają wskazówki od developerów gdzie
> > należy szukać błędów i mają możliwość testowania produktu we
> > wszystkich stadiach produkcji.
>
> Widzisz, w jednej z firm, w której pracowałem, ktoś powtarzał, że "autor
> programu jest najgorszym z mozliwych testerów własnego wyrobu". I wiesz
> co, po latach doswiadczeń przyznaję mu rację.

W sensie, że lepszym testerem będzie sprzątaczka?

[...]
> sprawdzi dokładnie). Niestety w życiu codziennym pojawiają się sytuacje,
> których autor programu nie przewidzi (np jakies nawyki osób
> obsługujacych program). Dlatego w firmie w której pracowałem były osoby
> w dziale testów, które zajmowały się testowaniem produktów w taki
> sposób, jaki robia to urzytkownicy, poniewaz było to oprogramowanie

No dobra, co według Ciebie oznacza użyty przeze mnie powyżej skrót
"QA"?
Oczywistą sprawą jest, że dział testów wykonuje testy takie, jak
opisałeś, a nir tylko realizuje instrukcje programisty.

Ale też instrukcje programisty przyczyniają się do wykrywania wielu
błędów, które prowadząc takie testy nie zostałyby wykryte, bo masz np.
sytuację, gdzie został przetestowany build nr 1234, po czym
programista wprowadza pewne drobne zmiany i do testowania idzie build
nr 1235. Jeśli programista wie, na czym polega zmiana i co ewentualnie
może zepsuć, to może napisać notkę wyszczególnuiającą, jakie części
czy funkcje należy w tym momencie szczególnie intensywnie testować i
jakiego rodzaju kombinacje mają szczególnie duże szanse ujawnienia
bugów. To są bardzo cenne wskazówki, których laboratorium testujące
gotowy produkt nigdy nie otrzyma.

> > Jeśli chodzi o błędy polegające na tym, że w bardzo specyficznych
> > sytuacjach, przy specyficznej konfiguracji, przy specyficznych danych
> > wejściowych pojawiających się w specyficznych relacjach czasowych
> > program się wysypuje, to testy laboratoryjne mają bardzo słabe szanse
> > na ich wyłapanie, bo są w stanie przebadać jedynie bardzo wąskie
> > wycinki całkowitej przestrzeni zdarzeń.
>
> Ale takich błędów też nie wyłapią programiści.

Po pierwsze programiści posiadający odpowiednie umiejętności i wiedzę
popełnią takich błędów znacznie mniej dzięki stosowaniu odpowiednich
praktyk.

Po drugie oczywiście, że doświadczony progrramista może wyłapać lub
zmniejszyć szansę takich rzeczy w cudzym kodzie przez code review. Nie
mówimy już tu nawet o zauważeniu, że np. wątki programu używają
dzielonej zmiennej bez lockowania, ale przede wszystkim o tępieniu
złych praktyk, takich jak pisanie nieczytelnego kodu. Bo nie chodzi o
to, czy ten certyfikowany programista będzie w stanie sprawdzić, czy
spaghetti code ma błędy funkcjoalne, tylko że będzie wiedział, że to
jest źle napisany kod, w którym w związku z tym istnieje większa
szansa na błędy, mniejsza szansa na znalezienie błędów i większa
szansa na wprowadzenie błędów w przyszłości: więc nie certyfikuje
takiego kodu niezależnie od tego, czy fanktycznie posiada on błędy
funkcjonalne, czy nie.