Dlaczego pozwolić / nie pozwolić programistom na przetestowanie własnej pracy

Chcę zebrać kilka argumentów, dlaczego pozwolenie programistom na przetestowanie własnej pracy jako ostatniego kroku przed wejściem produktu do produkcji jest złym pomysłem, ponieważ niestety moje miejsce pracy czasami to robi (ostatnim razem, gdy to się pojawiało , spór sprowadzał się do tego, że większość ludzi była zbyt zajęta innymi rzeczami i nie miała czasu na zapoznanie się z tą częścią programu przez inną osobę - jest to bardzo specjalistyczne oprogramowanie).

W tym przypadku istnieją plany testów (choć nie zawsze), ale zdecydowanie popieram stworzenie osoby, która nie dokonała testowanych zmian, faktycznie wykonując testy końcowe. Pytam więc, czy możesz podać mi dobrą i solidną listę argumentów, które mogę przywołać przy następnej dyskusji. Lub przedstawić kontrargumenty, jeśli uważasz, że jest to w porządku, szczególnie gdy istnieją formalne przypadki testowe do przetestowania.

Jak zauważyli inni (i ty), programiści powinni przetestować własny kod. Jednak później każdy nietrywialny produkt powinien zostać przetestowany przez niezależną osobę (osoby działające w dziale kontroli jakości i / lub samego klienta).

Programiści zwykle pracują z nastawieniem programistów na „jak sprawić, by to działało?” . Dobry tester myśli o tym „jak to przerwać?” - zupełnie inny sposób myślenia. Testy jednostkowe i TDD uczą programistów do zmiany kapeluszy do pewnego stopnia, ale nie powinieneś na tym polegać. Co więcej, jak zauważyli inni, zawsze istnieje możliwość niezrozumienia wymagań. Dlatego testy ostatecznej akceptacji powinny być przeprowadzane przez osobę możliwie najbliższą klientowi .

Deweloper wie, jak działa ich kod, i przyzwyczai się do testowania kodu zgodnie z tą wiedzą.

Deweloperowi trudno będzie usunąć się z myślenia „jak to działa”, a nie „jak to powinno działać”.

Z tego powodu lepiej jest poprosić kogoś o wysokim stopniu obiektywności do przetestowania programu, tj. QA lub Test Engineers

Testerzy Test na złamanie, prosty. Tego rodzaju stronniczość jest potrzebna, aby naprawdę dowiedzieć się o ogranicznikach programu.

Programiści MUSZĄ przetestować swoją pracę. Jest to dorozumiana odpowiedzialność.

Zakładam, że nie masz zespołu dedykowanego do przeprowadzania testów opartych na twoim oświadczeniu. Jednak posiadanie zespołu dedykowanego do testowania naprawdę pomoże, ponieważ programiści zwykle testują swój kod w sposób, w jaki go kodowali. Nie oznacza to, że gdy masz już jakiś zespół zapewniania jakości, możesz już przystąpić do testowania jako obowiązek programistów.

Programiści zwykle używają sieci z ogromnymi dziurami do wyłapywania błędów. W rezultacie uciekają mniejsze błędy.

Ponieważ programiści nie są dobrzy w próbach złamania własnego kodu. Ich umysł po prostu podąża właściwą ścieżką wprowadzania danych i interakcji z aplikacją. Wiele błędów wynika z interakcji z systemem jak normalny facet . Programiści nie są zwykłymi użytkownikami. Są profesjonalnymi użytkownikami.

Istnieje kilka dobrych powodów, aby mieć dedykowany zespół testujący. Po pierwsze, jak wspomniano powyżej, programiści bardzo dobrze sprawdzają, czy ich kod działa, ale go nie łamią.

Ponadto, jak mówisz, programista wie, co napisali, ale zespoły testujące wiedzą, co powinno być napisane. Czasami te dwie koncepcje nie pasują do siebie. Jednym z zadań zespołu testującego jest upewnienie się, że oprogramowanie spełnia wymagania. W wielu przypadkach programista zna bardzo dobrze tylko kilka części systemu, ale zespół kontroli jakości wie wszystko.

