Pozostawienie celowych błędów w kodzie dla testerów do znalezienia

267

Nie robimy tego w naszej firmie, ale jeden z moich przyjaciół mówi, że jego kierownik projektu poprosił każdego programistę o dodanie umyślnych błędów tuż przed przejściem produktu do kontroli jakości. Tak to działa:

  1. Tuż przed przejściem produktu do kontroli jakości zespół programistów dodaje umyślne błędy w przypadkowych miejscach w kodzie. Tworzą kopię zapasową oryginalnego, działającego kodu, aby mieć pewność, że błędy nie zostaną wysłane z produktem końcowym.
  2. Testerzy są również o tym informowani. Będą więc ciężko testować, ponieważ wiedzą, że obecne są błędy i że ich nie znalezienie może być uważane za przejaw niekompetencji.
  3. Jeśli zostanie znaleziony błąd (umyślny lub inny), zostanie zgłoszony do naprawy przez zespół programistów. Następnie zespół programistów dodaje kolejny celowy błąd w powiązanej sekcji kodu tuż przed przejściem produktu do kontroli jakości drugiego poziomu. Kierownik projektu mówi, że tester powinien myśleć jak programista i powinien spodziewać się nowych błędów w sekcjach, w których wprowadzono zmiany.

Tak to wygląda. Mówią, że takie podejście ma następujące zalety.

  1. Testerzy będą zawsze na nogach i będą testować jak szaleni. Pomaga im to także znaleźć ukryte (niezamierzone) błędy, aby programiści mogli je naprawić.
  2. Testerzy żywią się błędami. Nie znalezienie żadnych błędów wpłynie na ich morale. Łatwe do znalezienia pomoże im morale.

Jeśli zignorujesz scenariusz, w którym jeden z tych umyślnych błędów zostanie dostarczony z produktem końcowym, jakie inne wady należy wziąć pod uwagę, zanim pomyślisz o przyjęciu takiego podejścia?

Kilka wyjaśnień:

  1. Odpowiednio tworzą kopię zapasową oryginalnego kodu w kontroli źródła.
  2. Gdy tester znajdzie zamierzony błąd, zespół programistów po prostu go ignoruje. Jeśli tester wykryje niezamierzony (oryginalny) błąd, zespół programistów najpierw sprawdza, czy jest to spowodowane celowymi błędami. Oznacza to, że zespół programistów najpierw próbuje odtworzyć to na oryginalnym działającym kodzie i próbuje to naprawić, jeśli to możliwe.
  3. Po prostu zignoruj ​​problemy z relacjami między QA a zespołem programistów. Zadałem to pytanie konkretnie programistom , a nie miejscu pracy . Weź pod uwagę, że istnieje dobry stosunek między QA a zespołem programistów, którzy imprezują razem po godzinach pracy. Kierownik projektu to miły, stary dżentelmen, który jest zawsze gotowy wspierać oba zespoły (Godsend).
Krysznabhadra
źródło
59
„Test powinien myśleć jak programista” ... interesujący. Myślałem, że to oczywiste, że tester nie powinien myśleć jak programista, ale jak użytkownik.
Trilarion
12
Co się stanie, jeśli celowo wprowadzony błąd przykryje inny błąd, który testerzy mogliby znaleźć, gdyby ten umyślny błąd nie został wprowadzony? Załóżmy na przykład, że fragment kodu ma problem z płotem i że zespół programistów nie jest świadomy tego błędu. Programista decyduje się wstawić celowy błąd słupka ogrodzeniowego w tym miejscu. Teraz w kodzie występuje błąd podwójnego słupka ogrodzeniowego. Załóżmy, że testerzy wykryli błąd, ale nie widzą, że jest to błąd podwójnego słupka ogrodzeniowego. Gratulacje! Testerzy znaleźli wprowadzony błąd. Oryginalny kod zostanie przywrócony, aby zawierał oryginalny błąd słupka ogrodzeniowego. Ups!
David Hammen
20
Jestem QE. Wolę znaleźć prawdziwe błędy, dziękuję. Zrezygnowałbym z tej firmy, jakby się paliła. Nikt (umyślnie) nie zmarnuje mojego czasu.
ArjunShankar
7
„Nie robimy tego w naszej firmie, ale jeden z moich przyjaciół mówi, że jego CTO poprosił każdego menedżera produktu o dodanie dodatkowych funkcji na początku każdego cyklu rozwoju funkcji ...”
Marco
3
Podejrzewam, że dodanie celowych błędów stwarza ryzyko. Co się stanie, jeśli celowy błąd naprawi coś niezamierzonego? Pozytywny efekt uboczny nie jest zgłaszany, kod jest usuwany, a prawdziwy błąd przechodzi przez kontrolę jakości. Z natury te „umyślne błędy” z ostatniej chwili będą źle brane pod uwagę, jeśli nie, błędy marnują zbyt dużo czasu programisty.
Jodrell

Odpowiedzi:

462

Brzmi to absolutnie szalone. Poświęca wiele wysiłku, aby uzyskać bardzo wątpliwe korzyści, a praktyka wydaje się opierać na pewnych błędnych przesłankach:

  • Kontrola jakości nie będzie ciężka, chyba że będzie wiedziała, że ​​są codziennie testowane (co nie może być dobre dla morale)

  • Że w oprogramowaniu nie ma wystarczającej liczby niezamierzonych błędów, które można by znaleźć

  • Zadaniem QA jest znajdowanie błędów - nie jest; ma na celu zapewnienie jakości oprogramowania

  • To, że tego rodzaju bitwa rozumu między rozwojem a kontrolą jakości jest w pewnym sensie zdrowa dla firmy - nie jest; wszyscy pracownicy powinni współpracować przeciwko konkurentom firmy zamiast siebie nawzajem.

To okropny pomysł, a kierownik projektu, o którym mowa, jest palantem / idiotą, który nie rozumie ludzi i motywacji. I to jest złe dla biznesu.


Aby rozwinąć mój opis „zadania kontroli jakości”: Kontrola jakości zdecydowanie powinna znajdować błędy - zarówno w kodzie, jak i w ich zestawach testowych - jako artefakt wykonywania swoich zadań, ale roli nie należy definiować jako „musisz znaleźć robaki." Powinno być „musisz aktualizować pakiety testowe, aby uwzględniać nowe funkcje i zapewnić pełne pokrycie testów. Jeśli nie spowoduje to znalezienia błędów, wówczas procedury testowe nie są wystarczająco wyrafinowane dla produktu.

