fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
< 1 minut

Słowo na niedzielę, o testerach i programistach


10.07.2016

U mnie działa” – to słowa prawie sakramentalne w naszym zawodzie. I co wtedy robić? Krzyczeć, gniewać się? Bić?

Normalna sprawa – twórca rozwiązania siłą rzeczy wie jak klikać, aby wszystko banglało. Ba, mało tego! Nawet jeżeli programista dostanie cudzy program, to nie będzie z niego korzystał jak “normalny” użytkownik.

Macie tak? Ja mam. Na pewno nie jestem “zwykłym userem”, czegokolwiek nie używam.

Dlatego też:

The absolute worst testers you can possibly have are developers.
Jeff Attwood

0 0 votes
Article Rating
18 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Michal Franc
7 years ago

Trend jest taki ze nie bedzie juz podzalu na tester / programista. Bedzie programista specjalizujacy sie w tym i programista specjalizujacy sie w utrzymywaniu jakosci produktow.

“U mnie dziala” – to oznaka braku doswiadczenia i profesjonalizmu

widelec
7 years ago
Reply to  Michal Franc

Nie,odpowiedź u mnie działa nie jest oznaką braku profesjonalizmu, lecz informacją, że w środowisku developera/programisty ten błąd nie istnieje. To klucz do odnalezienia problemu, a nie przejaw braku kompetencji.

tomaszk-poz
tomaszk-poz
7 years ago
Reply to  widelec

Zależy w jakim kontekście jest “a u mnie działa”. Jak byłem wdrożeniowcem to serwisanci od dostawcy (produkt z pudełka) puszczali mi takie kity, że aż wstyd.
Potrafił mnie pytać, czy zaktualizowałem …Media Player’a, proponował reinstalację os serwera produkcyjnego :-D. Dopiero jak pokazałem raporty z windbg to zaskoczony zamknął japę i cudownie udało się zrobić poprawkę na drugi dzień.

Inna ich ulubiona odpowiedź: “tak działa program”.

Runaurufu
7 years ago
Reply to  Michal Franc

Z doświadczenia wiem, że są takie sytuacje, że ładujesz cudzą bazę, cudze ustawienia i u deva chodzi bez problemu… podczas gdy to samo zrobione w ten sam sposób na kompie nie deva potrafi wytworzyć piękny exception, którego ni jak nie jest się w stanie u siebie powtórzyć… dlaczego? Kto wie? Może dllki z GACa działają inaczej niż te które wrzucasz do instalki? Może coś jest przebudowane w debugu i z jakiegoś powodu działa inaczej… a może po prostu bogowie Cię nie lubią.
Tak czy inaczej – wizja świata bez testerów (poza sytuacjami, gdy aplikacja ma służyć programistom) jest absurdalna, bo szary człowiek inaczej używa aplikacji niż ktoś o technicznym wykształceniu… a jeśli jeszcze do tego zjadł zęby na naprawianiu bugów by apka była bardziej user-friendly to już w ogóle inaczej mu się iskrzą zwoje w mózgu. Do tego dochodzą przyzwyczajenia użytkowników z innych aplikacji, o których programista może nie mieć pojęcia (wpadlibyście na to, że podgląd jakiegoś schematu odświeża się tylko i wyłącznie za pomocą kliknięcia LPM i PPM?) i już się okazuje, że programista to jednak programista a nie tester… a specjalizacja o której p. Michał mówi to po prostu rozwój vs. bug-fixing – i to już się dzieje bo jakoś tak gdy produkt jest już w 99% gotowy to nagle programiści zwijają manatki i idą w siną dal szukać “nowych wyzwań”…

Michal Franc
7 years ago
Reply to  Runaurufu

@RUNAURUFU

Nie bug-fixing ale programisci ktorzy tworza testy automatyczne. Kilkanie manualne i testy manualne to przeszlosc. Programisci jak zwmywaja manatki i ida szukac nowych wyzwan sa nieprofesjonalni :) Profesjonalny programista skupia sie na produkcie biznesie a nie na technicznych wyzwaniach.

