Test what you fly and fly what you test
Generalna zasada w przemyśle kosmicznym brzmi: „Test what you fly and fly what you test” i oznacza, że należy sprawdzać te komponenty misji, które mają być używane, oraz wykorzystywać te, które zostały przetestowane. Brzmi banalnie, lecz to właśnie ścisłe trzymanie się tej zasady mogłoby pomóc w wielu projektach. Testowanie w przypadku misji kosmicznych jest o tyle trudne, że nie zawsze możliwe jest wierne odtworzenie warunków środowiskowych lotu lub takich, jakie panują na innej planecie. Tworzy się w tym celu specjalne laboratoria bądź symulacje komputerowe, lecz nawet wtedy stanowi to duże wyzwanie. ISTQB mówi wprost – testowanie gruntowne jest niemożliwe. Tylko w najprostszych przypadkach da się sprawdzić wszystkie kombinacje danych i warunków, a złożone systemy wykorzystywane w misjach kosmicznych zdecydowanie nie należą do prostych. Ponadto testowanie jest zależne od kontekstu. Tak specyficzne systemy wymagają również dostosowanych testów.
Testuj, żeby ujawniać błędy, a nie dowodzić ich braku
Kolejną zasadą, która odgrywa ogromną rolę w testowaniu oprogramowania misji kosmicznych, jest testowanie jako proces ujawniający istnienie błędów, a nie dowodzący ich braku. Jest to pesymistyczne, ale nader realistyczne podejście, o którym zapomniano choćby w przypadku katastrofy Ariane 5 z satelitami Cluster. Wspomina o tym nawet oficjalny raport, w którym stwierdzono, że oprogramowanie zostało uznane za poprawne, dopóki nie okazało się, że jest wadliwe.
Testuj najwcześniej, jak tylko się da
Równie istotna jest wspomniana już wcześniej zasada związana z testowaniem tzw. shift-left. Wykrycie błędów na wczesnym etapie projektu pozwala zaoszczędzić czas i pieniądze. W wielu misjach błędy pojawiły się już na etapie projektowania i nie zostały wykryte z powodu niedostatecznie rzetelnych procesów weryfikacji.
Jeśli chodzi o stosowane w NASA praktyki, to wiadomo, że organizacja kładzie duży nacisk na testowanie w cyklu tworzenia oprogramowania. Szacuje się, że około 40% budżetu projektu jest poświęcone właśnie na testy. Aktywności związane z zapewnianiem jakości rozpoczynane są zwykle na etapie analizy wymagań, które muszą być zrozumiałe, szczegółowe, realistyczne i adekwatne do możliwości, a także testowalne. Celem dobrze zaprojektowanej specyfikacji oprogramowania jest to, aby inżynier sprzętu rozumiał, jak oprogramowanie kieruje systemem. We wczesnych stadiach testowania oprogramowania NASA używa często symulacji danych wejściowych. W późniejszych fazach testowanie obejmuje również sprzęt do testowania operacji i interfejsów, poleceń naziemnych i końcowej fazy. Dużą wagę przykłada się wtedy nawet do takich szczegółów jak odpowiednia długość kabli. Ponadto większość sprzętu NASA nie może być naprawiana w trakcie eksploatacji, co nadaje jeszcze większą wagę zapewnianiu jakości już na etapie jego tworzenia.
Quality Assurance
Zapewnianie jakości w projektach IT. Sprawdź jakie trendy ukształtują rynek, na którym będzie wysokie zapotrzebowanie na testerów oprogramowania i zespoły zarządzania jakością.
Przeczytaj artykuł: Quality Assurance (QA) – zapewnij jakość w Twoich projektach IT
Testuj na czas
Innym istotnym dla testowania w misjach kosmicznych czynnikiem jest czas. Chodzi nie tylko o okna pogodowe umożliwiające start i synchronizację działań w czasie, ale także logistykę na etapie wytwarzania produktu (np. przygotowanie komponentu lub systemu w odpowiednim terminie, aby można było go przetestować w komorze próżniowej). Nawet tego typu testy zazwyczaj nie są jednak w stanie zagwarantować identycznych warunków jak te, które panują w kosmosie.
Proces testowania w NASA obejmuje także najnowsze i najbardziej zaawansowane technologie, które pozwalają też na oszczędności. Jedną z nich jest technologia Digital Twin, polegająca na tworzeniu dokładnych i szczegółowych cyfrowych replik produktów, procesów i systemów.
SpaceX – jak oni testują?
Również w SpaceX powszechną praktyką jest testowanie połączeń różnych systemów i symulacja warunków ich działania. Do testów oprogramowania wykorzystuje się m.in. tzw. table rocket. Polega to na ułożeniu wszystkich komputerów i kontrolerów lotu na stole i połączeniu ich tak, jakby były w prawdziwej rakiecie. W celu wykonania testów integracyjnych przeprowadza się na komponentach pełną symulację lotu, monitorując wydajność i wychwytując potencjalne awarie. W przypadku testów obciążeniowych inżynierowie robią to, co nazywają „przecinaniem sznurków” – losowo wyłączają komputer pokładowy w trakcie symulacji, aby zobaczyć, jak zareaguje. Ten poziom symulacji, połączony ze znacznym udziałem automatyzacji, pozwala osiągać świetne wyniki.
SpaceX jest w stanie bez obaw wprowadzać zmiany w oprogramowaniu produktu nawet 17 000 razy dziennie! Z tego, jak SpaceX tworzy oprogramowanie, możemy wywnioskować, że ponowne wykorzystywanie kodu, kultura DevOps i ciągły przepływ testowania są dla nich kluczem do sukcesu.
Podsumowanie
Powyższe obserwacje, chociaż kontekst może wydawać się odległy o lata świetlne, są całkiem bliskie projektowej codzienności każdego z nas.
Wiele z opisanych w artykule przypadków dostarcza uniwersalnych wniosków, które mogą znaleźć zastosowanie w projektach z innych branż, nie tylko kosmicznej. Mowa tu, chociażby o takich obszarach jak:
- analiza ryzyka,
- cykl życia oprogramowania (shift-left i włączenie procesu testowania do wczesnych faz powstawania software’u),
- testowanie produktu w środowiskach o różnych konfiguracjach i zasobach (dev, stage, preprod),
- automatyzacja procesu wytwarzania i integracji oprogramowania (CI/CD),
- pokrywanie funkcjonalności różnymi przypadkami testowymi.