Czy programista powinien być samowystarczalny?

28

W moim obecnym miejscu pracy nie mamy żadnych testerów, uzasadnienie ze strony kierownictwa brzmi: „gdybyśmy mieli testerów, w ogóle nie testowalibyście własnego kodu”. Tego rodzaju myślenie wydaje się być szkodliwe dla jakości produktu, ponieważ podczas testowania własnego kodu jest wiele rzeczy, za którymi będę tęsknił tylko dlatego, że znam system na wylot i nie wiem, jak go używać To błędne". Testowanie czarnej skrzynki tak naprawdę nie działa, ponieważ podświadomie unikam pułapek, w które wpadłby dedykowany tester. Dużo czasu poświęcam na naprawianie błędów, które zostały wprowadzone do kodu produkcyjnego i znalezione przez użytkownika końcowego.

System, o którym mowa, jest duży, ale został opracowany wyłącznie przeze mnie. Spowodowało to również, że niektóre obowiązki zarządcze spadły mi na kolana, takie jak definiowanie harmonogramów i praca nad specyfikacjami.

Czy takie zadania powinny być moją odpowiedzialnością? Uważam się za programistę i nic więcej. A jeśli to moja odpowiedzialność, w jakim stopniu? Kiedy projekt jest tak duży, że wymaga testerów? Czy programista powinien dopracować specyfikację, martwić się o zarządzanie projektem, a nawet zapewnić obsługę klienta?

Uwaga

Niektórzy mogli odnieść wrażenie, że jestem przeciwny rozszerzaniu moich obowiązków - tak nie jest, chętnie dostanę rolę, która wymaga większej liczby obowiązków kierowniczych, ale obecnie nie ma tego w opisie mojej pracy. Dopóki nie będę oficjalnie zatrudniony jako taki lub dopóki dodatkowe obowiązki nie zaczną się pojawiać w mojej wypłacie, będę uważał się za „po prostu” programistę. Niestety, jako młodszy programista, przejście do obowiązków kierowniczych nie nastąpi wkrótce.

Jak dotąd doskonałe odpowiedzi, zachęcaj je, jeśli chcesz coś dodać lub podzielić się osobistymi doświadczeniami!

