Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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. 

Komentarze

0 nowych
webnull   9 #1 15.09.2011 20:17

Przesadzasz. Piszę wiele desktopowych, konsolowych i webowych aplikacji i najczęściej wystarczy jak je starannie przetestuję sam, ale najczęściej mam kogoś do pomocy ;-)

bolivar   8 #2 15.09.2011 21:15

Taaak, właśnie siedzę nad skryptem na MSSQLu i głowię się jak to przetestować na dziesiątą stronę. Znając życie jak bym podrzucił znajomemu to znalazł by kilka bugów ;-)

Webnull masz pod pewnym względem rację. Jednak przy większych projektach gdzie jest kilku-kilkunastu developerów to już wygląda trochę inaczej. Zresztą sam pewnie wiesz ;-)

Jaahquubel_   12 #3 15.09.2011 23:20

No może to nie tak, że nie można testować własnego kodu. Trzeba testować własny kod, tyle tylko, że to nie wystarczy.
Im wcześniej wyłapie się błąd, tym taniej to wychodzi. Programista zawsze coś w swoim kodzie znajdzie. Miałem do czynienia z programistą, który robił masę literówek i jego dzieła od pewnego momentu często w ogóle nie działały. A wystarczyło uruchomić...
Z drugiej strony jest "paradoks pestycydów" - błędy "uodparniają" się na testera: jak ktoś w kółko tak samo testuje daną rzecz (nie dodaje przypadków), to w końcu dojdzie do tego, że on niczego nie znajdzie, a błędy i tak będą, przelecą jak woda przez sito. Wtedy potrzeba drugiego testera (lub ogarnięcia się przez pierwszego).

bolivar   8 #4 16.09.2011 08:34

@Jaahquubel_: Dlatego piszę: "Po prostu należy mieć fantazje i w nieszablonowy, a zarazem systematyczny (można to połączyć?) sposób myśleć i działać."
Poza tym piszę o testowaniu przez programistę: "Wpiszemy w to pole: "sadfsd sdfdf 12341234" i wystarczy" i tak zazwyczaj wygląda test ze strony programisty. Przy dużych projektach rzadko mają na więcej czas.
"Z drugiej strony jest "paradoks pestycydów" - błędy "uodparniają" się na testera: jak ktoś w kółko tak samo testuje daną rzecz (nie dodaje przypadków), to w końcu dojdzie do tego, że on niczego nie znajdzie, a błędy i tak będą, przelecą jak woda przez sito. Wtedy potrzeba drugiego testera (lub ogarnięcia się przez pierwszego)."
Dlatego co jakiś czas dochodzi do zmiany projektu/części funkcjonalności, którą zajmuje się tester. Zresztą programiści też się nudzą...

Draqun   9 #5 16.09.2011 15:22

Pamiętam jak oddawałem swój projekt z programowania w C. Była to gra konsolowa w postaci Labiryntu z kluczami i drzwiami. Wszystko testowało kilka osób i za każdym razem gra wyglądała inaczej więc uważnie obserwowałem całą akcję aby przypadkiem nie skończyło się tak, że ktoś użył kluczy w innej kolejności i się okazało, że nie mógł ukończyć gry ponieważ zabrakło mu kluczy do otwierania drzwi gdyż otwierał ją z inną kolejnością niż przewidziałem.

Takie obserwacje pozwoliły mi lepiej zrozumieć samą naturę testowania. Nie tylko u każdego gra wyglądała inaczej ale także podejście było inne. Od tamtej pory wszelkie programy, które pisze zanim zostaną oddane w czyjeś ręce przechodzą przez testy kilku osób zarówno takich co znają się na rzeczy jak i takich co mieliby potencjalnie korzystać z takiego programu.

bolivar   8 #6 17.09.2011 10:22

@Draqun: masz jak najbardziej prawidłowe podejście. Można stwierdzić, że po prostu zdrowe. Znam jednak osoby, które na samą myśl, że użytkownik może coś zrobić w innej kolejności oburzają się. Przecież tak nie wolno :D.

  #7 17.09.2011 14:06

