Czy testerzy są potrzebni?

0

Siema wszystkim, przejdę Od razu do rzeczy. Pracuję, jako tester, dużo o tym czytam itd. i natrafiłem ostatnio na kilka opinii, że testerzy są...niepotrzebni. To demotywuje trochę. Chciałbym prosić o Wasze zdanie na ten temat. Może przede wszystkim programistów, czy ludzi bardziej doświadczonych w zawodzie...
Z góry dziękuję ;)

0

Nikt nie wyłapie wszystkich błędów, żebym miał fundusze sam bym zatrudnił kogoś do testowania :p

6

No u mnie w firmie też są opinie, że testerzy są niepotrzebni, a mimo to zwykle niedługo po deployu klienci przysyłają listę bugów w oprogramowaniu na produkcji. Mało tego - są bugi które w kółko powracają. Mimo to nie mamy wydzielonych testerów. Testami zajmują się programiści, co jest moim zdaniem słabe, bo testera da się zatrudnić taniej niż programistę, a jednocześnie tester nie powinien znać kodu aplikacji, by nie unikać (podświadomie/ od niechcenia/ z przyzwyczajenia/ whatever) kroków postępowania które wykażą błędy.

Nie licząc Comarchu (w którym niewiele się nauczyłem) to pracuję już w trzeciej firmie i w każdej z nich zwykłe klikanie po wersji produkcyjnej dość szybko ujawniało błędy, mimo iż nieraz kod miał w miarę OK pokrycie testami.

0

W dzisiejszych czasach nie potrzeba już testerów. Każda praktycznie gra jest wypuszczana bez testowania, a klienci i tak wyłapią wszystkie błędy - to jest najbardziej opłacalne.

0

U nas w firmie jest dział testerów. Niestety z testami ludzkimi jest taki problem, iż często są zgłaszane problemy kompletnie nieadekwatne do sytuacji lub też testy są przeprowadzane dość kiepsko.
Według mnie od testów powinny być automaty - czyli testy jednostkowe, integracyjne, funkcyjne itp. Takie coś zastępuje dział testów i ludzi, którzy testują aplikacje nierównomiernie, niedokładnie i bez ustalonego algorytmu lub też ten algorytm łamią w pewnych sytuacjach.

Niemniej na dziś, jak widzę, iż firma posiada dział testów to kojarzy mi się jednocześnie z profesjonalizmem. Raczej nie chciałbym pracować w firmie gdzie nie ma jednej z tych rzeczy:

  • Testerów
    lub
  • testów jednostkowych, integracyjnych i funkcyjnych.
1

Oczywiście, że testerzy są potrzebni. Ja sam nie jestem w stanie pomyślec o każdym scenariuszu, częściej się zafiksuje na jednym paroma.

Kiedyś naprawiałem buga zgłoszonego przez testera i nie mogłem go powtórzyć mimo scenariusza. Po rozmowie, okazało się, że ja klikam a on wciska bodajże Enter, i to robiło różnicę.

Testerzy są potrzebni.

4

Warto przeczytać -> "Top Five (Wrong) Reasons You Don't Have Testers"
http://www.joelonsoftware.com/articles/fog0000000067.html

Testerzy są bardzo potrzebni. Szczególnie dlatego że testerzy są nastawieni zupełnie inaczej niż programiści i programista nie wyłapie nawet 5% błędów. Ale jednocześnie nie chodzi mi tutaj o testerów-klikaczy. Testerzy to są ludzie którzy powinni wymyślać jak rozwalic aplikację a potem tworzyć automatyczne testy które będą to wykonywać.

4
Wybitny alien napisał(a):

U nas w firmie jest dział testerów. Niestety z testami ludzkimi jest taki problem, iż często są zgłaszane problemy kompletnie nieadekwatne do sytuacji lub też testy są przeprowadzane dość kiepsko.
Według mnie od testów powinny być automaty - czyli testy jednostkowe, integracyjne, funkcyjne itp. Takie coś zastępuje dział testów i ludzi, którzy testują aplikacje nierównomiernie, niedokładnie i bez ustalonego algorytmu lub też ten algorytm łamią w pewnych sytuacjach.

Niemniej na dziś, jak widzę, iż firma posiada dział testów to kojarzy mi się jednocześnie z profesjonalizmem. Raczej nie chciałbym pracować w firmie gdzie nie ma jednej z tych rzeczy:

  • Testerów
    lub
  • testów jednostkowych, integracyjnych i funkcyjnych.

