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

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).

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.

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.

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.

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ł.

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źć”,

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 są 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.

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.

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.

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.

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.

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).

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 .

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ść.

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.

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.

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.

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?”

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…

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ą .

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.

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 ... ;-)