@WIDELEC

Ok zgodze sie troche przesadzilem ale srodowisko developera powinno byc w stanie odtworzyc warunki srodowiska produkcyjnego. Jak tego nie ma to warto zastanowic sie jak to zmienic ( tak sa wyjatki i systemy ktorych nie ruszysz )

WIDELEC
7 years ago
Reply to  Michal Franc

Czemu uważasz, że:
“Programisci jak zwmywaja manatki i ida szukac nowych wyzwan sa nieprofesjonalni :) Profesjonalny programista skupia sie na produkcie biznesie a nie na technicznych wyzwaniach.” ?
Tendencją polskich firm jest stagnacja i brak odwagi wdrażania nowych rozwiązań poprawiających wydajność produktu. Znam firmy, które zatrzymały się na php4! i nie ruszają swoich projektów bo działają. Jeśli siedzisz w jednej firmie za długo to dopada Cię wypalenie. Nie masz wyzwań, robisz ciągle to samo i się nie rozwijasz. Idąc gdzie indziej pytasz o wykorzystywane technologie i *boom*, *wow* – oni robią to całkowicie inaczej i innymi rozwiązaniami! To jest rozwój! Profesjonalny programista ma wiedzę i doświadczenie w jej wykorzystywaniu w praktyczny sposób! Dąży do osiągnięcia jak najwięcej i zmiana pracy często mu to właśnie oferuje. Nie piszę tu o skoczkach po 3 miesiące, ale o ludziach powyżej 3-4 lat w jednym projekcie.

Michal Franc
7 years ago
Reply to  WIDELEC

Sa na rynku firmy ktore nie podazaja za takimi tendencjami. I to nie tylko specyfika Polskiego rynku ale wieszkosci rynkow. Malo jest firm ktore nie boja sie eksperymentowac bo jest to ryzykowne i kosztowne. Nie dziwie sie ze wiele produktow i organizacji skupia sie na starych sprawdzonych technikach. Tak samo ciezko znalezc ciekawy projekt ktory wart jest naszej uwagi i skupienia sie. Natomiast sa takie projekty i firmy i warto ich poszukac.

Jak mowimy o 3-4 latach to zgadzamy sie w zupelnosci :)

coffeina
coffeina
7 years ago
Reply to  Runaurufu

RUNAURUFU zgodze sie z Toba w 100%. Mam pytanie do Ciebie: jak widzisz wspolprace programistow i testerow w jednym projekcie? Zauwazylem nacisk (i co moim zdaniem jest na prawde dobre) na testy automatyczne. Im wiecej automatyzacji tym lepiej, poniewaz cos da sie zrobic szybciej, uruchomic testy w srodku nocy, testy automatyczne nie odczuwaja zmeczenia przy 10 buildzie jaki chcesz przeztestowac. jedn klik i poszlo … Ale takie srodowisko nalezy utrzymywac i wlozyc czasami bardzo duzo pracy by w ogole ruszylo. Za to taki wklad procentuje. Wg mnie tester jest osoba ktora dba o utzrymanie srodowiska testowego, dodajac nowe przypadki testowe plus wykonujac testy manualne. Jak to wyglada w Waszych projektach ?

Runaurufu
7 years ago
Reply to  coffeina