Co innego testy jednostkowe, co innego funkcjonalne a co innego funkcyjne, co innego INTEGRACYJNE i jeszcze AKCEPTACYJNE. Jestem testerem i piszę testy automatyczne. Niestety z mojego doświadczenia -> developerzy są idiotami w tej kwestii. Mają siebie za geniuszy a kogoś kto zajmuje się programowaniem testów za debili. Zależnie od problemu i wielkości systemów wiadomo różne metody się przydają a inne nie, niemniej jednak developer testując kod, ba nawet testując czyjś kod nie wyłapie błędów. On patrzy na to spod spodu. Poza tym testując coś swojego mamy nadzieję ze nie znajdziemy błędu, wiec nie testujemy tego tak dokładnie jak osoba "z zewnątrz"(jest to w każdym kursie dla testerów na samym początku). Tester ma wziąć produkt i traktować jak blackbox po prostu-> bierze i sprawdza czy działa.
Odkąd pracuję na tym stanowisku ciągle widzę jak programiści nie doceniają nas i mają za kogoś gorszego. Dla mnie to po prostu oznaka ich debilizmu i zawyżonej samooceny. "Jak jakiś tester może wytykać mi błędy, przecież on nic nie umie!!!"

0
Shalom napisał(a):

Warto przeczytać -> "Top Five (Wrong) Reasons You Don't Have Testers"
http://www.joelonsoftware.com/articles/fog0000000067.html

Testerzy są bardzo potrzebni. Szczególnie dlatego że testerzy są nastawieni zupełnie inaczej niż programiści i programista nie wyłapie nawet 5% błędów. Ale jednocześnie nie chodzi mi tutaj o testerów-klikaczy. Testerzy to są ludzie którzy powinni wymyślać jak rozwalic aplikację a potem tworzyć automatyczne testy które będą to wykonywać.

Wg mnie klikacz jest tak samo potrzebny jak ten który zajmuje się automatycznymi testami. Dlaczego? Dlatego że to on jest tym który "udaje klienta". On sprawdza to czy system posiada cechy i przede wszystkim czy systemu da się używać. To nie automat będzie na końcu klikał tylko pani Grażyna z księgowości albo Józek z banku spółdzielczego. Bo to oni są klientami.

1
Wybitny alien napisał(a):

U nas w firmie jest dział testerów. Niestety z testami ludzkimi jest taki problem, iż często są zgłaszane problemy kompletnie nieadekwatne do sytuacji lub też testy są przeprowadzane dość kiepsko.

To znaczy, że ci testerzy są słabi. Zatrudnijcie lepszych albo szkolcie obecnych.

Według mnie od testów powinny być automaty - czyli testy jednostkowe, integracyjne, funkcyjne itp. Takie coś zastępuje dział testów i ludzi, którzy testują aplikacje nierównomiernie, niedokładnie i bez ustalonego algorytmu lub też ten algorytm łamią w pewnych sytuacjach.

:D :D :D
Dobrzy testerzy przetestują aplikację lepiej niż sztywno napisane testy, bo używają intuicji i doświadczenia.
I niestety nie wszystko da się przetestować jednostkowo czy integracyjne. Niektóre rzeczy wymagają automatycznych testów UI, a te też piszą testerzy.

Ważnym aspektem jest też to, że za przetestowanie aplikacji ktoś musi wziąć odpowiedzialność i się pod tym podpisać. Komputer tego nie zrobi.

Mały Mleczarz napisał(a):

Niestety z mojego doświadczenia -> developerzy są idiotami w tej kwestii. Mają siebie za geniuszy a kogoś kto zajmuje się programowaniem testów za debili.

Programiści w ogóle często nie myślą nad tym, co robią i tworzą kod na zasadzie: "jebnę sobie fajną funkcję" w ogóle bez myślenia o jakości, wydajności czy poprawności wyników.

Odkąd pracuję na tym stanowisku ciągle widzę jak programiści nie doceniają nas i mają za kogoś gorszego. Dla mnie to po prostu oznaka ich debilizmu i zawyżonej samooceny. "Jak jakiś tester może wytykać mi błędy, przecież on nic nie umie!!!"

To samo tyczy też testerów - są tacy, którzy twierdzą, że programiści to debile, i traktują ich jako wrogów, którym trzeba personalnie wytknąć jak najwięcej błędów. Co też jest idiotycznym podejściem, bo przecież gdyby programiści byli bezbłędni, to testerzy nie byliby w ogóle potrzebni.

Jeśli taką masz atmosferę w firmie, to idź tam, gdzie stosunki między programistami a testerami są normalne.

Mały Mleczarz napisał(a):

Wg mnie klikacz jest tak samo potrzebny jak ten który zajmuje się automatycznymi testami. Dlaczego? Dlatego że to on jest tym który "udaje klienta". On sprawdza to czy system posiada cechy i przede wszystkim czy systemu da się używać. To nie automat będzie na końcu klikał tylko pani Grażyna z księgowości albo Józek z banku spółdzielczego. Bo to oni są klientami.