Co prowadzi do kolejnego powodu, zespoły testujące przeprowadzają pełne testy integracyjne. Fragment kodu, który właśnie napisałeś, może sam działać dobrze, ale może uszkodzić inne funkcje, o których nie wiedziałeś.

Po pracy z zespołem kontroli jakości i bez niego, mogę powiedzieć, że w 100% doceniam pracę, którą wykonują i powiem, że są cenioną częścią zespołu oprogramowania. Gdy masz zespół kontroli jakości, to znacznie ułatwia uwalnianie twojego kodu, bo wiesz, że został dokładnie przetestowany, a to oznacza, że ​​otrzymujesz mniej połączeń 3 nad ranem.

Programiści powinni testować własny kod.

Niezależni testerzy nie tylko testują złamanie, ale także testują nieokreślone i nieokreślone założenia, które opracowali programiści podczas kodowania.

Spodziewałbym się, że programista przeprowadzi wstępne testy przed dokonaniem jakichkolwiek zmian i upewni się, że kod działa. Oczekiwałbym wtedy, że programista dołączy do przypadków testowych jakąkolwiek konkretną wiedzę na temat „białej skrzynki”. Na przykład wyszczególnia wszelkie inne obszary kodu, które mogły zostać zmienione.

Główny sprzeciw programistów testujących własny kod polega na tym, że testujesz tylko jeden punkt widzenia. Deweloper przeczytał specyfikację i zinterpretował ją. Mamy nadzieję, że specyfikacja jest jasna, kompletna i jednoznaczna, ale nie zawsze tak jest. Deweloper mógł źle zrozumieć część specyfikacji. Jeśli przetestują własny kod, nie zostanie on przechwycony, ponieważ stwierdzą, że funkcja działa zgodnie z oczekiwaniami.

Różni ludzie będą również mieli tendencję do używania produktu w różny sposób i w wyniku tego będą przechodzić różne trasy przez kod. Deweloper zapewni, że kod będzie dla nich działał, ale mógł nie wziąć pod uwagę przypadku, który może znaleźć inny tester.

Programiści powinni przetestować własną pracę. Pozwalanie programistom na przekazywanie niesprawdzonej pracy zespołowi ds. Kontroli jakości lub ich współpracownikom to naprawdę zły pomysł. Marnuje czas zarówno programistów, jak i testerów oraz niszczy relacje.

Jednak to nie zawsze wystarcza. Deweloperzy prawdopodobnie będą podążać szczęśliwą ścieżką przez system lub będą ślepi na niektóre osobliwości, na które byli narażeni w kółko podczas rozwoju.

Inną kwestią jest to, że może istnieć wiele warstw komunikacji między specyfikacją a wdrożeniem. Może to prowadzić do efektu chińskich szeptów na końcowym urządzeniu. Najlepiej, jeśli ktokolwiek zdefiniował wymaganie lub raport o błędzie, sprawdza, czy działa tak, jak chciał.

Jako programista jesteś odpowiedzialny za swój własny kod, powinieneś go przetestować. Does the feature work as expected?Jeśli odpowiedź brzmi tak, to koniec.

Dlaczego nie powinieneś robić przypadków testowych?

1. Jesteś subiektywny , ponieważ znalezione błędy są pisane przez ciebie (lub twoich kolegów).
2. Jesteś zbyt drogi, aby firma mogła przeprowadzać testy przypadków. (Mam nadzieję).

Zazwyczaj programiści nie będą w większości przypadków tymi, którzy używają kodu, z wyjątkiem niektórych specjalnych przypadków. Tak więc ostatnim krokiem testowania przed awansem do systemu produkcyjnego powinno być testowanie akceptacji użytkownika, UAT. Zasadniczo są [lepiej] zaznajomieni z tym, czego oczekują od pakietu. I generalnie są bardziej zdolni do niszczenia rzeczy przy przepływach wejściowych nieznanych komuś, kto nie używa ich na co dzień.

Czy twoje plany projektowe nie uwzględniają testów użytkowników? Jeśli zmusisz użytkowników do przetestowania tego, możesz złapać błędy wcześniej niż po implementacji, co w moim świecie nie jest niczym złym.

