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

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.

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

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.

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.