James McLeod
źródło
17
Zadaniem QA jest znajdowanie błędów - nie jest; ma na celu zapewnienie jakości oprogramowania. To wymaga pewnych wyjaśnień. Wyizolowanie i naprawienie błędu jest jednym z ważnych procesów w oprogramowaniu do wysyłania wysokiej jakości.
Krishnabhadra
21
W rzeczywistości w wielu firmach zadaniem QA jest znajdowanie błędów, a jeśli do produktu dodano nowe funkcje, a QA właśnie wtedy uruchamia pakiet testowy, który nie pokazuje żadnych błędów, osobiście nie ufam temu pakietowi testowemu i przypuszczam, że jest niekompletny.
Doc Brown
8
Zgadzam się, z wyjątkiem ostatniego punktu. Posiadanie przeciwnego podejścia między kontrolą jakości a rozwojem (i biznesem) jest w dużej mierze nieuniknione. Każda grupa ma własne pragnienia i wiedzę. Jako firma muszą się one równoważyć, aby dobrze działać. Z mojego doświadczenia wynika, że ​​„dobre granie” prowadzi po prostu do tego, że grupy nie dążą do realizacji swoich planów, co prowadzi do stagnacji lub braku równowagi. Najlepsze firmy, jakie widziałem, to takie, w których rozwój, kontrola jakości i strona biznesowa dążą do zaspokojenia swoich potrzeb, ale działają jak inne firmy, co prowadzi do kompromisu w zakresie najlepszej równowagi dla firmy.
Telastyn
42
Dodałbym jeszcze jedną kwestię: celowy błąd mógł ukryć prawdziwy błąd, który pojawiłby się, gdyby celowy błąd nie zatrzymał procesu (na przykład poprzez zgłoszenie wyjątku).
nkoniishvt
30
Gdybym był facetem od kontroli jakości i dowiedziałem się, że marnuję czas na szukanie i dokumentowanie celowo wprowadzonych błędów typu bzdury, znajdę nową pracę.
Kik
209

Na podstawie tego, czego się nauczyłem:

  1. To nie jest rozmowa szkolna ani praca;
  2. Testerzy nie są dziećmi;
  3. To nie jest gra;
  4. Marnuje pieniądze firmy.

Kontrola jakości służy nie tylko do znajdowania błędów, ale także do martwienia się o intuicyjność systemu, jaką krzywą uczenia się ma użytkownik, użyteczność i ogólnie dostępność . Na przykład: „Czy system jest brzydki ?”, „Czy kolor użytkownika jest ślepy, a rzeczy są czerwone i zielone?” Oni też powinni narzekać.

Minimalne wymagania, aby system mógł przejść kontrolę jakości, są zwykle opisane w historii użytkownika dla tej konkretnej funkcji lub w tym, jak magicznie organizacja producentów chciała, aby system był w jego głowie.

tl; dr

To nie tylko błędy, testerzy powinni wyrosnąć z tego wąskiego widoku.

Iskra
źródło
26
+1 Zdecydowanie zgadzam się ze wszystkimi 4 punktami, zwłaszcza pierwszym. Podejście konkurencyjne, które przynosi tak wielu nowszych twórców, często odzwierciedla ich poprzednie 15 lat nauki - niezwykle konkurencyjne środowisko - w przeciwieństwie do miejsca pracy, w którym współpraca byłaby lepszym podejściem.
Michael Durrant
1
Zdecydowanie wolę tę odpowiedź od najwyższej.
Pharap
1
„Kontrola jakości służy nie tylko do znajdowania błędów, ale także [...]” - chcę tylko powiedzieć, że w wielu miejscach terminy testowanie oprogramowania i zapewnianie jakości są używane zamiennie. Tak, to źle. Tam, gdzie kiedyś pracowałem, mieliśmy pracownika, który wykorzystywał stan - na każdym spotkaniu działu jakości - tym, co tu robimy, nie jest zapewnienie jakości, ale kontrola jakości. (Miała to na myśli krytykę naszego działu kontroli jakości.)
Mario,
1. To jest szkoła. Każdy dzień jest dniem szkolnym. Jeśli pracujesz w dyscyplinie inżynierskiej, ale nie chcesz się uczyć każdego dnia, powinieneś wyjść z mojego biura. To także wywiad. Wydajność należy mierzyć każdego dnia, aby mieć pewność, że dział zyskuje na wartości. 2. Jeśli moja kariera mnie czegoś nauczyła, to QA ma zdolności umysłowe 14-latków. Są dziećmi i powinny być zarządzane jak stado owiec.
Gusdor,
1. Nie jest to szkoła w tym sensie, że ludzie mogą współpracować i nie konkurować ze sobą o oceny, nie ma czegoś takiego jak kopiowanie pracy, ponieważ zadania muszą zostać wykonane tylko raz i nie jest wstydem prosić o pomoc kolegę. I 2. Jeśli twoja kontrola jakości jest tak zła, twój problem dotyczy HR, i to oni powinni wyjść z biura.
SparK
100

Zły pomysł.

Z punktu widzenia testera: „Więc będą ciężko testować, ponieważ wiedzą, że obecne są błędy i ich nie znalezienie może być uznane za ich niekompetencję”. Zasadniczo deweloperzy łapią kod w pułapkę. Niewiele osób lubi wykonywać pracę, która jest ostatecznie bezcelowa (ponieważ błędy są znane z góry), ale która nadal wpływa na to, jak są postrzegani. Jeśli istnieją wymierne kary za nie znalezienie pułapek-min, tym bardziej. A czy wiesz, że testerzy rozwijają się w poszukiwaniu błędów? To brzmi jak toksyczne środowisko konfrontacyjne; kontrola jakości powinna być szczęśliwa, jeśli sprawdzany kod jest wysokiej jakości. Chociaż jeśli zostaną opłacone przez błąd ... http://thedailywtf.com/articles/The-Defect-Black-Market

Z punktu widzenia dewelopera: QA są zachęcani do znajdowania błędów, o których wiesz, że tam są. Może to zwiększyć prawdopodobieństwo wystąpienia prawdziwych błędów przez drzwi; QA spędzają przynajmniej część swojego czasu na poszukiwaniu rodzaju błędu, który jest łatwy do posadzenia, a nie bardzo subtelny. Ponadto istnieje niewielka szansa, że ​​pułapka może wydostać się z drzwi.

Julia Hayward
źródło
32
Jeśli płacą za błąd, to
BЈовић
12
„zachęcony do znalezienia błędów, o których wiesz, że tam są” Znakomity punkt. Jeśli organizacja to robi, prawdopodobnie oznacza to, że ktoś oddycha przez szyjki QA, aby upewnić się, że znajdzie posadzone błędy, więc będzie to ich najwyższy priorytet. Co jeśli się spotkają i stwierdzą, powiedzą: „Hej, zasadzone błędy prawie zawsze powodują, że nie można zapisać jednego pola na ekranie edycji z dużą ilością danych” (lub cokolwiek innego). Następnie spędzą nadmierną ilość czasu na poszukiwaniu jednego rodzaju błędu i zwiększą szansę, że przegapią inne rodzaje błędów.
Jay
Pierwszą rzeczą, jaka przyszła mi do głowy, było to, że Wally po południu
zakoduje
10
> prawdziwe błędy wychodzące z drzwi. Robiłem duże testy. Zaczynasz od tezy, że (nietrywialny) kod zawsze zawiera błędy. QA to bohaterowie, którzy znajdują ich zanim zrobi to klient. Błędy są zawsze dostępne. Jeśli wprowadzasz sztuczne błędy, marnujesz czas, możesz spędzać na poszukiwaniu prawdziwych błędów; czas na testowanie jest ograniczony, obniżasz jakość dodając niepotrzebną pracę.
RedSonja,
58

