Czy stworzenie całkowicie zduplikowanego systemu zapewniania jakości (QA) innej złej praktyki?

10

W pracy mamy dość skomplikowany system. Nazwijmy ten system System_A. Nasz zespół ds. Kontroli jakości stworzył inny system o nazwie System_B, aby przetestować System_A.

Sposób użycia System_B jest następujący. Generujemy dane wejściowe (przy użyciu samego System_B), IN, przetwarzamy je z powrotem przez System_B i generujemy dane wyjściowe, O_B. Proces przebiega więc następująco:

System_B(IN) -> O_B.

Następnie robimy to samo dla System_A, aby wygenerować własne dane wyjściowe, O_A:

System_A(IN) -> O_A.

W dowolnym momencie zakłada się, że O_B to oczekiwany wynik, a O_A to wynik obserwowany / rzeczywisty. Sugeruje się, że O_B jest źródłem „złota” (prawda). Jednak natrafiliśmy na kombinacje problemów.

  • O_A jest źle, O_B ma rację
  • O_A ma rację, O_B ma rację
  • O_A jest źle, O_B jest źle
  • O_A ma rację, O_B ma rację

Kto decyduje, co jest słuszne, jeśli zakłada się, że O_B ma zawsze rację (lub czego się oczekuje)? Okazuje się, że O_B jest czasem (lub często) błędny w kontroli i analizie przeprowadzanej przez ludzi. Sprawy przejdą kontrolę jakości przy użyciu tego procesu, a prawdziwi użytkownicy będą narzekać, a my wrócimy do stwierdzenia, że ​​O_B był w błędzie.

Pytanie brzmi: czy złą praktyką jest tworzenie „systemu testowego” w celu przetestowania prawdziwego systemu?

  • A co ze śliskim stokiem? Czy nie możemy zatem argumentować, że potrzebujemy jeszcze jednego systemu do przetestowania „systemu testowego”?
  • Koszt jest zdecydowanie wygórowany, ponieważ programiści muszą teraz nauczyć się co najmniej 2 podstaw kodu, z być może złożonością System_B większą niż System_A. Jak ocenilibyśmy, jak dobrze lub źle jest mieć System_B w organizacji?
  • Jednym z oryginalnych „przekonujących” powodów do stworzenia System_B była „automatyzacja” testowania. Teraz jesteśmy bardzo dumni z tego, że jesteśmy w pełni zautomatyzowani (ponieważ System_B generuje dane wejściowe, aby rozpocząć proces wykorzystywania samego siebie do generowania danych wyjściowych). Ale myślę, że wyrządziliśmy więcej szkody i wprowadziliśmy większą złożoność w sposób niewymierny. Czy zadanie kontroli jakości jest w pełni zautomatyzowane? Czy to wystarczający powód, aby uzasadnić utworzenie systemu równoległego?
  • Moją prawdziwą troską jest to, chociaż wszyscy wiemy, że System_B jest zły (dość często). Jeśli System_B jest tak dobry w przetwarzaniu danych wejściowych, a jego wyjściem jest źródło złota, dlaczego nie zastąpić System_A przez System_B? Na to nikt w pracy nie jest w stanie zapewnić satysfakcjonującej odpowiedzi.

Wszelkie wskazówki na ten temat są mile widziane.

