Skip to content

Kako smo uspeli da pošaljemo čoveka u svemir, a meni baguje aplikacija za dostavu hrane?

Danas koristimo aplikacije za najrazličitije stvari – od naručivanja hrane do brojanja koraka i čaša vode koje smo popili, ali one su često daleko od savršenih. Povremeni bagovi i problemi su nešto na šta smo već navikli, iako u njima svakako ne uživamo. Otud često čujemo pitanje – „kako smo uspeli da pošaljemo čoveka u svemir, a meni baguje aplikacija za __________ (upiši po želji)“?

Koliko god bile iritantne, u nekim slučajevima su greške u softveru ipak samo sitna neprijatnost, ali postoje i sistemi gde kvar može izazvati ozbiljne posledice. Dok je kod nekih aplikacija prihvatljivo da povremeno zakažu, kod drugih greška jednostavno ne sme da se dogodi. U takvim slučajevima, testiranje igra izuzetno važnu ulogu. Kako, dakle, izgleda razvoj i testiranje softvera tamo gde je pouzdanost apsolutni prioritet?

Ko ima najrigoroznije standarde za testiranje softvera?

Najstrože standarde testiranja softvera primenjuju one industrije u kojima greška prosto nije opcija. Pored vazduhoplovne i svemirske industrije, to važi i za medicinske uređaje, nuklearne elektrane, automobilsku industriju (posebno kod autonomnih vozila), a u dobroj meri i za finansijske institucije.

NASA je jedna od organizacija koje svakako prednjače u ovom smislu. Oni ulažu ogromne resurse u testiranje pre nego što bilo koji softver postane deo misije. Čak i najmanja greška može dovesti do katastrofalnih ishoda, od fatalnih posledica po ljude, preko ogromnih finansijskih gubitaka, pa do propadanja čitave misije u koju su uložene godine ili čak decenije ogromnog truda, istraživanja i razvoja.

Kako se testira softver u NASA-i?

Softver koji se koristi u svemiru mora proći dug period rigoroznog testiranja pre nego što se uopšte nađe u upotrebi. NASA koristi niz složenih procedura kako bi osigurala da svaki deo softvera funkcioniše besprekorno u svim mogućim uslovima.

NASA-tester

1.Standardizacija i smernice

Pre svega, NASA ima izuzetno stroge standarde i smernice kako bi osigurala doslednost i kvalitet u razvoju i testiranju. Postoji veliki broj dokumenata koji definišu standarde i procese za inženjering softvera unutar agencije, kao i priručnika koji pružaju detaljne smernice za njihovu implementaciju. Oni služe kao vodič za sve koji su uključeni u upravljanje, razvoj, testiranje i održavanje NASA-inog softvera.

 U kontekstu testiranja, posebno su važni standardi za inspekciju koda, koji pomažu rano otkrivanje defekata. Ovaj standard propisuje sistematske provere koda u ranim fazama razvoja, što je važno za svaku vrstu testiranja i svaku vrstu softvera, ali je posebno važno u okolnostima u kojim greška koja uđe u produkciju ne može da se reši brzim update-om. Kada misija već krene, vrlo verovatno je već kasno za popravljanje kritičnih grešaka koje bi lako mogle ugroziti uspeh čitavog poduhvata.

 Tokom inspekcije, multidisciplinarni timovi koriste detaljne kontrolne liste kako bi proverili sve – od grešaka u sintaksi do složenih logičkih problema i neusaglašenosti između softvera i hardvera.

2. Dobro definisani zahtevi

Jedan od ključnih faktora uspeha u NASA-inom testiranju softvera jeste i precizno definisanje zahteva. Pre nego što se uopšte napiše prva linija koda, NASA ulaže ogroman napor u definisanje tačnih, nedvosmislenih i proverljivih zahteva koji izražavaju konkretna očekivanja od softvera.