Programiści nie powinni testować własnego kodu, ponieważ jest to podobne do oceniania sztuki własnego dziecka. Tak czy inaczej będzie dla ciebie pięknie i naprawdę potrzebujesz profesjonalisty, aby wskazać wady. Z drugiej strony testy jednostkowe są podobne do upewnienia się, że twoje dziecko nie próbuje malować ołowiem.

Jeśli NAPRAWDĘ nie chcesz zatrudniać QA, poproś programistów o napisanie kodu testowego dla innych programistów. To dobry pierwszy krok - wkrótce zobaczysz programistów proszących o zasoby związane z kontrolą jakości, ponieważ większość czasu spędzają na testowaniu kodu innych pod kątem problemów, oprócz CR.

Nie tylko programiści chronią swój kod, jeśli nie zdają sobie sprawy z konkretnego przypadku lub źle interpretują specyfikację w sposobie, w jaki coś rozwijają, to pominą te przypadki podczas testowania swojego kodu.

Techniki i umiejętności testowania są bardzo różne.

Większość testów przeprowadzanych przez zespół testowy jest funkcjonalna (to, że produkt działa zgodnie ze specyfikacją) i czarna skrzynka (zespół testowy nie zobaczy wewnętrznego działania aplikacji). Testerzy funkcjonalni nie muszą się martwić o to, jak rzeczy działają, muszą jedynie skupić się na tym, czy tak się dzieje.

Z mojego doświadczenia, przynajmniej w mojej małej organizacji, użytkownik końcowy musi przetestować. Niemal każdy projekt, który otrzymujemy, nie zapewnia wszystkich potrzebnych informacji i zawsze pomija pewne szczegóły. Deweloper jest zawsze w niekorzystnej sytuacji testowej, ponieważ nie wie, jak wykonać zadanie użytkownika, więc chociaż wie, że oprogramowanie działa zgodnie z informacjami, które otrzymał, nie wie, czy to pomoże użytkownikowi końcowemu wykonują swoją pracę.

Programiści źle odczytują i błędnie interpretują wymagania, a osoby odpowiedzialne za wymagania często nie określają kluczowych rzeczy. Jeśli nikt poza testami programistów, nikt nie znajdzie tych rozłączeń przed uruchomieniem. Gdy programiści testują, wiedzą zbyt wiele o tym, jak to ma działać i nie próbują głupich rzeczy, które użytkownicy mogą wypróbować. Deweloperzy piszą także testy na podstawie własnej interpretacji wymagań, co zbyt często nie jest tym, co naprawdę miało na myśli. Testy zaliczają się, ale wymaganie nie zostało spełnione. Kiedy przeprowadzasz testy innej osoby, może ona mieć odmienne wyobrażenie o wymaganiach i często znajdujesz miejsca, w których wymaganie zostało źle wyrażone przez to, jak odmiennie interpretują je dwie różne osoby. O wiele lepiej dowiedzieć się tego podczas testowania niż po uruchomieniu.

Deweloper powinien wykonać wstępne testy, abyśmy wiedzieli, że kodowany przez nas kawałek będzie działał tak, jak powinien, zgodnie z naszymi wymaganiami. Więc wykonujemy normalne testy, a także piszemy testy jednostkowe dla napisanego przez nas kodu.

Następnym krokiem jest zadanie kontroli jakości, aby dowiedzieć się, czego programiści nie widzą, gdy piszemy kod. Deweloper myśli na wyższym poziomie, ale użytkownik może nie myśleć na tym samym poziomie. Gdy programista testuje swój utwór i musi wpisać jakiś tekst w polu tekstowym, zawsze może wprowadzić pełny ciąg znaków, myśląc, że zrobiłby to również użytkownik. Może i użytkownik może to zrobić, ale losowo, gdy wpisze w tekście znak specjalny, taki jak% & $ ^, który łamie aplikację, nie wygląda dobrze dla użytkownika końcowego. Deweloper nie może i nie będzie myśleć o wszystkich możliwościach, które mogą się wydarzyć, ponieważ nie jest wyszkolony do takiego myślenia. Jeśli chodzi o kontrolę jakości (tester), zawsze myślą o tym, co użytkownik może zrobić, aby złamać tę aplikację i wypróbować każdą głupią rzecz z książki, nie użytkownicy są głupi, ale nie powinniśmy pozostawiać nic przypadkowi.

