Branża potrzebuje ich coraz więcej. Bez nich zginiemy. Testerzy

Sprzęt był sprzedawany między 2006 a 2008 rokiem. Zune charakteryzował się wieloma pionierskimi rozwiązaniami. Jego posiadacze mogli korzystać z darmowych hot-spotów WiFi oraz ściągać utwory na zasadzie abonamentowej, tak jak później miało to miejsce w przypadku Spotify, iTunes Music czy Google Play Music. Mimo że piosenki, które odtwarzał Zune, były zabezpieczone przed kopiowaniem, można było się nimi dzielić z innymi użytkownikami, którzy mogli je odtwarzać trzy razy, o ile ich nie kupili.

Wydawałoby się, że trudno o lepsze podstawy do sukcesu, prawda? Szczególnie jeśli konkurencja nie oferuje tak zaawansowanych funkcji. Niestety Zune w postaci sprzętowej przetrwał zaledwie dwa lata. Przyczyny były różne, ale jedną z ważniejszych były błędy w jego oprogramowaniu.

Ci z użytkowników, którzy chcieli odtworzyć muzykę w Sylwestra 2008 roku spostrzegli, że ich urządzenie było nie do użytku. Na oficjalnym forum poświęconym wsparciu Zune pojawiło się ponad 2500 wątków stworzonych przez użytkowników skarżących się na buga, którego szybko ochrzczono “Zune Y2K”, problemem roku 2000 dla Zune.

Był to gwóźdź do trumny tego urządzenia.

Nawalił niewinnie wyglądający fragment kodu sprawdzającego, czy bieżący rok jest rokiem przestępnym.

year = ORIGINYEAR; /* = 1980 */
while (days > 365)
{
​ if (IsLeapYear(year))
​{
​ if (days > 366)
​ {
​ days -= 366;
​ year += 1;
​ }
​ }
​ else
​ {
​ days -= 365;
​ year += 1;
​ }
}

Większość programistów na pierwszy rzut oka zauważy problem. W czasie roku przestępnego najpierw sprawdzany jest węższy warunek, a w jego wnętrzu warunek szerszy. Powoduje to zamknięcie się w nieskończonej pętli. Nieco ironiczny jest fakt, iż programista, który to zauważył i opublikował na forum ZuneBoards, stwierdził:

No cóż, cztery lata później o Zune nikt już nie pamiętał. Zniknął z rynku również przez słabo przetestowane oprogramowanie wewnętrzne.

Każde urządzenie wokół nas składa się z dwóch komponentów: sprzętu (hardware) oraz oprogramowania (software) - od najprostszego robota kuchennego, którego możemy ustawić na odpowiedni program działania, poprzez realizującą program prania pralkę, aż po automatyczny termostat, który powinien uruchomić o odpowiedniej porze lub w odpowiedniej temperaturze piec.

W każdym z tych urządzeń nieprzetestowane oprogramowanie może zawieść powodując szkody. Przypalony w piekarniku chleb czy zmarznięci domownicy to wcale nie najgorszy przypadek. Oto kilka takich sytuacji, w których brak dogłębnego przetestowania programu zawartego w urządzeniu wyrządziło szkody o wiele dotkliwsze. W każdym z tych przypadków przemyślane testy, nawet w postaci prostych testów jednostkowych (unit tests), a czasem testów integracyjnych, nie dopuściłoby do problemu.

Mars Climate Orbiter był sondą wystrzeloną w 1998 r., która po dotarciu na orbitę Marsa we wrześniu 1999 r. miała zajmować się badaniami atmosfery, pogody i klimatu tej planety. Niestety kontakt z satelitą został przerwany w wyniku błędu w oprogramowaniu komputera pokładowego.

Gdy satelita nawiązał kontakt z centrum na Ziemi, okazało się że zamiast na orbicie o wysokości 140 km nad powierzchnią Marsa, znajduje się on na zbyt niskiej orbicie o wysokości 57 km. Wkrótce potem Mars Climate Orbiter spadł na powierzchnię planety.

Analiza wypadku pokazała, że winą był program wyznaczający trajektorię lotu, który używał jako jednostki mocy niutonów (jednostki metrycznej). Program, który się z nim komunikował, działający w ramach kontroli naziemnej, przesyłał dane w postaci niemetrycznych funtów. Interpretacja funtów jako niutony doprowadziła do katastrofy.

Therac-25 to urządzenie stosowane do radioterapii nowotworów. Użytkowane było w latach 80, zaś w latach 1985-1987 było przyczyną co najmniej sześciu przypadków, w których poszkodowani byli pacjenci. Otrzymali bardzo wysoką dawkę promieniowania, większość z nich zmarła.