Całkowicie zgadzam się z powyższymi odpowiedziami, dlaczego jest to niekorzystne dla motywacji i ogólnie okropnego zarządzania ludźmi. Prawdopodobnie istnieją jednak uzasadnione przyczyny techniczne, aby tego nie robić:

Tuż przed przejściem produktu do kontroli jakości zespół programistów dodaje umyślne błędy w przypadkowych miejscach w kodzie. Tworzą kopię zapasową oryginalnego, działającego kodu, aby mieć pewność, że błędy nie zostaną wysłane z produktem końcowym.

  1. Na podstawie pierwszego stwierdzenia nigdy nie testujesz zamierzonego kodu produkcyjnego w tych dwóch przejściach.

  2. Wyobrażam sobie, że znacznie zwiększasz prawdopodobieństwo przypadkowego włączenia „umyślnego” błędu do uwolnionego kodu produkcyjnego, gdy próbujesz przyspieszyć zmianę dla klienta. W pewnym momencie może powodować kilka czerwonych policzków.

  3. Wyobrażam sobie, że to po prostu uczy twoich testerów, aby myśleli tak, jak twoi programiści (tj. W jaki sposób Tom dodałby tutaj błąd), co prawdopodobnie zmniejsza prawdopodobieństwo znalezienia błędów, o których Tom nie pomyślał.

Paddy
źródło
43
+1, ponieważ nigdy nie testujesz zamierzonego kodu produkcyjnego w tych dwóch przejściach. Jak możesz nawet pomyśleć o wydaniu bez testowania kodu produkcyjnego, jest poza mną; jeśli ponownie testujesz bez zamierzonych błędów, to powtarzasz wysiłek i marnujesz wysiłek początkowy.
adamdc78
51

Edytować

Chcę jasno powiedzieć, że ta odpowiedź dotyczy tylko koncepcji testowania procesu kontroli jakości i nie bronię konkretnej metodologii przedstawionej w pytaniu.

Zakończ edycję

Istnieje uzasadniony powód, aby sprawdzić, czy Twoje testy / sprawdzanie rzeczywiście działa. Dam ci przykład z produkcji, ale zasada jest taka sama.

Jest to typowe podczas podawania materiału przez maszynę, że podajnik może nie przepchnąć materiału wystarczająco daleko. Nazywa się to „krótkim podawaniem” i aby temu zapobiec, możemy zainstalować „czujnik krótkiego podawania” (zwykle czujnik typu wiązki światła, który jest blokowany przez materiał). Ten czujnik wykrywa koniec materiału, gdy osiągnie pełną długość podawania. W pewnym momencie cyklu maszyny sprawdzamy, czy czujnik jest zablokowany i zatrzymujemy maszynę, jeśli kontrola się nie powiedzie.

Teraz musisz pomyśleć o tym, jak sam test może się nie powieść. Na przykład niektóre zabrudzenia lub inne zanieczyszczenia mogą zablokować czujnik i zawsze zgłasza „OK” i nigdy nie zatrzymuje maszyny. Charakter czujnika polega również na tym, że odbiornik włącza się, gdy wiązka uderza w niego, więc w zależności od rodzaju zainstalowanego czujnika, elektrycznie dostajesz wejście „ON”, gdy czujnik nie jest zablokowany . Oznacza to, że w przypadku odcięcia kabla lub utraty zasilania tego czujnika lub awarii wejścia, logika twojego programu brzmiałaby „OFF”, a to oznaczałoby „zablokowany” lub „OK”.

Aby wyłapać te tryby awarii testu, zwykle wstawiamy drugie sprawdzenie, aby upewnić się, że czujnik jest faktycznie odblokowany podczas drugiej części cyklu. W ten sposób sprawdzamy, czy test nadal działa (najlepiej jak potrafimy).

Podobnie istnieje wiele przyczyn niepowodzenia działania działu kontroli jakości. Być może testy automatyczne nie zostały uruchomione, a raport analizuje starą kopię danych testowych. Być może ktoś źle wykonuje swoją pracę. Testowanie działu kontroli jakości jest rozsądne.

Oczywiście wadą jest to, że „błąd testowy” może przedostać się przez dział kontroli jakości do gotowego produktu. W branży produkcyjnej zdarzają się przypadki, w których znana część zła, zwana czasem „czerwonym królikiem”, jest wkładana do procesu (zwykle przez kogoś z kontroli jakości) i obserwują, jak ta część przechodzi przez proces i mierzy, ile czasu zajmuje znajdź część i usuń ją. Zwykle ta część jest pomalowana na jaskrawo czerwony (lub pomarańczowy), więc można ją łatwo śledzić. Ponieważ ktoś patrzy, jak część przechodzi proces podczas tego testu, szansa na przejście do produktu końcowego jest praktycznie zerowa. Są oczywiście apokryficzne historie o tym, że ktoś wrzuca znaną złą część procesu, aby „sprawdzić, czy system może go znaleźć”,

Scott Whitlock
źródło
1
Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .
yannis
Witam wszystkich. Dyskusja była zbyt długa na komentarze. Jak widać z mojego wcześniejszego (automatycznego) komentarza, wszystkie komentarze przeniosłem do dedykowanego pokoju rozmów . Jeśli chcesz kontynuować omawianie odpowiedzi, zrób to w tym pokoju rozmów, a nie tutaj. Dzięki.
yannis
3
Tak opisane podejście może być stosowane do testowania kontroli jakości od czasu do czasu , a nie jako proces ciągły.
gerlos
30

Szczerze, nazwałbym to zachowanie rażąco nieetycznym i niepraktycznym. PM potrzebuje poważnego przekwalifikowania, jeśli nie zakończenia.

  • Wskazuje na zasadniczy brak zrozumienia pojęcia zapewnienia jakości . Testerzy nie powinni myśleć jak programiści: powinni myśleć jak użytkownicy końcowi. Cały powód posiadania zespołów ds. Kontroli jakości polega na tym, że programiści są z natury zbyt blisko kodu; Kontrola jakości powinna utrzymywać wystarczającą odległość od kodu, aby mogły uchwycić to, czego brakuje twórcom.
  • Marnuje wysiłek zapewnienia jakości . Zakładając, że te błędy nie są trywialne - patrz poniżej, kiedy są - oznacza to, że QA spędza czas i zasoby badając rzeczy, które już są znane, kiedy mogą poświęcać ten wysiłek na szukanie tego, co nie jest znane.
  • Marnuje wysiłek programisty . Aby ludzie z QA wyłapali te nietrywialne błędy, programiści muszą je najpierw napisać. Wymaga to dalszych wysiłków, poświęconych nie tylko na kodowanie błędów, ale także na uwzględnienie wymagań i projektu oprogramowania.
  • Naraża to produkcję na niepotrzebne ryzyko . To tylko kwestia czasu, zanim zmiany nie zostaną poprawnie scalone.
  • Jeśli nie robi powyższego, jest to bezcelowe . Jeśli wszystkie znane błędy są trywialne, nie złapią pracowników niespełniających norm: złapią tylko osoby, które w ogóle nie wykonują żadnej pracy. Są na to lepsze sposoby.
  • Zatruwa środowisko pracy . Twoi testerzy QA są profesjonalistami. Należy im ufać, że profesjonalistami, dopóki nie ma rzeczywistego powodu, aby podejrzewać inaczej. Gdy nie jest powód, aby podejrzewać, w przeciwnym razie, nie powinno być właściwe dochodzenie zamiast tych gier umysłowych. Wszystko inne zabija morale.

