“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
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
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.
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”.
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ń”…
@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 )
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.
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 :)
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 ?
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?
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.
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.
Projekt oraz osoby które przy nim pracuj. Co jak co ale testy trzeba umieć pisać. Nie wszystkim się niestety chce. Trochę to smutne
Nie wszystko da sie przetestowac automatycznie.
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ę ;)
@WIDELEC np podchmielonego goscia probojacego skorzystac z smartfona.
@COFFEINA
nie wiem jakie testy prowadzisz, ale ja pytałem o kod
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.
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.