Błędy:
"wpisu do przeczytania innej osobie zanim trafi on na DB" => Co to jest DB ?
"litrówki"
UFO albo ufo
"Po prostu należy mieć fantazje" => fantazję
Na temat interpunkcji i poprawności składniowej wpisu wolę się nie wypowiadać.
+++++
Co do meritum
Opisany test można całkowicie/częściowo zautomatyzować => http://en.wikipedia.org/wiki/Fuzz_testing
W PRL niemal wszyscy wyznawali zasadę "Po mnie się nie poprawia". Rozglądam się po świecie i internecie coraz częściej dochodząc do przygnębiającego wniosku, że dziś wyznaję ją jedynie ja :/

Jaahquubel_   12 #8 17.09.2011 18:12

@Bolivar
""Wpiszemy w to pole: "sadfsd sdfdf 12341234" i wystarczy" i tak zazwyczaj wygląda test ze strony programisty. Przy dużych projektach rzadko mają na więcej czas."
Programista sprawdza, czy program ma szanse zadziałać, tester sprawdza, czy program ma szanse nie zadziałać. ;P
Ale to właśnie źle, jak programista nie ma czasu sprawdzić nic więcej - choć to też może zależy od metodyki, aplikacji itd.
Jak deweloper od razu sprawdzi, to od razu poprawi i tester się o tym nawet nie dowie. Jak wykryje to dopiero tester, to po poprawce będzie musiał zrobić ponowną instalację (co bywa przedmiotem intensywnych testów), oraz zrobić testy regresji. Biorąc to do kupy, wychodzi strata.

SnajperskY   4 #9 17.09.2011 20:33

@Jaahquubel_

Widzę, że dalej marnujesz swój cenny czas i konsekwentnie ubijasz masło maślane.

[...]
Ale to właśnie źle, jak programista nie ma czasu sprawdzić nic więcej - choć to też może zależy od metodyki, aplikacji itd.
[...]

Nie, nie zależy. Jedyna rozsądna sytuacja, w której programista to jednocześnie tester występuje w projektach jednoosobowych.

[...]
Jak deweloper od razu sprawdzi, to od razu poprawi i tester się o tym nawet nie dowie.
[...]

W maciupeńkich projekcikach to owszem może się to sprawdzić. Wyobraź sobie większe projekty, niekoniecznie potężne, w których programiści są odpowiedzialni za pojedyncze moduły, bądź fragmenty owych modułów. Nie ma możliwości, aby jeden człowiek ogarniał duży system i był w stanie przewidzieć wpływ swoich zmian na niego. Od tego są dedykowani ludzie zwani...testerami (taaadaaa!).

Jak zrozumiesz, że rola testera różni się znacząco od roli programisty oraz "dwa w jednym" jest wyłącznie wynikiem cięcia kosztów/braku pojęcia, a nie głębszą filozofią - to nastąpi przełom.

[...]
Biorąc to do kupy, wychodzi strata.
[...]

Wychodzi, owszem, po raz kolejny brak doświadczenia.

Jaahquubel_   12 #10 17.09.2011 22:58

@SnajperskY
A ja widzę, że znów próbujesz na siłę, moim kosztem, udowodnić, że jesteś najlepszym znawcą testowania oprogramowania na DP.

Znów też popadasz w skrajności, i znów nie umiesz przeczytać ze zrozumieniem (tak, wiem, za chwilę dowiem się od Ciebie, że piszę mało konkretnie, przez co moje wypowiedzi można różnie interpretować). :)

"Jedyna rozsądna sytuacja, w której programista to jednocześnie tester występuje w projektach jednoosobowych."
Skrajność. Ja nie piszę o tym, że programista ma być testerem, ale że ma zadbać o to co wychodzi spod jego rąk. Gdyby tester miał wszystko robić za dewelopera, do czego byłby potrzebny deweloper?
Zobacz: http://www.dobreprogramy.pl/tfl/Programowanie-ekstremalne,27837.html
Zwłaszcza ostatni akapit drugiego komentarza.

"Wyobraź sobie większe projekty, niekoniecznie potężne, w których programiści są odpowiedzialni za pojedyncze moduły, bądź fragmenty owych modułów. Nie ma możliwości, aby jeden człowiek ogarniał duży system i był w stanie przewidzieć wpływ swoich zmian na niego."
To już konsekwencja wyżej zacytowanego zdania. Oczywiście zgadzam się, że nie ma możliwości, żeby jedna osoba ogarnęła wszystko. Tyle że ja nigdzie o tym nie piszę. Piszę o tym, że sprowadzenie testowania własnego kawałka programu do wpisania "sadfsd sdfdf 12341234" to za mało. Nie potrzeba odpytywać piętnastu modułów autorstwa czterdziestu programistów, aby sprawdzić zachowanie jednego pola tekstowego. Poza tym, są jeszcze zaślepki, sterowniki...