Poważnie. Nawet jeśli paranoja premiera okaże się uzasadniona w tym konkretnym przypadku, nie jest to ktoś, kto ma testerów zarządzających biznesem.

The Spooniest
źródło
28

Osobiście czuję się nieswojo przy takim podejściu.

Najważniejsze, co mnie niepokoi, to praktyczność wprowadzania zamierzonych błędów. Wydaje mi się, że jest to trudne do wykonania w jakikolwiek przewidywalny sposób.

Wszelkie zmiany kodu (celowe lub inne) mogą powodować skutki uboczne. Te skutki uboczne mogą być ujawnione podczas testowania, ale może nie być oczywiste (nawet dla dewelopera, który zasadził błąd), jaka jest podstawowa przyczyna. To nie wydaje się „bezpieczne”, jeśli wiesz, co mam na myśli (mówię tutaj z jelit).

Ponadto tester zmarnuje dużo czasu na testowanie kodu, który w rzeczywistości nie zostanie wydany. Moim zdaniem, po usunięciu zamierzonych błędów, i tak należy przeprowadzić pełny ponowny test. To jest cały punkt testowania. Coś się zmienia, cokolwiek , a ty wszystko testujesz ponownie . Ok, wiem, że to się nigdy nie zdarza w praktyce, ale o to właśnie chodzi w testach regresyjnych.

Ogólnie rzecz biorąc, nie przekonany.

Z drugiej strony, zwykle pozwalamy klientom weryfikować pracę zespołów ds. Kontroli jakości, co prawdopodobnie nie jest idealne. Jest to jednak bardzo potężna pętla sprzężenia zwrotnego.

Roger Rowland
źródło
1
Podoba mi się pomysł zasilania pętli sprzężenia zwrotnego!
jxramos
23

Jest to zły pomysł z wszystkich podanych już powodów, ale seedowanie błędów jest przydatnym narzędziem do innych celów. Możesz go użyć, aby uzyskać przybliżony pomiar skuteczności procesu zapewniania jakości.

W najprostszym przypadku, powiedzmy, że wysiewasz 100 błędów, a są one reprezentatywne dla pełnego zakresu prawdziwych błędów (wiem, mało prawdopodobne, ale upraszczam). Nie mów QA, że robisz to, aby uniknąć zepsucia eksperymentu. Pod koniec procesu kontroli jakości powiedzmy, że znaleźli 60 ze 100 zaszczepionych błędów (i inne prawdziwe błędy). Teraz wiesz, że QA znajduje 60% błędów.

Możesz rozszerzyć to dalej, licząc liczbę znalezionych prawdziwych błędów QA i zastosować współczynnik fałszywych błędów. W naszym przykładzie, jeśli QA wykryło 200 prawdziwych błędów, możesz stwierdzić, że znaleziono tylko 60% z nich, więc 133 pozostało.

Oczywiście jest to tylko szerokie oszacowanie z ogromnymi słupkami błędów. Pisanie realistycznych, reprezentatywnych błędów jest trudne. Błędy, które piszesz, mogą być łatwiejsze do znalezienia przez kontrolę jakości, ponieważ programiści są przeszkoleni, aby nie pisać błędów. Lepiej jest zasymulować klasę błędów, takich jak błędy off-by-one, błędy Unicode, przepełnienie bufora i tak dalej.

Powinno to dotyczyć całego procesu kontroli jakości , który obejmowałby testowanie jednostek programistów, ciągłą integrację oraz, jeśli to możliwe, dedykowany zespół kontroli jakości.

Jest to metryka i nie należy jej przejmować jako narzędzia motywującego do zarządzania.

Schwern
źródło
Byłby to jedyny sposób, w jaki można zebrać jakiekolwiek znaczące dane. Ale ilość czasu i wysiłku, które byłyby wymagane do ustalenia odpowiednich przypadków testowych, aby uzyskać znaczące wyniki, zniszczyłyby każdy budżet i harmonogram. A nawet jeśli dostaniesz budżet i harmonogram, będziesz musiał pokonać przeszkodę w zapewnieniu, że masz kwalifikacje do rozumienia statystyki i oprogramowania na tyle dobrze, aby móc zidentyfikować odpowiedni podzbiór testów. Nie sądzę, że dostaniesz to wszystko w jednym projekcie. Tak więc w prawdziwym życiu najlepszym sposobem, jaki może zrobić ta metoda, jest uzyskanie błędnych, jeśli nie wprowadzających w błąd liczb.
Dunk
1
Dobrze jest do tego wstrzykiwać SQL, ponieważ można po prostu losowo wybrać n instrukcji SQL, aby „złamać”
Ian
1
Dużym problemem jest to, że celowe błędy będą się bardzo różnić od problemów, które pojawią się naturalnie - możesz po prostu szkolić kontrolę jakości, aby myśleć jak programiści. To w zasadzie niszczy cały punkt kontroli jakości - mieć POV bliżej klienta niż kodu. Ogromna część kontroli jakości polega na sprawdzeniu rozsądku w stosunku do rzeczy, które twórcy myślą intuicyjnie (z powodu niewiedzy o ignorancji użytkowników lub bliskości kodu, czasu spędzanego z interfejsem użytkownika itp.). Celowe błędy nie są dobrze rozłożoną próbką.
Luaan
20

Zły pomysł.

Jest to rodzaj logicznego, binarnego podejścia, które programiści często wprowadzają, ale jest demotywujące dla QE. To po prostu pokazuje brak zaufania. Pytania i odpowiedzi często umieszczane są w takich sytuacjach bez większego wkładu i zakładano, że są w porządku, i nie jest to ich miejsce, aby sugerować inaczej.

Tego rodzaju myślenie łączy się z QE będącymi jedynie testerami ręcznymi i brakiem motywacji do zrozumienia rzeczywistego testowanego kodu.

Jestem starszym QE i jest to znany problem w większości organizacji, w których pracowałem.

Michael Durrant
źródło
7
Moja żona przeprowadzała kontrolę jakości przez 8 lat i właśnie wyjechała na studia - głównie z powodu takich problemów związanych z zaufaniem. To tylko obraża testera.
Bryan Boettcher
19

Powiedziałbym zły pomysł.