Za razliku od mnogih komercijalnih aplikacija koje se razvijaju pomoću Agile metodologije, sa stalnim prilagođavanjem na osnovu povratnih informacija korisnika, NASA-ini zahtevi su apsolutno precizni od samog početka. Oni moraju pokriti svaki mogući scenario, uključujući i ekstremne situacije koje se mogu desiti u svemiru, i definisati očekivanja od softvera za svaki od tih scenarija.
Primera radi, ako softver upravlja modulom za sletanje na Mars, zahtevi će uključivati preciznu sekvencu naredbi koje se moraju izvršiti tokom spuštanja, način regulisanja temperature letelice, očekivano vreme kašnjenja signala između letelice i Zemlje, i još mnogo sličnih detalja.

Ovi zahtevi se definišu u saradnji između inženjera, naučnika, testera i astronauta, a zatim prolaze kroz višestruke provere kako bi se otklonile nejasnoće. Samo onda kada su zahtevi potpuno definisani, softver može da uđe u razvoj i testiranje.

3. Detaljne simulacije

Za pouzdan rad softvera i uspeh misije nije dovoljno utvrditi da li softver prosto radi već i da li radi u uslovima za koje je namenjen. Naravno, ovi uslovi su često sasvim drugačiji i daleko ekstremniji nego bilo gde na Zemljinoj površini. Na primer, softver koji kontroliše robotske ruke na Međunarodnoj svemirskoj stanici prethodno je testiran u nultoj gravitaciji u avionima koji simuliraju bestežinsko stanje.

Takođe, softver koji je korišćen za Curiosity rover, koji je 2012. godine uspešno sleteo na Mars, testiran je kroz hiljade simulacija koje su proveravale ponašanje sistema u najrazličitijim scenarijima. Testiranja su obuhvatala ponašanje softvera pri ekstremnim temperaturnim oscilacijama, u prašnjavoj atmosferi, na različitim vrstama terena, kao i prilikom potencijalnih kvarova pojedinih instrumenata tokom misije. Svaka moguća situacija bila je unapred testirana.

4. Sistemi zaštite

NASA softver je dizajniran tako da bude što otporniji na greške. Gotovo svi kritični sistemi imaju jednu ili više identičnih kopija – tako na primer ako jedan procesor zakaže, drugi preuzima njegovu funkciju. Osim toga, softver ima ugrađene mehanizme zaštite koji omogućavaju letelici da se automatski, bez ljudske intervencije, oporavi od određenih problema.

Takvi mehanizmi mogu uključivati sisteme zaštite napajanja, gde letelica ima više izvora energije (solarnih panela ili baterija), a u slučaju kvara jednog izvora automatski se prebacuje na drugi kako bi nastavila s radom. Takođe, često se koristi rezervna navigaciona i komunikaciona oprema, gde letelica može preći na alternativne senzore ili pomoćne antene ako dođe do kvara glavnih sistema za orijentaciju ili komunikaciju sa Zemljom.

5. Stručnost i iskustvo 

NASA ne angažuje samo vrhunske programere, već iskusne inženjere koji razumeju specifične izazove svemirskih misija. Rad u svemiru nosi sa sobom jedinstvene probleme – izloženost zračenju koje može uticati na elektronske sisteme, ekstremne temperature koje mogu oslabiti hardver, kao i potrebu da softver funkcioniše besprekorno u okruženju gde svaka greška može imati ozbiljne posledice.

Upravo zato, NASA-ini stručnjaci nisu samo developeri, već svestrani inženjeri sa znanjem iz oblasti aeronautike, elektronike i fizike svemirskog okruženja.

Ali nije dovoljno imati samo vrhunske stručnjake – ključno je i učiti iz svojih grešaka. NASA ima kulturu analize i neprekidnog unapređivanja, gde se svaki uspeh i svaki neuspeh detaljno proučavaju. Lekcije naučene iz prethodnih misija implementiraju se u nove projekte, čime se smanjuje rizik od ponavljanja starih grešaka. Ova akumulacija znanja kroz decenije rada omogućava NASA-i da konstantno podiže standarde i postiže ono što je nekada delovalo nemoguće.