Użytkownik to nie to samo co klient.

1

Wbrew pozorom płace testera nie są niskie. Słyszałem, że dobry tester może w Polsce dostać nawet 10k.
Do testowania-klikania trzeba mieć odpowiednie cechy charakteru, ja bym na takim stanowisku oszalał po dwóch tygodniach.

1

Stawki osob zwiazanych z testami w KRK (specjalistow) sa nie gorsze niz w Javie (pracowalem 6 lat w testach, teraz przerzucilem sie na developerke).

Co do stwierdzenia:

U nas w firmie jest dział testerów. Niestety z testami ludzkimi jest taki problem, iż często są zgłaszane problemy kompletnie nieadekwatne do sytuacji lub też testy są przeprowadzane dość kiepsko.
To po pierwsze czesto developerzy nie patrza pod katem wygody uzytkownika, latwosci uzycia itp. Byle dzialalo zgodnie ze specyfikacja, ale to ze uzywanie pozniej takiego narzedzia to koszmar to juz inna bajka (np. kiedys tak sie musialem wyklocac ze jesli GUI potrzebuje 10-20 s na odpowiez i freezuje sie na ten czas to nie powinno to tak dzialac).

Co do cech charakteru - najgorsze jest wyklocanie sie o to czy cos jest defektem i trzeba poprawic czy nie (dlatego odszedlem od testow). Samo szukanie dziury w calym jest fajne, do tego po jakims czasie staje sie druga natura i to nie tylko w sofcie, rowniez w urzadzeniach, procesach itp.

Tester ma wziąć produkt i traktować jak blackbox po prostu.

  • to tylko czesciowa prawda, wszystko zalezy od tego jakie testy wykonujesz. Z grubsza mozna wyroznic:

Smoke testy, sanity, performance, longevity, unit testy, integracyjne, regresje, alfa, usability, pentesty, akceptacyjne itp. wiekszosc z nich mozna traktowac zarowno jako white i black box.

0

Testerzy są bardzo potrzebni, tylko często atmosfera między nimi a programistami jest zamącona (jak widać powyżej).
Tester powinien wytknąć wszystkie błędy najlepiej bezosobowo, schody zaczynają się gdy tester zaczyna błędy "personalizować" albo szukać winnych. Albo pisze takie zgłoszenia typu "poszukaj sobie" np:

"Na ekranie wypłat regularnych kwota przed podatkiem jest za niska"

  • nie wiadomo który to ekran (transakcji są setki, każda ma po kilka ekranów)
  • nie wiadomo dla którego klienta
  • o jakie pole chodzi - bywa że nawet jest to niewidoczna wartość pośrednia
  • nie wiadomo jaka powinna być wartość
  • nie wiadomo wg jakiego wzoru jest liczona (błędy zgłaszane są np. do istniejących funkcjonalności które mają błędy i nie były ruszane)

Co ważne, to to że charakter pracy testera może być różny, w zależności od organizacji.
Jeśli to osoba która tylko klika i patrzy czy ekrany reagują, to rzeczywiście można ją zastąpić przez automat.
Jeśli to osoba która czytając analizę funkcjonalną sprawdza czy odpowiada ona stanowi systemu (także całościowo - od strony bazy danych) to taka osoba jest niezastąpiona.

0

Nikt nie napisał czy lubi testować. Otóż ja lubię programować i nie lubię testować. Oczywiście muszę przetestować co napisałem i klikam na różne sposoby. Jednakże z powodu tego, że zajęcie to jest nuuudne, to nie raz pominę jakieś przypadki szczególne bo stwierdzam "jest ok, działa - kod przeszedł review, to sprawdziłem i to i tamto". Po czym się okazuje, że jak się kliknie tak, siak, a potem nijak, to jest błąd.

My w firmie nie mamy działu testerów, bo faktycznie byłoby to nadmiarowe w tym przypadku. Mamy natomiast system, że po wdrożeniu testowym inny programista testuje i akceptuje bądź nie. System ten się sprawdza, bo błędów tak dużo nie wychodzi. Najczęściej takie trudne do powtórzenia.

3

Według mnie od testów powinny być automaty - czyli testy jednostkowe, integracyjne, funkcyjne itp. Takie coś zastępuje dział testów i ludzi, którzy testują aplikacje nierównomiernie, niedokładnie i bez ustalonego algorytmu lub też ten algorytm łamią w pewnych sytuacjach.

A kto te automaty będzie programował? Programiści piszący testowane oprogramowanie? To się niemal nigdy nie sprawdza.

