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!
źródło
Odpowiedzi:
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.
źródło
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.
źródło
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ć.
źródło
Słusznie.
Decyzja należy do Ciebie.
Być może jesteś w złej pracy. Wiele osób lubi ponosić dodatkową odpowiedzialność.
Jeśli kierownictwo tak mówi, tak.
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.
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.
W razie potrzeby tak.
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.
źródło
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ę.
źródło
„ Gdyby twój samochód miał pas bezpieczeństwa, cały czas byś go zepsuł! ”
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.
To nie jest (całkiem) prawidłowe pytanie. Lepiej zapytaj „kiedy jakość produktu / wizerunku firmy jest tak ważna, że wymaga testerów?”
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ą).
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).
źródło
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.
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.
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ś.
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).
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.
Udokumentuj swój kod i jego architekturę, pomoże ci to w zrozumieniu możliwych wad (moje własne doświadczenie).
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.
źródło