Jane Wayne
źródło
1
Zapomniałeś Systemu C: ten, który decyduje, który z nich ma rację, jeśli A i B się nie zgadzają.
Robert Harvey,
1
Mówiąc poważniej, prom kosmiczny miał pięć komputerów pokładowych: 3 z uruchomionym oprogramowaniem lotniczym, jeden sprawdzający, czy wszyscy się zgadzają, i piąty z oprogramowaniem napisanym przy użyciu tych samych specyfikacji, ale innego dostawcy, na wypadek gdyby stało się nie do pomyślenia. To, czy zdecydujesz się przejść na ten poziom rygoru, zależy wyłącznie od ciebie, ale jest to precedens.
Robert Harvey,
3
Wiesz jedno, to znaczy, że ilekroć System_A i System_B nie zgadzają się ze sobą, jedna z nich ma błąd. Pomoże to znaleźć błędy w obu systemach. Jeśli System_A jest jedynym „ważnym”, pomógł ci znaleźć jakieś błędy w System_A, ale nie wszystkie. To jest ten sam pomysł za formalną weryfikacją.
user253751,
1
Coś, co nie jest jednoznaczne z twojego pytania: czy systemy A i B obsługują tę samą bazę kodów lub różne bazy kodów? Jeśli to drugie, a następnie, gdy nie zgadzają trzeba rozważyć nich zarówno złe, oraz zidentyfikowanie przyczyn, że dali różne odpowiedzi.
kdgregory,
1
A jeśli chodzi o twoje aktualne pytanie („czy to zła praktyka”): tylko jeśli nie ma powodu, aby dokładnie sprawdzać swoje operacje. I w typowym zastosowaniu biznesowym nie ma. Jeśli korzystasz z promu kosmicznego, jak zauważył Robert Harvey, jest. Są też niektóre aplikacje, takie jak handel akcjami lub prognozowanie pogody, w których można mieć dwa systemy, które się nie zgadzają i oba są ważne (jeśli niekoniecznie „właściwe”).
kdgregory,

Odpowiedzi:

5
  • O_A jest źle, O_B ma rację

Napraw A.

  • O_A ma rację, O_B ma rację

Fix B.

  • O_A ma rację, O_B ma rację

Mam nadzieję, że oni również się zgadzają.

  • O_A jest źle, O_B jest źle

Mamy nadzieję, że się nie zgadzają, więc będziesz wiedział, jak coś z tym zrobić.

Żaden proces nie łapie wszystkiego. Jasne, podwoiłeś swój kod, ale pomyśl o nim jak o 2 w O (2n). Zautomatyzowana kontrola jakości aż do testów integracyjnych to cudowna rzecz. Testy ręczne to utrudnienie dla innowacji. Zwłaszcza w przypadku zmian przekrojowych, które wymagałyby pełnego testu. Ponadto, ponieważ będziesz mieć różnych programistów wdrażających to samo, możesz sprawić, że będą się ścigać.

Różni ludzie powinni zwiększać szanse na uzyskanie różnych błędów. Nie radzę tworzyć systemu B, radząc sobie z systemem A. Wszystko, co daje, to test regresji. Możesz uzyskać to samo, zapisując stare kopie O_A w celu porównania z nowymi.

Pytanie brzmi: czy złą praktyką jest tworzenie „systemu testowego” w celu przetestowania prawdziwego systemu?

Jeśli tak, to wszystkie testy są złe.

  • A co ze śliskim stokiem? Czy nie możemy zatem argumentować, że potrzebujemy jeszcze jednego systemu do przetestowania „systemu testowego”?

Tak, możemy się z tym kłócić. Nazwiemy ten trzeci system, system_A. : P

  • Koszt jest zdecydowanie wygórowany, ponieważ programiści muszą teraz nauczyć się co najmniej 2 podstaw kodu, z być może złożonością System_B większą niż System_A. Jak ocenilibyśmy, jak dobrze lub źle jest mieć System_B w organizacji?

Według liczby zadowolonych klientów, którzy płacą nam za zabawę z bronią nerf. Uwolniłeś się od kosztów ręcznego testowania. Stworzyłeś coś, którego użyteczność zostanie udowodniona za każdym razem, gdy zostanie złapany przez błąd. Błąd wykryty wcześnie kosztował znacznie mniej niż błędy zgłoszone późno.

  • Jednym z oryginalnych „przekonujących” powodów do stworzenia System_B była „automatyzacja” testowania. Teraz jesteśmy bardzo dumni z tego, że jesteśmy w pełni zautomatyzowani (ponieważ System_B generuje dane wejściowe, aby rozpocząć proces wykorzystywania samego siebie do generowania danych wyjściowych). Ale myślę, że wyrządziliśmy więcej szkody i wprowadziliśmy większą złożoność w sposób niewymierny. Czy zadanie kontroli jakości jest w pełni zautomatyzowane? Czy to wystarczający powód, aby uzasadnić utworzenie systemu równoległego?