A tak w ogóle, słyszał kolega o modelu V? A o testach białoskrzynkowych?

"Od tego są dedykowani ludzie zwani...testerami (taaadaaa!)."
Eeee tam. Nie możliwe!

"Jak zrozumiesz, że rola testera różni się znacząco od roli programisty oraz "dwa w jednym" jest wyłącznie wynikiem cięcia kosztów/braku pojęcia, a nie głębszą filozofią - to nastąpi przełom."
No Ty patrz, je tego nie rozumiem, a mimo tego jakoś przez ponad dwa lata płacili mi za bycie testerem. Co więcej, nawet kazali mi coś testować.

SnajperskY   4 #11 17.09.2011 23:16

@Jaahquubel_

[...]
A ja widzę, że znów próbujesz na siłę, moim kosztem, udowodnić, że jesteś najlepszym znawcą testowania oprogramowania na DP.
[...]

Wręcz odwrotnie, że Ty masz nikłe pojęcie na ten temat. Zapewne sprowadzające się do maleńkich projektów. Twoje podejście to potwierdza.

[...]
Znów też popadasz w skrajności, i znów nie umiesz przeczytać ze zrozumieniem (tak, wiem, za chwilę dowiem się od Ciebie, że piszę mało konkretnie, przez co moje wypowiedzi można różnie interpretować).
[...]

Szczerze to dalej odechciało mi się czytać :) Za wysokie progi.

bolivar   8 #12 18.09.2011 14:18

@BigZonk (niezalogowany):
"W PRL niemal wszyscy wyznawali zasadę "Po mnie się nie poprawia". Rozglądam się po świecie i internecie coraz częściej dochodząc do przygnębiającego wniosku, że dziś wyznaję ją jedynie ja :/"
Chyba coś ci się pomyliło... w PRLu to dopiero było poprawiania. No chyba, że ja w innym PRLu dorastałem...
Inna sprawa, że zasada dobra, ale nie widzę szans na jej wprowadzenie przy terminach i naciskach z góry.

@Jaahquubel_:
"Ale to właśnie źle, jak programista nie ma czasu sprawdzić nic więcej - choć to też może zależy od metodyki, aplikacji itd.
Jak deweloper od razu sprawdzi, to od razu poprawi i tester się o tym nawet nie dowie. Jak wykryje to dopiero tester, to po poprawce będzie musiał zrobić ponowną instalację (co bywa przedmiotem intensywnych testów), oraz zrobić testy regresji. Biorąc to do kupy, wychodzi strata."
W świecie idealnym tak jest. Niestety przy projektach bywa różnie.

Jaahquubel_ i SnajperskY:
naprawdę ciekawie musiało by się z wami pracować... w sumie nie wiem czy po tygodniu nie chciałbym zmienić projektu...

SnajperskY   4 #13 18.09.2011 18:44

@bolivar

[...]
naprawdę ciekawie musiało by się z wami pracować
[...]

Nie wyobrażaj sobie nas (z Jaahquubel_ ) razem z prozaicznego powodu. Raz jednoosobowe, akademickie projekty mam dawno za sobą, a dwa w jednoosobowych projektach nie ma miejsca dla dwojga :)

[...]
w sumie nie wiem czy po tygodniu nie chciałbym zmienić projektu...
[...]

W sumie to Twoja ocena opiera się na paru suchych wpisach, oraz najprawdopodobniej nie przypadła Ci do gustu sama wymiana zdań. Twoje kryteria wyboru współpracowników są bardzo profesjonalne (sarkazm).

bolivar   8 #14 18.09.2011 19:01

@SnajperskY:"W sumie to Twoja ocena opiera się na paru suchych wpisach, oraz najprawdopodobniej nie przypadła Ci do gustu sama wymiana zdań. Twoje kryteria wyboru współpracowników są bardzo profesjonalne (sarkazm)."
Równie w czasie rozmowie kwalifikacyjnej, po kilku minutach, możesz wiedzieć czy chcesz z kimś pracować czy nie.

Przykro mi, ale ja wolę ludzi którzy potrafią dojść do porozumienia, a nie eskalują konflikt.