Przyczyną podawania błędnej dawki promieniowania pacjentom było zjawisko tzw. wyścigu (ang. race condition), które wystąpiło w oprogramowaniu urządzenia. W ściśle określonych przypadkach (których reprodukcja wymagała m.in. pracy szybkiego i sprawnego technika medycznego), dochodziło do sytuacji, w której niektóre z komponentów urządzenia nie były poprawnie zainicjowane. Powodowało to błędy odczytu i błędne sterowanie dawkami promieniowania.

Sonda Mariner 1 została wystrzelona z Cape Canaveral na Florydzie 22 lipca 1962 r., a jej lot zakończył się katastrofą po 293 sekundach. Gdy rakieta zaczęła się zachowywać bardzo dziwnie, wykonując serię bardzo szybkich i gwałtownych manewrów, sterujący lotem oficer bezpieczeństwa wydał polecenie samozniszczenia.

Przyczyną dziwnych ruchów był błędnie zaimplementowany algorytm sterujący lotem. Znalazł się w nim całkowicie trywialny błąd - programista opuścił w nim kreskę ułamka zwykłego. We współczesnej inżynierii oprogramowania błąd ten miałby szansę być wychwycony na jednym z wielu etapów pracy:

Zamknijcie oczy i wyobraźcie sobie testera oprogramowania.

Wyobraźcie sobie testera. Kogo widzicie? Zapewne siedzącego przed komputerem człowieka, który klikając i wpisując na klawiaturze różne wartości sprawdza, czy dany program działa poprawnie. Znajduje w nim błędy, lub nie. Wszystko zależy od jego samozaparcia i szczęścia.

Współczesny tester to często inżynier zajmujący się jakością oprogramowania (QA - Quality Assurance). Organizuje sobie pracę na podstawie specyfikacji oprogramowania, które testuje. Dokładnie tej samej, według której oprogramowanie piszą developerzy. Najczęściej też nie używa oprogramowania samodzielnie. Ma do dyspozycji szereg narzędzi, które pozwalają mu zaprogramować testy automatyczne. Tak – zaprogramować. Praca współczesnego inżyniera testów nie różni się aż tak bardzo od pracy programisty.

Na pytania, co tak naprawdę robią inżynierowie zajmujący się jakością, najlepiej odpowie praktyk. O uporządkowanie tych pojęć poprosiliśmy Sebastiana Chmielewskiego, trenera w firmie Sages, zajmującej się m.in. prowadzeniem zajęć w ramach bootcampu dla testerów pod szyldem Kodołamacz.

Tester musi wiedzieć więcej od tworzących oprogramowanie programistów. Musi potrafić nie tylko stworzyć sobie scenariusz testowania, ale także napisać skrypty, które zapewnią testy poszczególnych punktów wymagań. Musi również znać się na bazach danych - testowanie aplikacji na pustej bazie niewiele przecież da, jeśli błąd może się okazać wykrywalny jedynie przy większym obciążeniu aplikacji danymi. Istnieją też odpowiednie narzędzia, których używania trzeba się nauczyć.

Wśród wymaganej wiedzy jest też znajomość narzędzi do continuous integration, czyli takich, które umożliwiają stworzenie testowalnego środowiska na podstawie zawsze najnowszej wersji kodu źródłowego.

Tego wszystkiego - i jeszcze więcej - można nauczyć się uczestnicząc w bootcampie Tester automatyczny, który prowadzony jest w ramach programu Kodołamacz. Przeznaczony jest on zarówno dla testerów manualnych, którzy chcieliby poszerzyć swoje kompetencje, jak i dla osób, które dotąd nie zajmowały się testowaniem.

W ciągu intensywnego, blisko dziewięciotygodniowego bootcampu uczestnik pozna szczegółowo metody pozyskiwania wymagań do testów, planowania ich przebiegu oraz narzędzia do testów funkcjonalnych takie jak Selenium czy SoapUI. Po zakończeniu szkolenia będzie biegły w automatyzacji czynności testowych oraz będzie potrafił programować w stopniu wystarczającym do realizacji zadań testera automatycznego.

Dla wielu testerów kontakt z QA (Quality Assurance, czyli kontrolą jakości) to pierwszy krok w karierze związanej z tworzeniem oprogramowania. Wielu programistów wywodzi się z bycia testerem. To często kolejny logiczny krok w ich ścieżce rozwoju. Możliwy jest również rozwój zawodowy w ramach bycia testerem. Większe projekty wymagają bowiem zarządzania testami i przygotowania dużych scenariuszy realizowanych przez cały zespół.