Złożoność System_B jest cudownie odizolowana od System_A. Dodanie funkcji do System_A nie jest trudniejsze, ponieważ istnieje System_B. Jest to w rzeczywistości łatwiejsze, ponieważ System_B daje im pewność, że mogą iść szybko.

  • Moją prawdziwą troską jest to, chociaż wszyscy wiemy, że System_B jest zły (dość często). Jeśli System_B jest tak dobry w przetwarzaniu danych wejściowych, a jego wyjściem jest źródło złota, dlaczego nie zastąpić System_A przez System_B? Na to nikt w pracy nie jest w stanie zapewnić satysfakcjonującej odpowiedzi.

Czy to literówka? System_B jest często błędny, więc jest to złoty standard, którego chcesz użyć, aby zastąpić System_A?

Zakładam, że miałeś na myśli, że System_A często się myli. Tak naprawdę nie ma znaczenia, który z nich jest najczęściej błędny. Cokolwiek jest nie tak, to takie, które potrzebuje pracy. Programiści nie decydują o tym, co jest dobre, a co złe. Testy wywołują nieporozumienie, które oznacza, że ​​coś jest nie tak. Deweloperzy ustalają, co to jest. Pamiętaj, że nie produkuje się tutaj złotego standardu. Istnieje tylko zgoda lub brak zgody. Różnica zdań wymaga wykonania pracy. Część tej pracy polega na ustaleniu, gdzie.

candied_orange
źródło
3

Jeśli masz system produkcyjny, który jest faktycznie używany przez klientów, absolutnie konieczne jest posiadanie systemu kontroli jakości w celu weryfikacji poprawek błędów i nowej funkcjonalności. Z punktu widzenia jakości powinna być jak najbliższa replika systemu produkcyjnego. W ten sposób, jeśli upewnisz się, że system produkcyjny i jego system kontroli jakości są identyczne, to, co działa na jednym, powinno działać na drugim. Jeśli tak nie jest, wówczas systemy nie są identyczne, wejścia nie były identyczne i / lub wyjścia zostały źle zinterpretowane.

Dzieje się to podwójnie, więc jeśli twój system ma kluczowe znaczenie i musi być dostępny 24/7. Nie możesz wtedy pozwolić sobie na luksus, aby nie mieć systemu zapewniania jakości, ponieważ musisz absolutnie zminimalizować przestoje w systemie produkcyjnym. A jeśli jest to system 24/7, to dokładna replika systemu produkcyjnego jest bardzo, bardzo silną rekomendacją.

Oczywistą wadą tego podejścia jest koszt. Podwaja koszty sprzętu i zwiększa koszty wdrożenia i konserwacji. Ponadto należałoby wdrożyć ciągłą replikację danych z systemu produkcyjnego do kontroli jakości, aby zminimalizować możliwość różnych wyników z powodu różnicy w danych, z którymi współpracują systemy.

Pewną równowagę zwykle można znaleźć, zmniejszając niektóre komponenty systemu zapewniania jakości w stosunku do systemu produkcyjnego, aby większość funkcji mogła zostać odpowiednio przetestowana. Są to zwykle serwery nadmiarowe, rozmiar serwerów lub liczba stacji roboczych. Jednak z mojego doświadczenia wynika, że ​​jakiś błąd zawsze znajduje się dokładnie w części, która została zmniejszona, a potem koszmarem jest odtworzenie problemu i wdrożenie poprawki przy zachowaniu minimalnego dozwolonego czasu przestoju w systemie produkcyjnym.

Vladimir Stokic
źródło
2

Za każdym razem, gdy testujesz system, musisz wiedzieć, jaki jest twój oczekiwany wynik.

Problem z wygenerowaniem przez system oczekiwanego wyniku polega oczywiście na tym, „jak przetestować ten system”

Mimo to nieczęsto zdarza się, aby ludzie używali arkuszy kalkulacyjnych na przykład do generowania zestawów oczekiwanych wyników.

Na koniec dnia naprawdę potrzebujesz człowieka, aby zinterpretować wymagania systemu i ręcznie uzyskać oczekiwany wynik. Jeśli masz system, zrób to i sprawdź tylko różnice, wtedy pomijasz testy.

Ewan
źródło