Administrator? Programista? A może Tester? Część 2

Dlaczego programista nie powinien testować swojego kodu? Można to opisać w najprostszy sposób: tak samo jak ja, daję tekst tego wpisu do przeczytania innej osobie zanim trafi on na DB. [W tym momencie rozpoczynam ryzykowną grę ponieważ zaraz kilka osób udowodni mi, że  i tak są jakieś błędy ;)] Mogę nie zauważyć jakiejś litrówki, powtórzenia, itp. W końcu ja piszę ten tekst i ja jestem jego twórcą. Mogę być trochę zmęczony - bo wczoraj był mecz/czytałem książkę/wróciłem z imprezy/porwało mnie Ufo - i mogę przegapić pewne rzeczy. Dodatkowo nie czytam dokładnie ponieważ zakładam, że jest to prawidłowe. Podobnie programista tworząc swój kod działa na pewności i odruchach. Wie, że to działało wcześniej to dlaczego ma nie działać teraz. No właśnie? Dlaczego ma nie działać? Po pierwsze w trakcie pracy nad kodem mogły zmienić się wymagania. Np. formularz, który ma być wypełniony przez użytkownika w pierwszym projekcie miał mieć maksymalnie 2000 znaków. Po kolejnych konsultacjach został ustalony na 8000 znaków... ale na sam koniec ktoś zdecydował, że będzie to jednak wielkość 50000 znaków. Czy to problem... no czasem może być to problem. W MSSQLu na początek ktoś użył zmienną varchar (2000), później zmienił na varchara (8000) lub po prostu varchar (max)... a co dalej?

Tutaj właśnie zaczyna się zabawa. Mam kilka możliwości gdzie mogą być błędy. Te najpopularniejsze to: - pole w bazie nie zostało zmienione - wprowadzenie tekstu nie zostało zmienione - zapis do bazy nie został zmieniony - odczyt z bazy nie został zmieniony - ... i kilkanaście innych miejsc ;‑) Teraz jeżeli programista testuje swój kod to może nie mieć świadomości, że ktoś dokonał zmian w wymaganiach, mógł też nie poprawić za którymś razem fragmentu kodu odpowiedzialnego za daną funkcjonalność... lub po prostu zapomniał. Dochodzi też coś takiego, co ja tak nazywam subiektywnym podejściem do swojego dziecka - nie działamy destruktywnie . Wpiszemy w to pole: "sadfsd sdfdf 12341234" i wystarczy. Tester zaloguje się na Wikipedię i skopiuje artykuł o Javie i go tam wklei. Dodatkowo skorzysta z Google Translate i wrzuci kilka linijek w różnych językach by sprawdzić jak zachowa się kodowanie. Oczywiście przydaje się przy tym wiedza z zakresu programowania, baz danych, administracji i trollowania po forach ;‑) To ostatnie to żart... ale nie do końca. Po prostu należy mieć fantazje i w nieszablonowy, a zarazem systematyczny (można to połączyć?) sposób myśleć i działać. Dlaczego systematyczny? Test musi być powtarzalny i udokumentowany. Dlaczego nieszablonowy? Nie można za każdym razem, iść utartą ścieżką, ale sprawdzić różne drogi dojścia do celu.

Na koniec jeszcze jedna brutalna sprawa - Tester (zazwyczaj) jest po prostu tańszy od programisty i lepiej by on przez kilka godzin sprawdzał daną funkcjonalność, a w tym czasie programista tworzył kolejną.

Następnym razem: wymagania - temat rzeka. Kto jak i dlaczego nawet gdy wydają się bezsensowne to należy ich się trzymać i jak je komentować.

[add 14:19 18‑09-2011] Podaje proste przykłady - proszę brać pod uwagę, że DB czytane są zarówno przez osoby zaczynające przygodę z IT jak i mające już kilka lat na karku. Proszę to brać pod uwagę, że nie każdy z nas/was posiada kilkunastoletnie doświadczenie w projektach. Niektórzy myślą dopiero o przyszłości i dla nich głównie są te wpisy.