Po pierwsze: programiści poświęcą czas na zamieszczenie celowych błędów w kodzie i trochę wysiłku, aby zapisać dobrą wersję. Podczas gdy testerzy powinni prawdopodobnie testować wszystko, w tym funkcje z posadzonym błędem, kiedy go znajdą, prawdopodobnie będą musieli wrócić i ponownie uruchomić ten test, aby sprawdzić, czy to rzeczywiście był błąd (a nie, że tester się pomylił w pewnym sensie). Przynajmniej testerzy spędzą czas na pisaniu posadzonych błędów. Następnie programiści muszą poświęcić czas na naprawienie błędu, który zasadzili. Jest to duży wysiłek, który można by poświęcić próbując napisać dobry kod i napisać prawdziwe błędy.

Po drugie: wysyła do testerów jasny komunikat, że programiści i / lub kierownictwo uważają, że nie wykonują swoich zadań i muszą być traktowani jak dzieci. Nie mogę sobie wyobrazić, że to jest dobre dla morale. Jako programista, jeśli otrzymałem dwuznaczne lub sprzeczne specyfikacje programu i musiałem poświęcić sporo czasu na ich wyjaśnienie, a następnie po marnowaniu godzin lub dni mój szef powiedział mi: „Och, tak, celowo zamieściłem sprzeczne stwierdzenia w specyfikacje, aby upewnić się, że naprawdę je czytasz ”, myślę, że byłbym naprawdę zirytowany. Jeśli zdarza się to regularnie, to może wystarczyć, żebym szukał innej pracy.

W prawdziwym życiu wszystkie oprócz najbardziej trywialnych zmian kodu BĘDĄ mieć błędy. Nigdy nie miałem problemu z tym, że testerzy byli zadowoleni, ponieważ pierwszy szkic, który dostali, był tak często w 100% idealny. Miałem do czynienia z leniwymi testerami, którzy nie wykonują odpowiedniej pracy, ale nie dostali się w ten sposób, ponieważ programiści byli tacy doskonali. Najlepsza osoba testująca, z jaką kiedykolwiek współpracowałem, powiedziała mi, że w przypadku nowej wersji oprogramowania wyznaczył sobie osobisty cel znalezienia 100 błędów. Ok, czy 100 jest liczbą realistyczną, zależy od tego, jak duży jest produkt i jak daleko idą zmiany, ale w naszym przypadku prawie zawsze udało mu się osiągnąć ten cel. Czasami musiał rozciągać różne rzeczy, na przykład nazywał źle napisane słowo w komunikacie „błędem”, ale hej, to musiało zostać naprawione.

Post script: Jeśli to zrobisz, założę się, że prędzej czy później programiści zamierzają podłożyć błąd, testerzy nie znajdują tego konkretnego, a programiści zapominają o przywróceniu dobrego kodu. Więc teraz celowo posadzony błąd zostaje wysłany do klienta.

Sójka
źródło
Ten punkt dotyczący specyfikacji w „Two” jest doskonałą analogią.
Kyralessa
14

Naprawdę nie uważam tego za zły pomysł. Jest tylko wiele rzeczy, które według mnie lepiej działają:

  1. Spraw, aby kontrola jakości była odpowiedzialna za jakość w dowolny sposób. Na przykład poprzez wspieranie ich również odpowiedzialności. Zwiększy to ich motywację do zapewnienia wyższej jakości wysyłanych produktów. Zawsze potrzeba mniej wysiłku, aby samemu odkryć nieadekwatność (błąd, oczywiście brak funkcji, zachowanie sprzeczne z intuicją), a następnie spróbować zrozumieć, co próbuje wytłumaczyć zdenerwowany użytkownik. A powierzenie części tej odpowiedzialności nawet deweloperom może zwiększyć ich motywację, aby pomóc QA w wykonywaniu pracy najlepiej, jak potrafią.

  2. Posiadaj wiele zespołów zapewniania jakości, które mogą konkurować. Oczywiście musisz znaleźć rozsądną miarę. Zdecydowanie nie tylko liczba problemów. Pomocne może być uwzględnienie wagi wady lub wartości biznesowej (określonej przez interesariuszy) proponowanych ulepszeń.

Trudno powiedzieć, czy kontrola jakości jest „wystarczająco dobra”. Na dłuższą metę jest łatwiej, a może nawet lepiej, znaleźć sposoby na „poprawę” kontroli jakości.

Mimo to, należy pamiętać o jednym problemie, jeśli wprowadzasz umyślne błędy: skąd wiesz, że „poprawny” kod rzeczywiście był poprawny? Po drugiej kontroli jakości usuwasz wszystkie umyślne błędy, które nie zostały wykryte. Nie ma sposobu, aby wiedzieć, że albo nie zastępujesz ich tylko kodem, który jest uszkodzony w inny sposób, albo że nie włączasz niedziałającego zachowania, które wcześniej było nieosiągalne (przesadzony przykład: niektóre okna dialogowe nie otworzyły się z powodu celowego błędu, ale samo okno dialogowe jest zepsute - po prostu nie dowiadujesz się, ponieważ testerzy go nie widzieli).

back2dos
źródło
5
Gdybyście zostawili to pierwsze zdanie, dałbym wam +1, bo wszystko inne jest dobre :) To po prostu okropny pomysł, zły to mało powiedziane. Najłatwiejszym sposobem na rozliczenie kontroli jakości jest śledzenie liczby błędów, które sprawiają, że jest ona w terenie. Już samo to osiągnie WSZYSTKO, co proponowana metoda twierdzi, że jest jej zaletą.
Dunk
@Dunk: Śledzenie tej liczby nie poprawi automatycznie zespołu, podobnie jak utrzymywanie wyniku w sporcie nie czyni z ciebie najlepszego sportowca. W rzeczywistości sportowcy trenują , tj. Wykonują sztuczne zadania, aby zwiększyć swoje wyniki w kontrolowany sposób, co nie różni się od proponowanego tutaj. Jeśli nie masz pomysłu, jak zachęcić ludzi do poprawy tej liczby, ma ona niewielką wartość.
back2dos
Nie twierdzę, że to coś poprawi. Twierdzę tylko, że osiągnie wszystko, co osiągnie metoda „wstaw fałszywe błędy”, ale bez wszystkich kosztów i straconego czasu. Będzie to wskazywać, czy zbyt wiele wad przechodzi przez kontrolę jakości. Jeśli okaże się, że tak jest, wówczas proces lub ludzie muszą zostać poddani ponownej ocenie. Metoda „fałszywego błędu” nie dostarcza więcej informacji, ale w rzeczywistości dostarcza mniej przydatnych informacji. Tak więc Twoje koszty są wyższe przy mniejszym zysku dzięki metodzie „fałszywego błędu”. Tak jak powiedziałem, okropny pomysł.
Dunk
@Dunk Wtedy nie przeczytałeś poprawnie pytania. Sugeruje to, że ta metoda zwiększa morale, a także dokładność. Również liczba błędów, które przeszły przez kontrolę jakości, nie mierzy w wiarygodny sposób skuteczności zespołu kontroli jakości. Równie duży wpływ ma to, ile błędów wprowadzają programiści. Jeśli zaczną korzystać z TDD i nastąpi gwałtowny spadek defektów w wydaniu, co to mówi o testerach? Nic.
back2dos
@Dunk W przeciwieństwie do tego, „fałszywy błąd” faktycznie daje więcej informacji, przy założeniu, że trudność ich znalezienia nie waha się nieregularnie (co można ustawić). Ponieważ wiesz, ile jest sztucznych wad, możesz dokładnie powiedzieć , jaki procent z nich został złapany podczas kontroli jakości. Tak więc dodatkowe informacje, jakie otrzymujesz, to skuteczność QA w wykrywaniu sztucznych wad. Liczba ta z pewnością bardziej koreluje z ich ogólną skutecznością niż ta, którą zasugerowałeś.
back2dos
9