Tatu Ulmanen
źródło
4
Ach, stary, dobry scenariusz „użytkownicy jako testerzy”. Dobrze to wiedziałem.
Matt Ellen,
Przepraszam, muszę ci to powiedzieć, ale ... twoje kierownictwo jest pełne idiotów :(
dr Hannibal Lecter,
1
Jak duża jest firma, dla której pracujesz? Jeśli zatrudniliby testera, to czy byłaby wystarczająca ilość pracy, aby utrzymać je w pełnym wymiarze godzin? Gdyby zatrudniali kierownika projektu, czy byłoby wystarczająco dużo pracy, aby utrzymać ich zajęty w pełnym wymiarze godzin? Miejscami pracy, w których sam musiałem zarządzać takimi rzeczami, były firmy, które nie były wystarczająco duże, aby uzasadnić innego pracownika do pełnienia tych ról.
Carson63000,
@ Carson6300, obecnie mamy 7 programistów, którzy są przepracowani i taką samą liczbę grafików. Mamy też zrobić mieć kierowników projektów, przynajmniej w pewnym sensie tego słowa. Jak powiedziałem: „… spowodowało pewne obowiązki zarządcze…”; większość zarządzania jest nadal wykonywana przez kierownika projektu. Sądzę, że jesteśmy na tyle duże, aby uzasadnić oddanych testerów.
Tatu Ulmanen
Być może musisz pokazać swojemu zarządowi następujący artykuł: Operant Conditioning by Software Bugs
Vaibhav Garg

Odpowiedzi:

19

Ci zrobić mają testerów. Tylko nazywasz ich „użytkownikami końcowymi”. Jest to szkodliwe z wszystkich powodów, które opisujesz; bez względu na to, jak sumienny jesteś koderem, po prostu nigdy nie będziesz w stanie wykonać wystarczająco dobrej pracy, pokonując własne uprzedzenia co do tego, w jaki sposób kod ma być „używany”, aby znaleźć wszystkie sposoby, które mogą go zepsuć. .

Musisz ponownie otworzyć ten problem z zarządzaniem. W tym momencie wydaje się, że masz jakieś twarde dane na poparcie swojej sprawy; obecne praktyczne podejście do zapewniania jakości marnuje czas i pogarsza wrażenia użytkowników. Musisz być ostrożny w tym, jak to prezentujesz, aby było jasne, że jest to problem strukturalny, a nie przypadek „Po prostu ssiesz testowanie”, ale brzmi to jak dyskusja, która musi się odbyć.

Wygląda na to, że zbliżasz się do skrzyżowania z tym pracodawcą. Jeśli chcesz pozostać programistą i nic więcej, być może będziesz musiał zacząć odpychać się i prosić o pomoc, abyś mógł odebrać ci niektóre zadania kierownicze, albo przez sprowadzenie kogoś nowego, albo przez rozszerzenie zakresu obowiązków istniejącego współpracownika. („Nie po to mnie zatrudniliście, a te zadania nie znikają. Czas, który źle spędzam na robieniu tych rzeczy, to czas, w którym nie spędzam na tym, w czym jestem dobry.”) Ale to może, a może nie być realistą. Czy uważasz, że poradzisz sobie z przejściem na bardziej kierownicze stanowisko, jeśli dadzą ci zasoby i uprawnienia, których potrzebujesz, aby dobrze wykonać pracę?

Co do tego, jak duży musi być projekt, zanim będzie wymagał testerów, nie jestem pewien, jak dokładnie zdefiniować tę linię, ale zdecydowanie myślę, że ją przekroczyłeś. Spędzasz więcej czasu niż chcesz naprawiać raporty o błędach pochodzące od rzeczywistych użytkowników; dla mnie to mówi, że czas poświęcić więcej wysiłku, aby powstrzymać błędy przed dotarciem do użytkowników.

BlairHippo
źródło
wspaniale powiedziałem, pracowałem w tak wielu miejscach, w których szef myślał, że programista musi przetestować oprogramowanie, ani jedno nie było dobrym miejscem do pracy, jeśli firma nie ma testerów, po prostu nie rozumie podstaw tworzenia oprogramowania lub są tanimi draniami , tak czy inaczej, powinieneś znaleźć inną pracę
jonathan
13

Tak. Jeśli masz do nich, powinieneś być w stanie przetestować swój kod. (Nie mówię o testach jednostkowych, ale testach akceptacyjnych itp.)

Nie . Testerzy są lepsi w testowaniu niż ty. Jak zauważyłeś, podobnie jak korekta, bardzo trudno jest dostrzec własne błędy. Dodatkowe gałki oczne będą miały duży (dobry) wpływ na jakość twojego programu.

Masz wiele innych pytań. Odpowiem tylko na jedno:

Czy programista powinien dopracować specyfikację?

Tak! Musisz wdrożyć specyfikację, więc musisz upewnić się, że specyfikacja jest rzeczywiście możliwa do wdrożenia. Ponadto, jako programista - przeszkolony w zakresie jasnego myślenia, precyzji i tym podobnych - możesz pomóc ludziom odkryć, co naprawdę należy zrobić, i wyeliminować niejednoznaczne lub logicznie błędne wymagania.

Frank Shearar
źródło
5

To, co mówią i rzeczywistość, to prawdopodobnie dwie różne rzeczy. Najprawdopodobniej uzasadnienie brzmi:
„Dlaczego muszę płacić pensję testerowi, skoro mogę po prostu zmusić programistę do podwójnej pracy?”

Oczywiście nie zamierzają tego powiedzieć i wymyślą wszelkiego rodzaju wymówki, które uważają za uzasadnione. Myślę o kilku obaleniach na ich temat, ale szczerze mówiąc, nie pomogą. Widziałem tę bitwę w kółko, a oni po prostu zmieniają swoje podejście za każdym razem, gdy podważasz ich obecne rozumowanie. W końcu poddadzą się i po prostu polecą ci to zrobić, a ty zostaniesz oznaczony jako osoba składająca skargę.

Najlepszym podejściem, jakie mogę wymyślić, jest zajęcie się tym nie z punktu widzenia jakości, którego zarządzanie wydaje się nigdy nie doceniać, dopóki nie pojawią się problemy, ale z punktu widzenia kosztów. Testerzy są lub przynajmniej są postrzegani jako tańsi niż programiści. Przypomnij im, że wykonując podwójny obowiązek, płacą oni lepiej płatny zasób (programista), aby wykonać pracę, którą mógłby wykonać tańszy zasób (tester). Dlatego nie maksymalizują wartości, którą czerpią z umiejętności programowania.

Takie podejście ma tę wadę, że rozpada się, jeśli otrzymujesz pensję i nie mają żadnych komplikacji, jeśli chodzi o to, byś pracował więcej za darmo, ale warto spróbować.

JohnFx
źródło
Jeśli otrzymujesz pensję i nie mają żadnych przeszkód, abyś pracował więcej za nadgodziny, czas odejść.
glenatron,
Dzięki Bogu, że obowiązkowe nieodpłatne godziny nadliczbowe nie są wszędzie regulowane.
Steven Evers,
3

System, o którym mowa, jest duży, ale został opracowany wyłącznie przeze mnie. Spowodowało to również, że niektóre obowiązki kierownicze spadły mi na kolana, takie jak definiowanie harmonogramów i praca nad specyfikacjami.

Słusznie.

Czy takie zadania powinny być moją odpowiedzialnością?

Decyzja należy do Ciebie.

Uważam się za programistę i nic więcej.

Być może jesteś w złej pracy. Wiele osób lubi ponosić dodatkową odpowiedzialność.

A jeśli to moja odpowiedzialność, w jakim stopniu?

Jeśli kierownictwo tak mówi, tak.

Kiedy projekt jest tak duży, że wymaga testerów?

Gdy jest zbyt wiele innych prac, które muszą wykonać programiści. W tym momencie kierownictwo musi zdecydować, czy chce zatrudnić dedykowanego testera, czy podjąć ryzyko pominięcia testów. (Ostatecznie programiści mogą zrobić tylko tyle.)

Posiadanie dedykowanych testerów ma określone zalety, ale są też wady ... oprócz kosztów zatrudnienia dodatkowego personelu.

Jeśli programista będzie musiał udoskonalić specyfikację,

W razie potrzeby tak. W rzeczywistości, jeśli specyfikacja wymaga dopracowania, a nikt inny nad nią nie pracuje, wówczas jej niepodanie może spowodować niepowodzenie projektu.

martw się o zarządzanie projektem

W razie potrzeby tak.

a nawet zapewnić obsługę klienta?

W razie potrzeby tak.

Wydaje mi się, że jesteś przepracowany i reagujesz na presję. To jest problem. Ale zajęcie stanowiska, że ​​„nie jest twoim zadaniem wykonywanie X, Y, Z”, nie pomoże. Lepszym planem jest wyjaśnienie, że jest tylko tyle, co możesz zrobić, i wskazanie, że może to spowodować niedotrzymanie terminów, pogorszenie jakości, słabą obsługę klienta i tak dalej. Ale i tak daj z siebie wszystko ... nie niszcząc przy tym swojego zdrowia, relacji itp.

Stephen C.
źródło
Nie chodzi tylko o zarządzanie, jest też jego podejście i odpowiednia rekompensata. Jeśli OP jest niezadowolony ze swoich obowiązków w porównaniu z odszkodowaniami, całkowicie uzasadnione jest, aby spróbować ustalić punkt odniesienia, aby dowiedzieć się, czyje oczekiwania są bliższe rzeczywistości.
jmoreno
3

Mamy testerów. Nie chciałbym bez nich pracować. Chociaż piszę testy jednostkowe (używając TDD) i automatyczny test integracji dla całego mojego kodu, testerzy nadal pełnią bardzo cenną funkcję.

  1. Są wysoko wykwalifikowani i mają inne umiejętności niż programiści.
    1. Mają duże doświadczenie i wiedzę na temat przeprowadzania testów zapewniania jakości oraz sprawdzania, czy wygenerowany kod naprawdę odpowiada zarówno oczekiwaniom użytkownika, jak i faktycznemu zachowaniu użytkowników.
    2. Napotkali wiele błędów i są bardzo dobrzy w myśleniu o sytuacjach, które mogłyby uszkodzić oprogramowanie.
    3. Zwykle są cyniczne i systematyczne. Zauważyłem, że programiści są często bardziej optymistyczni.
  2. Dostarczają cennych wczesnych informacji zwrotnych na temat użyteczności. Na przykład podczas niedawnego tworzenia interfejsu API REST obszary, których testerzy kontroli jakości nie mogli łatwo zrozumieć, były dobrą wskazówką obszarów, z których użytkownik również byłby niezadowolony.
  3. Testują rzeczywiste środowisko, w rzeczywistości wiele konfiguracji rzeczywistego sprzętu, systemu operacyjnego itp.
  4. Wiedzą, jak budować duże, realistyczne łóżka testowe oraz przeprowadzać testy wydajności, obciążenia i obciążenia
  5. Koncentrują się na zapobieganiu wydostaniu się złych wydań. Programiści zwykle koncentrują się na wydaniu kodu. To prawie jak, programista domyślnie wyda kod, ale tester QA będzie potrzebował powodu, aby go zwolnić (wykazano, że działa!)
Flamingpenguin
źródło
0

„gdybyśmy mieli testerów, wcale nie testowałbyś własnego kodu”

Gdyby twój samochód miał pas bezpieczeństwa, cały czas byś go zepsuł!

Czy takie zadania powinny być moją odpowiedzialnością? [...] A jeśli to moja odpowiedzialność, w jakim stopniu?

Odpowiedź brzmi „to zależy”. Z tego, co rozumiem, twoi pracodawcy postrzegają cię jako „jednoosobowy dział IT”. Jeśli tak jest, to są (twoja odpowiedzialność). Jeśli masz obowiązki, których absolutnie nienawidzisz i których chcesz uniknąć, poszukaj stanowiska w firmie z większym działem IT.

Kiedy projekt jest tak duży, że wymaga testerów?

To nie jest (całkiem) prawidłowe pytanie. Lepiej zapytaj „kiedy jakość produktu / wizerunku firmy jest tak ważna, że ​​wymaga testerów?”

Gdyby programista musiał doprecyzować specyfikację, [...]

Tak, zdecydowanie. W większości przypadków istnieje duża rozbieżność między tym, czego potrzebuje programista / realizator, a tym, co zapewniają klienci [jako specyfikacje].

Wiele razy musisz znaleźć szare / nieokreślone obszary i zadać właściwe pytania, zauważyć i wskazać technicznie niemożliwe lub sprzeczne wymagania i tak dalej (szczególnie jeśli jesteś jedynym programistą).

[...] martwisz się o zarządzanie projektem, a nawet zapewnia obsługę klienta?

Zależy to od obowiązków, które przyjęliście na stanowisko. Na przykład niektóre pozycje wymagają bezpośredniego zwracania się do klientów. Wszystkie inne rzeczy są równe, starałbym się unikać takich pozycji (ale to zależy od ciebie i możesz nie mieć wielu możliwości wyboru pracy).

utnapistim
źródło
0

Po pierwsze, testowanie, a ściślej mówiąc Quality Assurance, to nie tylko testowanie funkcjonalności poprzez klikanie w aplikację. Zapewnienie jakości dotyczy procesów . Nie tylko testują aplikację w celu wykrycia błędów, ale także muszą zapobiegać ich tworzeniu przez programistów.

  1. Specyfikacja produktu + przypadki użycia
    Nawet jeśli wszyscy wiedzą (lub myślą, że wiedzą), co to jest funkcjonalność produktu, należy to zanotować. Nie można przetestować aplikacji bez jasnej specyfikacji. Specyfikacja określa, co jest poprawnym zachowaniem, a co błędem.
  2. Testy jednostkowe, testy integracyjne
    Testy elementów wewnętrznych, które są trudne do przetestowania za pomocą interfejsu użytkownika, wyjątkowe stany aplikacji. Jest to koniecznością dla każdego większego systemu. Oba typy testów mają również inną interesującą właściwość - zmuszają cię do ponownego przejrzenia każdej części kodu, a zdasz sobie sprawę z błędów / problemów architektury, których nigdy wcześniej nie widziałeś.
  3. Jakość kodu i standardy kodowania
    Jednym z zadań QA powinno być mierzenie złożoności kodu. Kod o niskiej złożoności zmniejsza prawdopodobieństwo błędów (zapobieganie błędom).
  4. Recenzje kodu
    Kiedy projekt osiąga określony rozmiar lub jest używany przez wielu użytkowników, recenzje kodu są koniecznością. Inny programista zawsze znajduje problemy z kodem / błędy, które przegapiłeś. Programiści są czasem ślepi na oczywiste błędy we własnym kodzie.
  5. Dokumentacja
    Udokumentuj swój kod i jego architekturę, pomoże ci to w zrozumieniu możliwych wad (moje własne doświadczenie).
  6. Testerzy
    Tester nie jest małpą, która po prostu klika interfejs użytkownika. Tester bierze specyfikacje i przypadki użycia i tworzy przypadki testowe. Następnie testuje je jeden po drugim. Jeśli użytkownicy końcowi zgłaszają błąd, należy do tego dodać testowy przypadek.

Programista nigdy nie powinien tworzyć specyfikacji (1). Nie jesteś tutaj, aby decydować o funkcjonalności. Zwykle muszą rozmawiać z użytkownikami końcowymi, tworzyć projekty graficzne itp. To czasochłonne zadanie. Jeśli programista decyduje o funkcjonalności, zwykle kończy się słowami „jest w porządku, ale czy możesz zmienić wszystko w tym oknie do jutra?” „nie tego chciałem” „działa, ale jest trudny w użyciu” „brakuje jedynej potrzebnej nam funkcji”.

Programista może osiągnąć 2, 3 i 5.

Potrzebujesz 4. programisty do 4. Każda firma z dużym projektem informatycznym i tylko jeden programista, który zna system, wchodzi na bardzo niebezpieczną ziemię.

Jeśli nie masz wystarczająco dużo czasu, nie zawracaj sobie głowy tworzeniem przypadków testowych (5). Oddana osoba jest zwykle potrzebna, ponieważ zajmuje dużo czasu. Bez przypadków testowych testowanie to tylko żart.

Sułtan
źródło