Katastrofalne defekty oprogramowania oraz odpowiedzialność w pracy QA

Jeśli myślisz o karierze w branży IT jako tester oprogramowania lub już jesteś na tej ścieżce, to pewnie zdajesz sobie sprawę, jak ważna jest rola QA w tworzeniu i wdrażaniu systemów informatycznych. W tym wpisie przedstawię Ci trzy zdarzenia, które pokazują, jak katastrofalne mogą być skutki niedostatecznego testowania i błędów w procesach zapewnienia jakości oprogramowania.

Wolisz oglądać niż czytać? Wersja wideo w formie Shorts jest dostępna na YouTube.

Rakieta Ariane 5

Ta historia dotyczy katastrofy rakiety Ariane 5, która miała miejsce w 1996 roku. Była to pierwsza próba wystrzelenia nowego modelu rakiety nośnej, która miała wynieść na orbitę cztery satelity. Niestety, po 37 sekundach od startu rakieta eksplodowała, niszcząc ładunek o wartości ponad 370 milionów dolarów.

Co było przyczyną tej katastrofy? Okazało się, że to błąd w oprogramowaniu systemu sterowania lotem. Podczas konwersji prędkości kątowej z 64-bitowej liczby zmiennoprzecinkowej na 16-bitową liczbę całkowitą wystąpiło przepełnienie bufora, co spowodowało awarię systemu i autodestrukcję. Ten sam kod był używany w poprzednim modelu rakiety Ariane 4, który nie miał problemów z tym błędem. Dlaczego? Ponieważ prędkość kątowa Ariane 5 była większa niż Ariane 4 i przekraczała zakres dopuszczalny dla 16-bitowej liczby całkowitej. Co więcej, ten kod był zbędny dla misji Ariane 5 i mógł być wyłączony bez wpływu na działanie rakiety.

Badanie tego wypadku wykazało błędy w analizie, specyfikacji i testowaniu oprogramowania. Wnioski z katastrofy znacznie zwiększyły świadomość opinii publicznej dotyczącą systemów krytycznych dla bezpieczeństwa .

 

Samolot pasażerski Boeing 737 Max

Wyjątkowo bolesne są zdarzenia, które wydarzyły się w latach 2018-2019 i były związane z samolotami Boeing 737 Max. W październiku 2018 roku samolot linii Lion Air rozbił się w Indonezji, zabijając wszystkie 189 osób na pokładzie. W marcu 2019 roku samolot tego samego typu linii Ethiopian Airlines spadł kilka minut po starcie, zabijając 157 osób. W obu przypadkach przyczyną katastrofy był błąd w systemie automatycznego sterowania lotem o nazwie MCAS (Maneuvering Characteristics Augmentation System), który miał zapobiegać przeciągnięciu samolotu. System ten opierał się na danych z jednego czujnika kąta natarcia i nie był wystarczająco przetestowany pod kątem różnych scenariuszy awaryjnych. W wyniku tego system ten mógł aktywować się niepotrzebnie i zmuszać samolot do gwałtownego opadania, pomimo prób odzyskania kontroli przez pilotów.

Po katastrofach wszystkie samoloty 737 Max uziemiono, a Boeing wprowadził wiele zmian w systemie MCAS, aby zapobiec podobnym sytuacjom w przyszłości. W listopadzie 2020 roku Federalna Administracja Lotnictwa (FAA) wydała zgodę na ponowne dopuszczenie samolotów Boeing 737 Max do użytku. W konsekwencji katastrof FAA zmieniła także swoje wytyczne dotyczące walidacji oprogramowania.

 

Urządzenie do radioterapii Therac-25

Trzecia historia ma związek z awariami urządzenia do radioterapii Therac-25 w latach 80. XX wieku. Urządzenie to miało za zadanie dostarczać precyzyjne dawki promieniowania do chorych na raka pacjentów. Jednakże z powodu błędów (typu race condition) w oprogramowaniu sterującym urządzeniem, mogło ono czasami dostarczać znacznie większe dawki promieniowania niż zamierzone, co prowadziło do poparzeń, uszkodzeń narządów i śmierci pacjentów. Szacuje się, że co najmniej sześć osób zmarło lub zostało poważnie okaleczonych przez urządzenie Therac-25.

Przyczyną awarii były błędy w procesie zapewnienia jakości oprogramowania, między innymi zaniedbanie przeglądów wymagań i kodu, słaba dokumentacja oraz niewłaściwe testowanie. Therac-25 został wycofany z użytku, a wnioski z tej tragicznej historii pozwoliły opracować standard tworzenia oprogramowania dla urządzeń medycznych (IEC 62304).

 

Odpowiedzialność za QA

Mam nadzieję, że ten wpis zmotywował Cię nie tylko do dalszego pogłębiania swojej wiedzy i umiejętności dotyczących testowania oprogramowania, ale również do brania większej odpowiedzialności za jakość systemu jako całości. Zabrzmi to banalnie, ale Twoja praca ma znaczenie i może mieć wpływ na życie wielu ludzi, zwłaszcza jeśli testujesz (będziesz testować) systemy krytyczne dla bezpieczeństwa. W takich projektach obowiązują standardy jakości, które zostały wypracowane przez lata i nie można ich lekceważyć.