Jak powiedzieli inni, programiści nie powinni celowo dodawać błędów w oprogramowaniu, ale uzasadnioną strategią dla pakietu testowego jest dodawanie błędów w oprogramowaniu w ramach procesu testowania.

To się nazywa testowanie mutacji . Chodzi o wykorzystanie oprogramowania do automatyzacji tworzenia małych zmian w kodzie źródłowym (zwanych mutantami). Zmiany mają na celu stworzenie różnych zachowań, na przykład możemy zmienić

if x < 10:
    print "X is small!"

w

# we flipped the inequality operator
if x > 10:
    print "X is small!"

a dobry test jednostkowy powinien wykryć, że fragment kodu mutanta nie działa już zgodnie z oczekiwaniami i zabija mutanta . Kiedy oryginalny kod przejdzie test i wszystkie mutanty (które nie są funkcjonalnie równoważne) nie przejdą testu, wtedy wiesz, że twój kod i twoje testy są silne .

James Mishra
źródło
7

Podoba mi się ten pomysł. Czy to generał Patton powiedział: „Im bardziej pocisz się w pokoju, tym mniej krwawisz na wojnie”.

Umieszczanie celowych błędów „marnuje czas” testerów. Ale to także sprawia, że ​​pracują ciężej, co oznacza, że ​​lepiej wykonają wyszukiwanie niezamierzonych błędów. (I masz kopię „oryginału”, więc nie musisz żyć z tym, co zrobiłeś).

Znalezienie większej liczby niezamierzonych błędów prawdopodobnie pozwoli zaoszczędzić więcej żalu na dłuższą metę niż koszt radzenia sobie z celowymi.

Ponadto możesz dowiedzieć się, jak dobrzy są twoi testerzy, a nie sama w sobie niewielka korzyść.

Tom Au
źródło
1
Myślę, że są w tym dobre strony. Lepiej jest znaleźć błąd PRZED tym, że przenosi się na wolność, i wolałbym raczej naciskać na moją wewnętrzną kontrolę jakości (za co płacą, prawda?) Niż na reagowanie na ataki zewnętrzne. Polowanie na błędy jest częścią, i dopóki takie testy są przeprowadzane poprawnie, nie rozumiem, dlaczego nie może być cenną częścią.
WernerCD
1
Kopia „oryginału” może nie być wolna od błędów i również z definicji nie jest testowana (ponieważ kod został zmieniony w celu dodania błędów).
Roger Rowland
1
Z mojego doświadczenia wynika, że ​​robaki nie są odizolowanymi zwierzętami i nie siedzą same. Oprogramowanie jest częścią systemu, a błędy - celowe lub nie - wpływają na system . O ile oczywiście nie mówimy o trywialnych programach.
Roger Rowland
18
Nie ma żadnego dowodu, że ta metoda znalazłaby jeszcze 1 dodatkowy błąd poza celowo wstawionymi błędami. Nie ma żadnego dowodu na to, że utrudniłoby to kontrolę jakości w poszukiwaniu błędów. Mogą starać się mniej. Ponadto, ponieważ zmarnowałeś cały cykl testowania procedury akceptacji podczas testowania celowo uszkodzonego kodu (nasz pełny test trwa 3 tygodnie), musisz teraz ponownie przetestować rzeczywisty kod, który zostanie wdrożony, ponieważ uszkodzony wersja nie jest tą samą wersją, więc jej testy są prawie bezużyteczne do sprawdzania poprawności „prawdziwej” wersji.
Dunk
6
Zgaduję, że Patton oznaczał, że powinieneś odbyć rygorystyczne szkolenie i ćwiczenia w terenie w czasie pokoju. Analogią byłoby prowadzenie rygorystycznych zajęć w szkole informatycznej lub na studiach podyplomowych. Jestem prawie pewien, że Patton nie miał na myśli, że oficerów należy poinstruować, aby strzelali do swoich żołnierzy od tyłu, aby utrzymać żołnierzy na palcach!
Jay
7

Nie ma podstaw do nagrody lub kary na podstawie własnych zasług, ale na podstawie zachowania, na które celujesz. A czasem występują niezamierzone konsekwencje. Jest celem, aby powstrzymać zespół QA przed zwalnianiem się lub sprawić, by jakiś menedżer miał wrażenie, że rzeczywiście coś wnosi, nie zdając sobie sprawy, że tylko mu przeszkadza.