Właśnie potrzebujesz osobny dział testów do programowania/rozwijania tych testów automatycznych. Programista oczywiście też powinien pisać testy jednostkowe/integracyjne, po to aby samemu mieć pewność, że jego kod robi, to co chciał aby robił, ale taki sposób testowania jest niewystarczający, bo jeśli programista o czymś nie pomyślał w trakcie pisania kodu, to na ogół nie pomyślał też o tym w trakcie pisania testów. Osobny dział testów natomiast będzie stawał na głowie aby coś zepsuć, bo dla nich zepsucie czegoś to wielki powód do dumy.

My mamy bardzo dużą liczbę testów jednostkowych + integracyjnych pisanych przez programistów, ale i tak dział QA potrafi złapać czasami różne ciekawe rzeczy. No i dział QA testuje oprogramowanie w różnych dziwnych warunkach, np. na klastrach po 1000+ węzłów, testuje nietypowe konfiguracje. Tego zwykły programista nie powinien robić, bo straciłby na to za dużo czasu, a dawanie każdemu możliwości przeprowadzania takich dużych testów mogłoby się skończyć katastrofą finansową. Lepiej mieć dedykowany zespół. I tak na sam hardware do testów idą u nas miliony $$$ rocznie (dosłownie).

Poza tym dział QA i tak nie jest w stanie wyłapać wszystkich błędów (czasem niestety coś przejdzie na produkcję), ale przynajmniej wiadomo, że nie ma poważnych błędów.

0

Trochę odkopię, ale ciekawi mnie czy w firmach, w których pracujecie bywa tak, że testują tylko testerzy. Rozumiem ideę TDD i jakie niesie ze sobą korzyści, ale z drugiej strony ostatnio odnoszę wrażenie, że w firmie, w której pracuję testy pochłaniają za dużo czasu programistów i niewiele dają. Spotkałem się ze stwierdzeniem, że testy powinny zając 20% czasu feature'a, natomiast programiści momentami poświęcają na nie więcej czasu niż na samą funkcjonalność. Czy to jest dobre podejście? Zaczynam powoli kwestionować w ogóle sens testowania kodu przez programistów, mimo to dużo firm robi tak, że testują tylko programiści lub testują oni wstępnie (pisząc testy naturalnie, nie klikając), a potem dodatkowo tworzą testy np. w selenium nieprogramiści (niekoniecznie pełnoprawni testerzy). Czy biorąc pod uwagę fakt, że programiści nie piszą efektywnie testów, jest w ogóle sens, żeby oni je pisali?

0

Moim zdaniem pokrycie kodu testami automatycznymi jest kluczowe, jeżeli chcemy refaktorować kod na bieżąco (tzn od razu gdy zajdzie potrzeba). O pozostałych rodzajach testów już inni się tutaj wypowiedzieli.

0

Zakładam tylko testy automatyczne i oczywiście odpowiednie pokrycie też, ale pytanie nie tego dotyczy. Pytam, czy to pokrycie powinien zapewnić jedynie tester, czy już programista i jeśli ten ostatni, to w jakim stopniu. Bo skoro zakładamy, że tester jest bardziej efektywny w testowaniu, to czy jest sens, żeby programista zapewniał częściowe pokrycie testami, skoro on (tester) może to zapewnić w lepszym stopniu przy ścisłej współpracy z programistą? Nie ma tutaj problemu z refactoringiem, jeśli osoby są odpowiednio zgrane.

0

A jaki jest stosunek czasu spędzonego na łataniu błędów do czasu spędzonego nad nowymi funkcjonalnościami? To jest pochodna jakości kodu produkcyjnego, a ta jest w dużej mierze zależna od jakości testów. I tak zdecydowanie więcej czasu spędza się na refaktoringiem i szukaniem błędów, niż nad tworzeniem nowych funkcjonalności, więc spędzanie większej ilości czasu nad pisaniem testów niż nad pisaniem kodu produkcyjnego jest jak najbardziej OK moim zdaniem.

Tester nie powinien w ogóle znać kodu produkcyjnego, a tym bardziej być w stanie napisać testy jednostkowe. Tester ma testować działanie skonfigurowanego produktu, a nie abstrakcyjnych tworów (z punktu widzenia użytkownika) jakimi są klasy w kodzie.

Zresztą gdyby był wydzielony gość od pisania testów to byłoby to antyproduktywne. Programista musiałby czekać na testera, a tester na programistę (w sensie, że w danej chwili mógłby pracować tylko jeden z nich). Nie ma sensu rzeźbić w kodzie jeśli testy nie przechodzą (bo można dołożyć sobie roboty), a tym bardziej zmieniać testów hurtowo bez poprawiania kodu produkcyjnego na bieżąco.

1 użytkowników online, w tym zalogowanych: 0, gości: 1