SnajperskY   4 #15 18.09.2011 19:39

Jeżeli w czasie rozmowy kwalifikacyjnej jesteś w stanie ocenić, czy ktoś zamiast rozwiązywać konflikty jedynie je eskaluje to gratuluję nosa :)

[...]
Równie w czasie rozmowie kwalifikacyjnej, po kilku minutach, możesz wiedzieć czy chcesz z kimś pracować czy nie.
[...]

Żartujesz? Nie zatrudnisz fachowca, z którym nie "klei" Ci się kilkuminutowa rozmowa? Poza skrajnymi przypadkami, gdzie pacjent pojawia się z nożem, bądź pluje Ci w twarz ciężko stworzyć wystarczający profil psychologiczny bez wykwalifikowanego psychologa.

Innymi słowy, z każdym w zespole/projekcie utrzymujesz świetne kontakty? Jeżeli tak to ponownie gratuluję specyficznego, unikalnego środowiska :)

SnajperskY   4 #16 18.09.2011 19:45

Aha, poza tym masz bardzo nisko zawieszoną poprzeczkę z napisem "konflikt"... Każda różnica zdań to dla Ciebie już dramat?

bolivar   8 #17 18.09.2011 20:05

@SnajperskY:"Aha, poza tym masz bardzo nisko zawieszoną poprzeczkę z napisem "konflikt"... Każda różnica zdań to dla Ciebie już dramat?"
Tylko, że ona już trwa drugi wpis na temat testowania ;-) Mnie osobiście znudziła... i nie przepadam za osobistymi wycieczkami.

"Żartujesz? Nie zatrudnisz fachowca, z którym nie "klei" Ci się kilkuminutowa rozmowa? Poza skrajnymi przypadkami, gdzie pacjent pojawia się z nożem, bądź pluje Ci w twarz ciężko stworzyć wystarczający profil psychologiczny bez wykwalifikowanego psychologa.

Innymi słowy, z każdym w zespole/projekcie utrzymujesz świetne kontakty? Jeżeli tak to ponownie gratuluję specyficznego, unikalnego środowiska :)"
Czasem człowieka szukasz przez kilka miesięcy. Nie tylko ze względu na wiedzę, ale właśnie na miękkie umiejętności, które powodują, że zespół jest zespołem i razem dobrze (lub nawet bardzo dobrze) współpracuję.
Jeżeli chodzi o "unikalne środowisko" - może mam szczęście? Może też dopieram w odpowiedni sposób firmę i nie tylko na rozmowie kwalifikacyjnej odpowiadam na pytania, ale obserwuję i sam je zadaję. Wystarczy mi raz gdy trafiłem do "toksycznej firmy".

Jeżeli chodzi o kilka minut rozmowy - zazwyczaj trwa dłużej (po ty by mieć pewność), ale jak na razie zdarzył się jeden przypadek, który miło zaskoczył (gość nie wiedział na jakie stanowisko aplikuje - dostał pracę :D)

Dziękuję za twoje wypowiedzi - zawsze ciekawa jest ta druga strona medalu ;-)

SnajperskY   4 #18 19.09.2011 10:01

@bolivar

Jeżeli masz ochotę to polecam mój jedyny wpis na blogu. Zobaczysz moje podejście do konfliktów i zabobonów.

Sytuacja zmienia się, gdy ktoś mimo delikatnych sugestii, nadal brnie w obranym kierunku plus dorzuca do pieca, bo czuje się taki "mocny". Lubię ludzi zdystansowanych i gotowych na krytykę. Taki jestem i również takimi ludźmi się otaczam.

Zauważ, że schemat: rzucanie pokrętnych teorii, ogólników, bez podania faktów, by później przeinaczać własne słowa rzucając przy tym na odchodne "czytaj ze zrozumieniem" pasuje do profilu, ale gimnazjalisty. Profil kolegi @Jaahquubel_ zbudowany, dalszej polemiki nie będzie :)

Mężczyzna sypiający z jedną, jedyną kobietą od 30 lat nie jest dla mnie ekspertem w tych sprawach jeżeli rozumiesz analogię ;)

Aby dalej nie eskalować konfliktu czekam na kolejny wpis ;P

BTW. Moje zagrywki potraktuj również jako element budowania czyjegoś profilu. Środek komunikacji mizerny, ale wystarczający w tym przypadku :)