Pozytywne wyniki - Zespół ds. Kontroli jakości pracuje ciężej, aby znaleźć błędy. Kto wie, może uważają to za wyzwanie. To przyjazna gra. A może robią to tylko dlatego, że są obserwowani (Efekt Hawthorne'a?).

Wynik negatywny - i tak mogą nie pracować ciężej i znaleźć błąd. QA postrzega to jako małostkowe i przeciwne. Więc teraz zaczynają szukać hiper-błędów i zwracają różnego rodzaju wybredne małe problemy. Ta czcionka nie wyświetla się poprawnie, gdy wykonam zrzut ekranu i przekonwertuję go na plik pdf i wyświetlę w 500%.

No Impact - brzmi dla mnie tak, że to nie ma znaczenia, więc po co zawracać sobie głowę? Po prostu ryzykujesz marnowanie czasu i irytowanie ludzi.

Wszyscy moglibyśmy się zgodzić, że nie zadziała to w 90% przypadków. To nie przyniesie wiele dobrego pozostałym 10%. Przetestuj wszystko dla siebie. Czy klienci są bardziej zadowoleni z wydania, które zawiera celowe błędy w kodzie? Czy wpływa to na morale pracowników i wydajność w innych obszarach? Zwiększyć obrót? Ty nam powiedz.

JeffO
źródło
Zdecydowanie zgadzam się z tym, że zgłaszane są problemy wybredne.
Adam Johns
@AdamJohns - Nigdy nie wiesz na pewno, chyba że spróbujesz go przetestować. Są lepsze sposoby, więc byłoby to dla mnie prawie ostatecznością.
JeffO
7

Pochodzący ze świata, w którym oczekuje się, że programiści sami piszą i przeprowadzają testy, ten silos „testujący” „QA”, o którym mówisz, przeraża mnie i myli, więc postaram się odpowiedzieć z tej perspektywy. Na marginesie, wykwalifikowani inżynierowie ds. Kontroli jakości, z mojego punktu widzenia (jak to dobrze opisano w odpowiedzi @ SparK), powinni skupić się na większych kwestiach, aby upewnić się, że oprogramowanie w pełni zaspokaja historie użytkowników i ma ogólną „jakość” (w odniesieniu do domena, dla której oprogramowanie jest przeznaczone), zamiast szukać błędów.

To, co mnie tutaj przyciągnęło, to wzmianka przez Jamesa Mccleoda o „wstrzyknięciu wady” w komentarzach do pytania. Właściwie uważam, że skłanianie programistów do zastanowienia się, w jaki sposób mogą wprowadzać błędy do systemu, jest świetnym pomysłem dogłębnego ukierunkowania koncepcji obrony. Żaden pojedynczy błąd nie powinien nigdy wystarczyć, aby doprowadzić do awarii całego systemu w niekontrolowany sposób (bez wyraźnego rejestrowania w akcji), spowodować uszkodzenie danych lub samo ujawnienie luki w zabezpieczeniach.

Programiści każdego komponentu tworzą celowe defekty, radzą sobie z innymi komponentami i ogólnie wprowadzają bardziej kontradyktoryjne nastawienie do swojego oprogramowania, prawdopodobnie mogą wiele zrobić w kierunku poprawy niezawodności oprogramowania. Nawet natychmiastowa korzyść może być znacząca - wymagałbym, aby przy każdym takim wstrzyknięciu nowego rodzaju usterki (dotychczas nie testowanej) programista natychmiast pokryłby ją nowym testem, który zostanie ustawiony flagą, która będzie pozwól, aby błąd mieszkał w bazie kodu bez zakłóceń przez krótki czas, a następnie włączał się przed dostarczeniem (i usunięto wadę), aby przekształcić się w regularny test, który zwiększy kompleksowość zestawu testów.

Powiązaną opcją jest użycie flag funkcji do celowego wyłączenia funkcji w poszczególnych komponentach w celu zbadania, jak radzą sobie z tym inne komponenty. Chciałbym również gorąco polecić przeczytanie bezpłatnej książki / artykułu „Uczenie się od osób udzielających pierwszej pomocy: kiedy twoje systemy muszą działać”, które opisują tak szeroko zakrojone testowanie infrastruktury oprogramowania, które będzie używane przez zespół Obamy w wyborach w 2012 roku.

yoniLavi
źródło
4
Zamiast pozwolić programistom na „wstawianie” błędów do kodu, ich czas byłby o wiele lepszy, aby zidentyfikować, w jaki sposób te błędy mogły dostać się do systemu na początku, a następnie poprawić kod, aby zapewnić, że te błędy nie mogą się zdarzyć lub że są odpowiednio obsługiwane oprogramowanie. Celem opracowania projektu nie jest testowanie systemu zapewniania jakości, lecz zbudowanie użytecznego, solidnego i działającego systemu, który robi to, co chcą jego użytkownicy.
Dunk
4

Jak już powiedzieli inni, nie jest zadaniem QA wyłącznie znajdowanie błędów. Chciałbym pójść dalej i powiedzieć, że technicznie nie jest to ich praca. Programiści powinni być odpowiedzialni za utrzymanie własnego kodu bez błędów. Pakiety testowe powinny być uruchamiane, zanim nowy kod zostanie w ogóle zatwierdzony, a jeśli pakiety testowe zawiodą, to nigdy nie powinno się udawać do kontroli jakości. Celowe wprowadzanie błędów oznacza, że ​​zdecydowanie nie możesz przejść testów, więc dlaczego twój kod przechodzi do kontroli jakości?

Kontrola jakości polega na sprawdzeniu poprawności aplikacji pod kątem wdrożonych przez nią historii użytkowników. Powinni przetestować przepływ, interfejs użytkownika itp. I upewnić się, że użytkownik może zrobić wszystko, co powinien, w możliwie najbardziej użyteczny i dostępny sposób. Robiąc to, oczywiście mogą natknąć się na błędy, ale jest to efekt uboczny tego, co robią, a nie tego, co robią. Pamiętaj, że kontrola jakości oznacza zapewnianie jakości, a nie zapewnianie błędów.

Chris Pratt
źródło
2

To niekoniecznie tak szalone, jak się wydaje. To zależy od twojej motywacji. Jeśli szukasz kija do pokonania zespołu testowego, to byłoby szalone. Z drugiej strony, jedną z najtrudniejszych rzeczy w tworzeniu oprogramowania jest wiedzieć, jak skuteczne jest twoje podejście do testowania.

Jeśli więc odpowiednio go skonstruujesz, możesz użyć tej techniki do oszacowania liczby nieuzasadnionych błędów w produkcie, który zamierzasz wysłać. Wyobraź sobie, że sztucznie umieściłeś 100 błędów w kompilacji testowej, a testerzy znajdują 50 z nich. Następnie możesz wywnioskować, że istnieje pewne prawdopodobieństwo, że jeśli znaleźli również 50 niesiewnych błędów, być może pozostało 50 do znalezienia.

Oczywiście wiąże się to z wieloma problemami. Możesz zdecydować, czy wysłać na podstawie tych statystyk, ale w prawdziwym życiu możesz znaleźć jeden bardzo paskudny problem lub tysiąc drobnych podrażnień.

Mimo to - wiedza to potęga i bez tej techniki masz jeszcze mniej pojęcia o jakości swojej bazy kodu. Jeśli możesz wdrożyć go z szacunkiem i z właściwych powodów, powiedziałbym „Dlaczego nie?”

Dominic Cronin
źródło
2

Jedna rzecz, o której nikt jeszcze nie wspominał: testowanie mutacji .

W tym miejscu zautomatyzowane narzędzie pobiera kod źródłowy i celowo wprowadza do niego błędy. (Np. Usuń losowo wybraną instrukcję, zmień AND na OR, lub cokolwiek innego.) Następnie uruchamia pełny zestaw testów i sprawdza, czy testy przeszły pomyślnie.

Jeśli wszystkie testy zakończą się pomyślnie, istnieją dwie możliwości:

  • To, co zostało zmienione, nic nie robi. Innymi słowy, masz martwy kod.
  • Zmiana wprowadziła błąd, którego Twój pakiet testowy nie wyłapuje. Potrzebujesz więcej testów.

Pamiętaj, że w przeciwieństwie do twojej propozycji wszystko, co opisałem powyżej, jest zautomatyzowane . Nie marnujesz czasu programistów, wkładając ręcznie bezsensowne błędy. I nie marnujesz czasu testerów na znajdowanie znanych błędów. Jedyne, co zużywasz, to czas pracy maszyny, który jest znacznie tańszy. (Maszyny nie nudzą się przeprowadzaniem tego samego testu 20 000 razy. Ludzie po chwili przestają się tym przejmować!)

Sugerowałbym, że automatyczne testowanie mutacji jest znacznie lepszym podejściem niż scenariusz manualny, o którym mówisz.

Pamiętaj, że jeśli poprosisz programistę o ręczne wstawienie błędów, rodzaj błędu, który otrzymujesz, prawdopodobnie nie jest reprezentatywny dla rodzaju przypadkowych błędów, które mogą popełnić ludzie. (Na przykład, jeśli nie zdajesz sobie sprawy, że istnieje możliwość wyścigu, prawdopodobnie nie zamieścisz też celowego). Oczywiście nie wiadomo, czy zautomatyzowane narzędzie jest bardziej obiektywne…

MathematicalOrchid
źródło
1

Chociaż ogólnie jest to zły pomysł (inne odpowiedzi doskonale wyjaśniają dlaczego), istnieje kilka szczególnych sytuacji, w których celowe wprowadzanie błędów do kodu produkcyjnego w kontrolowany, tymczasowy sposób może mieć sens.

Gdy refakturujesz kod testowy - i powinieneś, kod testowy zasługuje na taką samą uwagę jak szczegóły produkcyjne - możesz chcieć wiedzieć, czy kod testowy nadal znajduje błędy, które powinien znaleźć.

Następnie możesz celowo złamać kod produkcyjny, aby sprawdzić, czy testy nadal działają.

Jest wiele poziomów, na których jest to możliwe:

  • Deweloper, który właśnie zreformował niektóre testy jednostkowe, może złamać kod produkcyjny, aby sprawdzić, czy test jednostkowy nadal znajduje to, co powinien znaleźć.
  • Tester, który właśnie zreformował jakiś test akceptacyjny, może złamać kod produkcyjny, aby sprawdzić, czy test akceptacyjny nadal weryfikuje to, co powinien zweryfikować.
  • Jeśli interfejs jest stabilny i wystarczająco solidny (tj. Oparty na protokole), firma może chcieć zachować pakiet znanych wadliwych wersji produktu i przeprowadzić testy na nich, aby przeprowadzić test regresji.

To, czy te rzeczy mają sens, zależy. Jeśli jestem programistą i zajmuje mi tylko minutę, aby wstrzyknąć błąd, przetestuj test jednostkowy, usuń błąd - to dlaczego nie. Ale powinienem mieć mojego edytora, mój cykl i mój system kontroli wersji pod tak dobrą kontrolą, że nie przypadkowo zatwierdzę / dostarczę / zamelduję / nie popchnę błędu. To samo dotyczy testera i testu akceptacyjnego.

To, czy organizacja ma sens przechowywać zestawy znanych wadliwych wersji produktu i test regresji, zależy od testu. W przypadku sklepu internetowego nie zrobiłbym tego. W przypadku kart samochodowych, kart kosmicznych, kart bankowych lub kart płatnej telewizji zrobiłbym to.

To, ile wysiłku to zależy, zależy od stopnia oddzielenia testów od kodu produkcyjnego. Im bardziej oddzielone są testy od kodu produkcyjnego, tym mniej wysiłku to robi, tym bardziej spójne są testy z kodem produkcyjnym, tym więcej wysiłku.

Powód jest po prostu następujący: gdy testy i kod produkcyjny są spójne, zmiana kodu produkcyjnego wymaga częstej zmiany testów, co przełamałoby zależność między testami a wadliwymi próbkami produkcyjnymi. Będziesz musiał także zachować wadliwe próbki produkcyjne. W rzadkich przypadkach nawet to może być warte wysiłku, a kpina, a także inteligentne użycie systemu kontroli wersji może znacznie zmniejszyć wysiłek, ale wymaga znacznie więcej niż wykwalifikowanych programistów.

Pojęcie celowego wstrzykiwania błędów w kodzie produkcyjnym nazywa się sabotażem , a wstrzykiwany błąd nazywa się sabotażystą .

Christian Hujer
źródło
1

Tester, który nie pobiera kodu do przetestowania bezpośrednio z repozytorium, robi to źle. (1)

Programista, który jest sprawdzanie w znanej-wadliwy kod do repozytorium robi to źle. (2)


Dlatego na tym etapie nie ma już sposobu, aby ten schemat działał bez naruszenia przez jedną lub obie strony bardzo podstawowych założeń dotyczących sposobu opracowywania i testowania.


(1) Ponieważ musisz udokumentować, którą wersję przetestowałeś. Wersja oznaczona skrótem Git lub numerem wersji SVN to coś, co możesz przetestować, „kod, który dał mi Joe”, nie jest.

(2) Ponieważ po prostu nie robisz tego poza testowym sterownikiem, który oczekuje awarii.


Jest to próba możliwie najkrótszego, „windy”, która powinna mieć natychmiastowy sens zarówno dla programistów, testerów, jak i kierownictwa.

DevSolar
źródło
1
To jest okrągły argument. Mówisz: „wysiewanie błędów w kompilacji testowej jest nieprawidłowe, ponieważ programiści nie powinni tworzyć kompilacji ze znanym wadliwym kodem”.
Dominic Cronin
@DominicCronin: Nic o tym nie krąży. Wszystko, co zostanie przekazane do repozytorium, powinno być najlepszej możliwej jakości. Istnieje cały szereg powodów - unikanie sztucznej zmiany linii kodu jest jednym z nich (wrt „svn blame” i podobne funkcje repozytorium). Niebezpieczeństwo „zapomnienia” ponownego usunięcia błędu. Problem polegający na tym, że testerzy mogli po prostu sprawdzić, co zostało „zaszczepione”, patrząc na dziennik zmian repozytorium. Wiele innych powodów, praktycznie bez korzyści dla przeciwwagi. Ale brakuje mi miejsca, a zresztą chodziło o podanie jednego , krótkiego powodu.
DevSolar
@DominicCronin: Albo, mówiąc inaczej - nie może być przypadek należy przeprowadzić na „siewu” bug, ale linia musi być sporządzony na długo przed popełnieniem że do repo. A z drugiej strony, podczas konieczności „rozstawiony” kod do testowania może mieć jedną lub dwie rzeczy będzie dla niego, to powinien zawsze tylko przetestować popełnił kod. Te dwie idee - każda z nich jest już sama w sobie kontrowersyjna - po prostu nie łączą się w żaden rozsądny sposób.
DevSolar
0

Odradzam celowe wprowadzanie błędów do KAŻDEJ wersji wysyłanej do kontroli jakości.

Możesz od czasu do czasu, powiedzmy raz w roku, przeprowadzić tajną „kontrolę jakości”. Weź „sprawdzoną i działającą” bazę kodu i jak najwięcej małych nowych funkcji z listy Todo. Wdrażaj je „nieco niechlujnie” niż zwykle. Pomyśl o przypadkowych przypadkach, zapisz je, ale nie naprawiaj swojego kodu, aby je uwzględnić. Wyślij to do kontroli jakości.

Jeśli znajdą więcej niedziałających błędów, niż zapisałeś, na pewno nie twój QA wymaga nadzoru ... ;-)

Alexander
źródło
2
wydaje się, że nie oferuje to nic istotnego w porównaniu z punktami poczynionymi i wyjaśnionymi w poprzednich 16 odpowiedziach
komnata