Da li to znači da NASA ne greši?

Ipak, i pored svih NASA-inih rigoroznih procedura i mera predostrožnosti, kroz istoriju postoji nekoliko poznatih primera gde su softverski problemi doveli do propasti misije i ogromnih gubitaka. Najsavremenije metodologije testiranja su neophodne u ovako kritičnom okruženju, ali je kompleksnost softvera, hardvera i njihove interakcije sa okolinom tolika da je i dalje nemoguće garantovati ne samo da softver neće imati greške, nego ni da neće imati greške koje su krajnje opasne i potencijalno kobne.

Jedan od najzanimljivijih slučajeva bio je slučaj Mars Climate Orbiter-a iz 1999. godine. Ova misija je propala zbog naizgled neshvatljive greške. Inženjeri su koristili različite merne jedinice – oni koji su pravili navigacioni sistem koristili su metrički sistem (metre i kilometre), a oni koji su pravili softver za proračun potiska letelice služili su se imperijalnim jedinicama (jarde i milje), što je dovelo do velikih odstupanja u planiranoj putanji. Ishod? Letelica je ušla u atmosferu Marsa pod pogrešnim uglom i izgorela. Par godina pre toga, 1996, letelica Ariane 5 se samouništila nakon samo 37 sekundi leta zbog problema sa sistemom navigacije.

Iako bi se svakako moglo reći da zahvaljujući učenju iz grešaka danas ima manje ovakvih nemilih događaja, oni ipak nisu iskorenjeni. Najnoviji primer je Ingenuity, prvi helikopter koji je leteo na drugoj planeti, a koji je tokom svog 72. leta na Marsu u januaru 2024, takođe doživeo softverski problem sa navigacionim sistemom, što je dovelo do gubitka kontrole pri sletanju i ozbiljnog oštećenja koje je ovu letelicu zauvek prizemljilo.
Iz ovih slučajeva možemo videti da, čak i sa najstrožim procedurama, greške mogu promaći, ali ono što izdvaja organizacije poput NASA-e jeste sposobnost da iz njih nauče i unaprede svoje standarde i protokole.

Šta smo onda zaključili?

Dakle, kako smo uspeli da pošaljemo ljude u svemir, a meni baguje aplikacija za dostavu hrane? Razlog je jednostavan – softveri se testiraju u skladu sa posledicama njihovog eventualnog kvara. To što ti aplikacija baguje ne mora da govori ništa o kvalitetu rada developera ili testera, već o prioritetima i standardima koje softverske kompanije sebi postavljaju.

U svetu komercijalnog softvera, proizvodi moraju brzo da izlaze na tržište, što znači da testiranje često nije toliko rigorozno kao npr. u vazduhoplovnoj industriji. Greške se rešavaju kroz ažuriranja i ispravke nakon puštanja softvera u rad, dok se kod svemirskih misija takav luksuz ne može priuštiti.

Za svemirsku letelicu, greška može značiti kraj misije i milijarde izgubljenih dolara, pa je testiranje izuzetno temeljno i dugotrajno. Drugim rečima, greška kod svemirske letelice se često ne može ispravljati u letu, figurativno i doslovno. Svaki aspekt ponašanja softvera mora biti predviđen, analiziran i proveren pre nego što se lansira. S druge strane, ako aplikacija za naručivanje hrane ponekad zakaže, korisnik može ostati trenutno gladan i frustriran, ali posledice definitivno nisu fatalne.

Dakle, sledeći put kada ti neka aplikacija zablokira ili se neočekivano zatvori, seti se da verovatno nije testirana po NASA-inim standardima, i da će sledeći update sasvim moguće rešiti taj bag koji te iritira.

Ako i ti želiš da pomogneš da se reše iritantni bagovi, ili možda čak helikopteru da se ne sruši na Mars, SixCube University je pravo mesto da započneš svoj put ka tome. Saznaj više o našem QA kursu i prijavi se već danas!