Teraz musimy również zrozumieć, że na ogół wykonanych jest więcej niż jeden kawałek w tym samym czasie i oba będą przeznaczone do produkcji. Deweloper mógł przetestować tylko swój kawałek i pomyśleć, że działa dobrze, ale należy przeprowadzić ogólne testowanie regresji dla wszystkich elementów, które są wypychane, a także dowiedzieć się, że połączenie dwóch różnych elementów może zepsuć aplikację i robi to też nie wygląda dobrze. Musimy również wziąć pod uwagę scenariusze testowania obciążenia i inne rzeczy, z którymi testerzy są bardziej zaznajomieni.

Wreszcie musimy przejść przez UAT (test akceptacji użytkownika), aby zobaczyć, czy zrobiliśmy to, czego się spodziewaliśmy. Ogólnie rzecz biorąc, chociaż wymagania przechodzą przez BA, osoba końcowa może nie wiedzieć dokładnie, jak to wygląda i może pomyśleć, że to nie jest to, czego się spodziewali lub może chcieć dodać coś innego, aby poprawić wygląd lub z jakiegoś powodu mogą zeskrobać cały kawałek, ponieważ uważają, że kawałek nie byłby zgodny z dostępną już funkcjonalnością.

Jak wyjaśniono powyżej, są one bardzo ważne i nie mogą być wykonane przez samego programistę i są absolutnie potrzebne, aby aplikacja działała poprawnie. Kierownictwo może powiedzieć, że jest to podejście konserwatywne, ale jest to lepsze podejście. Możemy wprowadzić kilka drobnych poprawek do powyższego, ale nie możemy tego uniknąć w całości.

Powyższe komentarze podnoszą świetne punkty.

Dodatkowym, wcześniej nie wymienionym, jest fakt, że oddzielny indywidualny kod testowy działa jako dodatkowa kontrola wymagań i czy system poprawnie je implementuje.

Wymagania i dokumentacja nie są doskonałe, a często implementacja jest wynikiem interpretacji wymagań przez programistę.

Gdy testy przeprowadzane są przez oddzielną osobę, zapewniają one również własną interpretację wymagań podczas tworzenia planu testów i wykonywania testów.

Gdy działania testowe są wykonywane niezależnie od działań programistycznych, a wyniki obu „zgadzają się”, stanowi to dodatkowe potwierdzenie, że system jest poprawny i naprawdę odpowiada pierwotnej intencji wymagań.

Podczas testowania programista zobaczy pole tekstowe z etykietą „Ilość” i wpisz „1”. Doświadczony programista przeprowadzi następnie test kontrolny o wartości „2”.

Użytkownik zobaczy pole tekstowe z etykietą „Ilość” i wpisz „~~ jednorożce ROX !!! ~~”. Doświadczony użytkownik spróbuje również „-12 1/2”.

Mamy nadzieję, że tester będzie tam gdzieś, by ostrzec programistę o tym, czego doświadczy użytkownik, gdy zrobi te rzeczy.

Jednym z powodów jest to, że programiści są zbyt blisko własnego kodu. Wiedzą, że to dziwactwa, to trochę dziwne zachowania. Mają tendencję do testowania wokół tych drobiazgów, które tak dobrze znają. Nie są wystarczająco obiektywni. Zespoły testowe traktują to jak czarną skrzynkę. Piszą macierze dziesiątek lub setek przypadków testowych i metodycznie je przeglądają, aby zobaczyć, co zrobi kod. Często wymyślają scenariusze, o których zespół programistów nigdy by nie marzył.

Innym powodem jest czas. W przypadku dużych projektów, które są budowane etapami, zespół programistów zbuduje Etap 1. Następnie testerzy przetestują go podczas budowy Etapu 2 i zostaną usunięte wady Etapu 1. Dzieje się tak na wszystkich etapach, więc testowany etap jest poprzednim, który został zbudowany.