Przede wszystkim automatyczne testy to jest błogosławieństwo, które daje szansę na wychwycenie problemów w obszarach o których się nie myśli lub nie wie o ich istnieniu. Kto o nie powinien dbać? Zależy. Jeśli to są unit testy czy inne typowo kodowe rzeczy to najwłaściwsi byliby deweloperzy pracujący nad daną funkcjonalnością (a najlepiej wsparci przez ludzi z QA/programujących testerów jeśli takowi są ^.^).
Większy problem jest z testami _nie kodu_ bo tego programista nie zrobi dobrze, bo nie da się przewidzieć wszystkiego. Od tego powinien być ktoś kto umie używać (w sensie produkcyjnym) softu, a nie tylko przeklikać i pokazać jak co działa. Ktoś kto wie jak pracują klienci, co i jak chcą zrobić. Ktoś kto będzie mógł “pobawić się” aplikacją by wykryć problemy, które wychodzą poza ramy “normalnego użytkowania” – jak choćby podchmielony user napastujący klawiaturę. I ktoś taki po prawdzie nawet programować nie musi umieć, bo i po co?
Ale fakt ogólna tendencja do automatyzacji jest i jest ona coraz większa. Trochę mam wrażenie, że traktuje się to jako “świętego Graala”, którego trzeba zdobyć i już się jest nietykalnym – a to tak niestety nie działa. Bo co z tego, że wszystkie unit testy są “zielone” jak po wciśnięciu guzików w innej niż zakładana kolejności nagle dostajemy exception, zwis systemu i x czasu w plecy?

Norbert Rozmus
Norbert Rozmus
7 years ago
Reply to  Michal Franc

Może trend taki jest, ale jest on wydaje mi się dość wolny, oczywiście nowe projekty – nowe podejście umożliwia takie działania, ale przy starych legacy-projektach jest to ( wydaje mi się) nie możliwe do przejścia.

Michal Franc
7 years ago
Reply to  Norbert Rozmus

Projekt moze byc blokada, ale nie powinien byc taka blokada ktorej nie da sie obejsc. Testy automatyczne to duzo plusow, ale tak wiele firm nie podazy za tym trendem i pozostanie przy manualnym testowaniu.

Norbert Rozmus
Norbert Rozmus
7 years ago
Reply to  Michal Franc

Projekt oraz osoby które przy nim pracuj. Co jak co ale testy trzeba umieć pisać. Nie wszystkim się niestety chce. Trochę to smutne

coffeina
coffeina
7 years ago
Reply to  Michal Franc

Nie wszystko da sie przetestowac automatycznie.

widelec
7 years ago
Reply to  coffeina

Co np. się nie da? Obecnie są takie technologie, że wydaje mi się, że zawsze znajdzie się sposób by coś przetestować. Poza tym, niektórzy kod zaczynają pisać od pisania testów. Weź też to pod uwagę ;)

coffeina
coffeina
7 years ago
Reply to  widelec

@WIDELEC np podchmielonego goscia probojacego skorzystac z smartfona.

widelec
7 years ago
Reply to  coffeina

@COFFEINA
nie wiem jakie testy prowadzisz, ale ja pytałem o kod

Runaurufu
7 years ago
Reply to  coffeina

No ale to mówimy o testach kodu czy testach aplikacji. Bo pierwsze obsłużyć to nie jest problem (może jest czasochłonne, ale się da zautomatyzować), ale co do drugiego to już bardzo różnie bywa… Choćby taki casus podchmielonego użytkownika.

coffein
7 years ago

To co ja zauważyłem i z jakim sie nie raz spotkałem to: programista vs tester.
– u mnie dziala – programista
– ale zobacz tutaj … – mowi tester
– zle testujesz – mowi programista

Jest produkt ktory razem rozwijamy, jeśli jest beznadziejny: nie dziala zgodnie z wymiaganiami, jest wiele defektow krore obnizaja jego jakość, nie ma odpowienich zabezpieczen(jesli chodzi o kase), etc … => klient nie jest zadowolony i mozemy poplynać. A to nie jest dobre.
Druga sprawa: tworzymy rozwiazania nie tylko dla samych siebie. Tworzac program/aplikacjie/rozwiaznie mozemy nie przewidziec wszystkich edge caseow. I co wtedy? Wytedy nie dziala i tyle. Trzeba napisac fixa i sprawdzic ze rzeczywiscie dziala.

Kurs Gita

Zaawansowany frontend

Szkolenie z Testów

Szkolenie z baz danych

Książka

Zobacz również