Chcę zebrać kilka argumentów, dlaczego pozwolenie programistom na przetestowanie własnej pracy jako ostatniego kroku przed wprowadzeniem testu do produkcji jest złym pomysłem, ponieważ niestety moje miejsce pracy czasami to robi (ostatnim razem, gdy to się pojawiało , spór sprowadzał się do tego, że większość ludzi była zbyt zajęta innymi rzeczami i nie miała czasu na zapoznanie się z tą częścią programu przez inną osobę - jest to bardzo specjalistyczne oprogramowanie).

Testy nie są opcjonalne dla programisty. Deweloper musi przetestować napisany przez siebie kod. Jak inaczej może być pewien, że zadanie zostało wykonane pomyślnie? Musisz albo napisać jakieś testy automatyzacji (unittests), albo wykonać zadanie sprawdzania, czy „maszyna robi to, co chcę” manuall (używając GUI, wywołując polecenie z wiersza poleceń lub cokolwiek innego).

Wszystko, co jest następnie testowane, to „tylko” dodatkowe testy przeprowadzane przez innych ludzi (współpracowników, QA, ...). Nie ma alternatywy dla bezpośredniego testowania przez programistę. Każdy, kto mówi mi, że programista nie musi testować (lub nawet nie wolno mu) kodu / funkcji, którą napisał, po prostu nie rozumie, jak rozwija się oprogramowanie.

Jest testowany przez kogoś, kto nie zna kodu, czy ci się to podoba, czy nie. Pytanie brzmi, czy chcesz, aby ktoś był Twoim klientem.

Świetne pytanie. W twojej sytuacji istnieją przypadki testowe - czasami - a oprogramowanie wydaje się być na tyle skomplikowane, że przyspieszenie nowicjatu na produkcie nie jest praktyczne. Mówisz również, że przeprowadzony test jest testem końcowym przed produkcją

Powody, dla których deweloper może wykonać test końcowy

• Wystarczająco dużo innych testów ... Istnieją testy jednostkowe, istnieje środowisko testów integracyjnych i jest ono używane, przeprowadzono testy interfejsu użytkownika, testy eksploracyjne itp. Itd. Następnie test końcowy jest mniej rygorystycznym kryterium akceptacji niż ostateczny „ przebiec"
• Istnieje zestaw przypadków testowych napisanych przez profesjonalnego SQA / Testera, które ktoś (programista) może / musi jawnie przestrzegać
• Ryzyko awarii funkcji / produktu / modułu zostało w inny sposób ograniczone do niskich poziomów (pozwól profesjonalistom przetestować obszary wysokiego ryzyka, a „nowicjusz” przetestować niższe ryzyko)
• W rzeczywistości sytuacja biznesowa polega na tym, że wypuszczenie produktu z potencjalnymi wadami jest lepsze niż opóźnienie wydania
• Deweloper, o którym mowa, jest w rzeczywistości również bardzo wykwalifikowanym testerem i jest w stanie dokonać mentalnej zmiany ról
• Zmiana to poprawka błędu wprowadzona w terenie przez programistę, gdy witryna klienta jest zamykana lub w inny sposób traci przychody z powodu offline systemu (łata, która zostanie przywrócona do biura i przetestowana / wydana w kontrolowanej wersji JAK NAJSZYBCIEJ) )

Powody, dla których programista nie powinien przeprowadzać testów

• Coś jeszcze

Zasadniczo wydaje się, że jesteś na właściwej drodze do zaatakowania prawdziwego rozwiązania - Poproś eksperta SQA o wygenerowanie przypadków testowych ...

Uwaga: generalnie popieram pozwolenie Deweloperom na testowanie, ale do cholery upewniam się, że istnieje pierwszy punkt ...

Ludzie, będąc ludźmi, często cierpią na uprzedzenia poznawcze - w których ich ocena w dwóch prawie identycznych scenariuszach będzie się różnić, po prostu z powodu kilku rzeczy, które się zmieniły - jedną z rzeczy, które zauważyłem w ciągu 8 lat rozwoju, jest to, że deweloper ma do czynienia z testowaniem własnego kodu, w przeciwieństwie do kodu napisanego przez kolegę, testy przeprowadzone na jego własnym kodzie są znacznie gorszej jakości.

Nie oznacza to, że deweloper ponosi bezpośrednią winę - jego mózg użyje uprzedzeń, które napisali, aby wzmocnić fakt, że uważają, że ma rację, i wykona tylko podstawowe kontrole, w przeciwieństwie do programisty, który patrzy na kod innej osoby, przeprowadzi wiele dokładniejszych kontroli.

Istnieją tysiące przykładów, w których wprowadzono procedurę zapobiegającą uprzedzeniom poznawczym lub powszechnie znaną jako „czynnik ludzki”, na przykład systemy komputerowe w kontroli ruchu lotniczego, aby zapobiec sytuacji, w której dwa różne samoloty zajmowałyby tę samą przestrzeń powietrzną jednocześnie czas na wprowadzone procedury medyczne, więc więcej niż jeden lekarz musi postawić diagnozę.

Najwyższy czas, aby branża IT podążyła w kierunku bardziej profesjonalnego podejścia i wdrożyła procedury zapobiegające testowaniu własnego kodu.

• Każdy powinien przetestować - kod testowy Develpers, funkcjonalność testu QA'erów, marketingowy komunikat testowy. W ten sposób wszyscy podzielają tę samą filozofię i język testowania, co stanowi połowę sukcesu.

• Testowanie to rutynowa konserwacja i zwykle używam analogii do porównania . Na przykład analogia wymiany oleju samochodowego. Nigdy nie musisz „wymieniać” oleju. Ale i tak robisz to regularnie. To samo dotyczy mycia zębów. Jest powód, dla którego utrzymujesz je codziennie - nie zamierzają przełamać „dzisiaj”, chodzi o jutro i przyszłe dni oraz o dokonanie inwestycji.

• Każdy powinien wziąć na siebie odpowiedzialność za testowanie. Zespół ds. Kontroli jakości jest ważny, jednak „testowanie” jest czymś, co robi tylko zespół ds. Kontroli jakości, co sprawia, że ​​jest to „osobne” działanie, które nie jest zintegrowane z rozwojem produktu i przepływem pracy, co nie jest dobrą rzeczą.

• Kiedy coś się zepsuje w produkcji, wykonaj dwie rzeczy:

  1. Powiedz „hmm, mamy na to test ” jako pierwszy komentarz.
  2. Dokonaj wszelkich poprawek, uwzględniając testy problemu , najpierw do odtworzenia, niż poprawki.

W mojej firmie tworzymy dość złożone aplikacje finansowe. Zgodnie z naszą ogólną polityką programista powinien upewnić się, że nie wystąpią żadne błędy techniczne. Zasadniczo wypróbuj wszystko, co możesz, aby go złamać, biorąc pod uwagę zasoby użytkownika. Jeśli nie możesz znaleźć błędu środowiska uruchomieniowego, wyślij go do licencjobiorców w celu przetestowania. Mieliśmy kilku programistów, którzy zagubili się w testowaniu wymagań biznesowych do tego stopnia, że ​​wypalili się, ale tylko dlatego, że za wszystkie te testy nie odpowiadali. O ile nie ma wyraźnego błędu, który jest wyraźnie widoczny, wysyłamy go dalej do osób, które otrzymują wynagrodzenie, aby zrozumieć wynik. Ponadto użytkownicy powinni odgrywać prawdziwą rolę w sprawdzaniu wyników. Sprzedawca w sklepie detalicznym nie przymierza dla ciebie ubrań, a jedynie pomaga ci w „szczegółach technicznych”, takich jak znalezienie ubrań o odpowiednim rozmiarze.

Jednym z problemów jest to, że programiści nie mają wystarczającej motywacji do łamania własnego kodu - niewiele osób jest skłonnych szukać błędów we własnych pracach lub jest skłonnych do popełniania błędów. Posiadanie osobnego zespołu pomaga zapewnić, że wszystko się zepsuje.

Rola zapewniania jakości jest niezbędna, między innymi, aby ktoś mógł sprawdzić, czy programista zrozumiał wymagania. Deweloper nie może sam tego sprawdzić, ponieważ jeśli pomyśli, że źle zrozumiał, poprosi o wyjaśnienie.