środa, 28 września 2016

Dreszczowiec o braku analizy biznesowej

Oto dreszczowiec. Gdyby zrobić porządną analizę biznesową i zarządzać procesami biznesowymi, nie byłoby całej historii...
  

Miałem wracać z Rzymu samolotem do Warszawy. Po kiepskich wcześniejszych doświadczeniach w firmą „Terravision”, w drodze z lotniska do Rzymu, postanowiłem działać ostrożnie i systematycznie, aby tym razem uniknąć kłopotów.

O dziwo, sklep internetowy tej firmy okazał się mieć zadziwiająco prosty, intuicyjny z zrozumiały interfejs, choć doświadczenie z tego typu portalami kazało się spodziewać trudnej do pokonania przeszkody.

Światełko ostrzegawcze zapaliło się w mojej głowie dopiero wtedy, gdy system poinformował mnie, że przed wejściem na pokład autobusu, będę musiał bilet wymienić w kasie na kartę pokładową. To raczej zbędna oraz idiotyczna komplikacja, skoro bilet kupuję na konkretną trasę i godzinę, ale co tam: nie spodziewajmy się Rolls-Royce’a, kupując usługę za cztery euro.

Przybywszy dobrze przed czasem do miejsca wskazanego na bilecie jako „Terravision Café” – znów lekkie zaniepokojenie wywołała we mnie wcześniej sama absurdalna nieadekwatność tej nazwy do spodziewanej poczekalni i kilku kas – poczułem, jak mętna obawy zamieniają się w zimne przerażenie:

Poczekalnię szczelnie wypełniała wijąca się kolejka podróżnych, pragnących kupić bilety, dokładnie przemieszanych z osobami chcącymi, tak jak ja, wymienić swoje bilety na karty pokładowe. Oczywiście, okazało się, że cały ten system był potwornie niezdarny, najzupełniej zbędny i kłopotliwy dla wszystkich, zarówno dla pasażerów, jak i do wyraźnie zirytowanych panienek w kasach. Zirytowany pracownik obsługi klienta! – czy muszę wyjaśniać, że takie zjawisko świadczy o tym, że w firmie są duże, duże problemy?

Odczekawszy swoje, będąc już w pobliżu kasy, dojrzałem ręcznie napisaną kartkę formatu A4, informującą, że osoby, które nie kupują biletu, lecz wymieniają go na kartę pokładową, mogą ominąć kolejkę. Pomysł i rozwiązanie, będące swoistym rekordem bezmyślności i wzorcem, jak odpowiednio zły proces zamienia życie wielu tysięcy ludzi w piekło.

Stojąca przede mną w kolejce para starszych Szwedów chciała kupić bilety na następny dzień, aby dowiedzieć się od wyraźnie zdegustowanej ich niewiedzą ciemnowłosej i obrażonej kasjerki, że bilety można kupić dopiero… 30 minut przed planowanym odjazdem. Nie wspomniała – po co się wysilać przy wykonywaniu marnie płatnej pracy w procesie, zaprojektowanym tak, aby zmaksymalizować uciążliwość? – o dostępności biletów przez Internet.

Ściskając wreszcie cenną kartę pokładową w spoconej dłoni, już z pewną obojętnością potraktowałem informację, że mój autobus odjedzie z 20-minutowym opóźnieniem. Informację przekazaną ustnie, rzecz jasna: jakieś tablice świetlne czy ostatecznie ogłoszenia z głośników widać uznano za zbędne ułatwienia.

- Gdzie znajdę przystanek? – zapytałem, bo oprócz skłębionego tłumu zdenerwowanych ludzi, żadnego oznaczenia nie dostrzegłem.

- Bezpośrednio przed wejściem – odpowiedziała panienka, wskazując niedbałym gestem ten właśnie niepokojący mnie tłum.

Przyłączyłem się więc do tłumu, zastanawiając się i wielojęzycznie dopytując, jak zidentyfikować koniec kolejki i jak odróżnić od siebie kolejkę do autobusu na lotnisko Fiumicino od tej na Ciampino. Żadnych tabliczek, oczywiście, nie było.

   

Kiedy wreszcie pojawił się opóźniony, jeszcze nie mój, autobus, rozpętała się grecka tragedia. Jak już zauważyłem kilka dni wcześniej, genialny pomysł, by przystanek dla wysiadających umieścić w tym samym miejscu, co dla wsiadających, cudownie podnosił wszystkim poziom adrenaliny. Gratulowałem sobie, że wykazałem się zmysłem obserwacji, bo cel podróży autobus miał wypisany małymi literkami tylko z przodu, a boki autobusu zdobił zamaszysty i zupełnie bezużyteczny napis: „Rzym <-> Fiumicino / Rzym <-> Ciampino”. 

Tragedia szybko przeistoczyła się w horror, gdy zniecierpliwieni i zdesperowani pasażerowie usiłowali wsiąść do autobusu. Niektórzy nie mieli biletów i sądzili, że kupią je – jak to bywa na świecie – u kierowcy, inni nie wymienili biletów na karty pokładowe, inni dopytywali, na które lotnisko autobus pojedzie, a niektórzy – obciążeni wielkimi walizami – pytali, gdzie mają włożyć bagaż. Pomocnik kierowcy zaczął wrzeszczeć, a kierowca spokojnie, na oczach wszystkich, palił sobie zasłużonego papierosa.

Wrzeszczący pomocnik zrobił jedną dobrą rzecz: polecił pasażerom uformować dwie osobne kolejki, jedną do Ciampino, a drugą do Fiumicino. Gdyby na miejscu był ktoś myślący, mógłby to napoleońskie, czy może raczej salomonowe, rozwiązanie utrwalić, oznaczając na stałe dwie osobne kolejki, ale wątpię, czy osoba upoważniona do tak strategicznych decyzji była w pobliżu. 

    

Zapewne strategiczni szefowie gadali, jak to zwykle bywa w firmach, o wizjach, misjach i strategiach, a z powstałym bałaganem radzili sobie, lepiej lub gorzej (raczej gorzej niż lepiej), szeregowi pracownicy. Zjawisko to dobrze znamy ze świata IT! Żegnaj, Kaizen! Żegnaj, TQM! Żegnaj, systemie Toyoty! Żegnajcie, Juranie i Demingu! W „Terravision” albo o was zapomniano, albo nie słyszano zupełnie.
    
Kiedy wiele minut i morze zdenerwowania później uznałem, że moją jedyną szansą pozostaje taksówka, doświadczyłem jeszcze więcej fascynujących przeżyć. Już idąc szybkim krokiem w kierunku postoju taksówek, usłyszałem za sobą krzyki jakiejś pracowniczki „Terravision” (wrzeszczeć, to oni w tej firmie umieją! takie to, widać, u nich "zarządzanie kryzysowe" i "przywództwo"), że autobus spóźni się kolejne 30 minut z powodu niezwykłych korków na drogach. Rzym Rzymem, ale już jadąc taksówką w stronę lotniska, naocznie przekonałem się, że ruch sunął dość płynnie, co potwierdził także taksówkarz. A więc, prostackie kłamstwo… na dobitkę.
    
Potem przyszło mi stawić czoła rzymskim taksówkom. Otóż zobaczyłem tam niezwykłe zjawisko: to nie taksówki czekały na pasażerów, lecz pasażerowie na taksówki! Odmłodniałem nagle o ponad trzydzieści lat i znalazłem się ponownie w PRL-u, gdzie taksówki, jak wszystkie zresztą usługi, były dobrem wielce deficytowym, a jego dysponenci, na których czekali posłusznie i grzecznie klienci, mogli być aroganccy, niechlujni, nieuprzejmi.
   
Domyśliłem się, że to pewnie rzymska korporacja, związek zawodowy czy inna mafia taksówkarzy zdołała ograniczyć dostęp do kontrolowanego przez siebie zajęcia, co zapewniło im luksus nieustającego rynku dostawcy, nie klienta. Przez chwilę, zanim moja regresja dopełniła się, biegałem bezradnie między początkiem i końcem postoju, podczas gdy nadjeżdżające taksówki zatrzymywały się, gdzie chciały, ale w końcu moje stare, komunistyczne umiejętności wzięły górę i bez wahania ustawiłem się na ulicy, gdzie szybko złapałem taksówkę, zanim jeszcze dotarła do postoju.

 



sobota, 24 września 2016

Pan Tadeusz

Podstawowy Proces Testowy ISTQB jako XIV Księga "Pana Tadeusza"

Sensacja - odkryto zagubiony rękopis Adama Mickiewicza!



Natenczas Wojski wyjął na taśmie przypięty,
PROCES TESTOWY - długi, cętkowany, kręty.
Wciągnął oddech głęboki – zaczął PLANOWANIE,
Kombinując, co, komu i kiedy się stanie.
Myślał o środowisku, myślał o myśliwych,
O nagonce, o strzelbach i o chartach chyżych.
Co pomyśli, zapisze, chociaż aż się słania
Z wysiłku, w wielkim PLANIE POLOWANIA.

Po cóż ten plan Wojskiemu? Po cóż tak się trudzi?
Cóż, Wojski stary lubi OBSERWOWAĆ ludzi,
Czyli MONITOROWAĆ: gdzie który myśliwy,
Czy ma jeszcze daleko; czy zwierz jeszcze żywy,
Czy Sędzia, główny sponsor, będzie rad z wyniku?
Patrzy – a Hrabia bieży, jedzie na kucyku.

Wojski, widząc spóźnienie, gromko wnet zawoła:
„Hrabio, zajeżdżaj wasze, zajeżdżaj od czoła!”
Tak Wojski NADZORUJE, myśliwych przestawia,
Nagonkę pokieruje, tam, gdzie stoi Hrabia.

Pora ANALIZOWAĆ. Wojski grubą księgę
Czyta, a wokół szczwacze stoją ciasnym kręgiem.
Księga ta stara, zwana PODSTAWY TESTOWE,
Służyła dawniej królom, a dzisiaj gotowe,
Wojski z niej projektuje WARUNKI TESTOWE,
Czyli co trzeba sprawdzić, jak bardzo i kiedy,
Przetestować, myśliwskiej by nie zaznać biedy.

Z tych WARUNKÓW TESTOWYCH, przemyślni myśliwi
Tworzą różne PRZYPADKI; bardzo są gorliwi,
Wciąż PRZYPADKI TESTOWE opisują żwawo
Zasiadłszy na polanie, porośniętej trawą.
I gotowe! PRZYPADKÓW SPECYFIKACYA
Idzie w krąg, a tam Wojski już fuzję nabija.

Pora IMPLEMENTACJI! Strzelby nabijają,
Chcą gonić, strzelać, łowić w nadniemeńskim kraju.
PROCEDURY TESTOWE wsadziwszy za pasy
Ruszają strzelcy w bory, mokradła i lasy.
Z tych PROCEDUR, ZESTAWY kręcąc nader zgrabnie,
Niczym łapcie, iść mogą i nie grzęznąć w bagnie.

Idą; broń grzmi, zwierz pierzcha. W trawach ślady sarnie
Widać, wyraźne, niczym sofware’u AWARIE.
Za tymi awariami pilnie śledząc ślady
Czujny ogar wytropi i dopadnie BUGI.
To TESTÓW WYKONANIE. Wrzawa, krzyki, strzały!
Każdy strzelec jest dzielny, zwinny i zuchwały.
Już wieczór. „Chyba dosyć, dosyć już mospanie,
Może pora już kończyć i iść spać na sianie?”
„Na sianie?” – krzyknął Wojski. „Ależ, asińdzieju,
Czyżbyś asan się uchlał, czy najadł szaleju?
Jakże nam łów zakończyć: musimy KRYTERIA
ZAKOŃCZENIA wpierw SPEŁNIĆ, bez tego mizeria,
Bez tego szlachcic polski nie wróci do domu,
Zhańbiony, bez RAPORTU, zgoła po kryjomu!”
Więc dalej do niedźwiedzi, do dzików, zajęcy,
Aż im nabojów zbrakło – już nie mogą więcej.
Pozbierawszy zwierzynę, RAPORT ZAKOŃCZENIA
ŁOWÓW jeszcze napiszą – i już do widzenia!

Strzelcy na siano, pospać, lub do dom jechali,
Ale Wojski wciąż nie śpi i pracuje dalej.
Zwierzynę nieść do kuchni, strzelby czyścić każe.
Uwijają się sługi, czeladź i kucharze.
Miesiąc na niebo wyszedł, nawet Wojski drzemie.
Nastało w Soplicowie TESTÓW ZAKOŃCZENIE.


sobota, 17 września 2016

Testowanie systemów krytycznych dla bezpieczeństwa, wbudowanych i czasu rzeczywistego


Spis treści

Uwaga: to jest długi artykuł. Śpieszysz się? 
Najpierw obejrzyj tę animowaną prezentację:
 

  • Testowanie systemów krytycznych dla bezpieczeństwa, wbudowanych i czasu rzeczywistego. 1
  • Wprowadzenie do tematyki 3
  • Testowanie systemów krytycznych da bezpieczeństwa. 4
  • Skąd wybór tematu?. 5
  • Specyfika testowania systemów wbudowanych. 5
  • Na wielu platformach testowych. 6
  • Projektowanie aplikacji pod kątem możliwości testowania, również na środowisku docelowym.. 6
  • Równoległe projektowanie, tworzenie i testowanie sprzętu i aplikacji 7
  • Stosowanie języków niskopoziomowych, które wymagają od programistów dużej staranności i unikania błędów.. 8
  • Ze względu na ograniczoną dostępność testów w środowisku docelowym.. 8
  • Pełny nadzór, co jest testowane, w jakim środowisku. 9
  • Bardzo dokładne planowanie. 9
  • Używanie narzędzi, programistycznych i sprzętowych, umożliwiających bardzo dokładny oraz niskopoziomowy nadzór nad przebiegiem testów oraz ich wynikami 10
  • Bliskie związki testowania z debugowaniem, na dobre (współpraca) i złe (możliwa rywalizacja o dostęp do środowiska) 11
  • Nowość – testowanie zdalne przez łącze internetowe. 11
  • Jakie specjalne testy stosuje się dla systemów czasu rzeczywistego?. 14
  • Testy szybkości oraz czasowej przewidywalności nie tylko aplikacji, lecz również platformy sprzętowej i systemu operacyjnego. 14
  • Długotrwałe testy stabilności 14
  • Testowanie poprawności implementacji wymagań czasowych. 15
  • Testowanie niezawodności (MTBF) 15
  • Testowanie systemów krytycznych dla bezpieczeństwa. 16
  • Normy – warto je poznać. 16
  • Nacisk norm na zapobieganie, nie tylko na testy. 18
  • SIL a testowanie. 18
  • Jeszcze o testach systemów krytycznych dla bezpiueczeństwa. 18
  

Wprowadzenie do tematyki

Systemy wbudowane (albo: systemy kontrolne) = embedded systems (control systems), systemy krytyczne dla bezpieczeństwa = safety-critical systems, systemy czasu rzeczywistego (albo rzadziej: systemy nadążne) = real-time systems. Systemy krytyczne dla bezpieczeństwa są z reguły systemami wbudowanymi, wiele z nich jest także systemami czasu rzeczywistego.
 
Nie rzucają się w oczy tak, jak obecne wszędzie laptopy, tablety i smartfony, ale naprawdę jest ich znacznie od nich więcej: systemów wbudowanych, sterujących dziesiątkami miliardów urządzeń: pralek automatycznych, pomp paliwowych, samochodów, wind, instrumentów medycznych, robotów przemysłowych, statków i samolotów.
 
Nie pisze się o nich tak wielu socjologicznych dysertacji jak o Facebook ’u, Twitterze i Google, ale zmieniają one świat, w którym żyjemy, o wiele bardziej: systemy krytyczne dla bezpieczeństwa, którym codziennie – nie myśląc o tym – powierzamy i zawdzięczamy nasze życie i zdrowie.
Nie generują takiej masy tajemniczo brzmiącej terminologii jak wielkie zbiory danych (big data), ale to one właśnie tworzą większość tej oszałamiającej masy danych: systemy czasu rzeczywistego, pozwalające elektronice i oprogramowaniu reagować na zmiany środowiska niemal tak zwinnie i szybko, jak organizmy żywe, dzięki czemu świat zaludniają już dziś miliardy robotów, wykonujących zamiast ludzi prace szczególnie uciążliwe, trudne i niebezpieczne.
 
Firmom, tworzące produkty zawierające takie właśnie systemy - choć nie jest o nich tak głośno jak o informatycznych molochach, tworzących nieporadne systemy IT, które nam wszystkim utrudniają życie – tym firmom właśnie zawdzięczamy w ogromnym stopniu sukcesy polskiej gospodarki, eksportującej coraz skuteczniej wysoką technologię światowej klasy.
Awarie systemów krytycznych dla bezpieczeństwa są szczególnie tragiczne i bolesne. Przyczyną tej i wielu podobnych awarii nie była jednak zawodność technologiczna, lecz nieumiejętność uwzględnienia w ich projektowaniu czynników psychologicznych, przez co wzrasta ryzyko niepoprawnych działań ich operatorów, zwłaszcza w stresie. 
 
Ponieważ konsekwencje nieprawidłowego działania (awarii) systemów krytycznych dla bezpieczeństwa są bardzo wysokie, gdyż mogą oznaczać śmierć lub zranienie ludzi, dlatego proces ich tworzenia ma służyć zminimalizowaniu ryzyka (prawdopodobieństwa) awarii.
Mówiąc bardzo ogólnie, oznacza to wymaganie, żeby proces tworzenia takich systemów był staranniejszy niż proces tworzenia mniej krytycznych systemów. Z reguł te wymagania wobec procesu określają specyficzne dla danej branży normy / standardy. Te standardy określają zarówno wymagania bezpieczeństwa wobec produktu, jak i wymagania wobec procesu jego tworzenia, a także określają, w jak sposób producenci muszą udowodnić spełnienie tych wymagań.
 
Zasady inżynierii wymagań dla takich systemów nie różnią się zasadniczo od tych, które obowiązują dla innych systemów, ale muszą być w pełni przestrzegane, oraz wymagana jest możliwość potwierdzenia i udowodnienia, że są rzeczywiście przestrzegane.
 
Wymagania specjalne dla systemów krytycznych dla bezpieczeństwa są dwóch rodzajów: wymagania wobec produktów, oraz wymagania wobec procesu ich wytwarzania. Dla znakomitej większości tego rodzaju produktów istnieją międzynarodowe, obszerne i drobiazgowe normy, określające, jakie wymagania mają być spełnione, jakimi metodami i w jaki sposób musi się być w stanie potwierdzić ich przestrzeganie.
  

Testowanie systemów krytycznych da bezpieczeństwa

Testowanie systemów krytycznych da bezpieczeństwa spełnia dwa podstawowe zadania: jest dowodem na to, że gotowy system rzeczywiście ma określoną wymaganiami funkcjonalność, niezawodność oraz inne, znaczące dla bezpieczeństwa atrybuty jakości, oraz służy wykrywaniu defektów systemu, dzięki czemu możliwe jest ich usunięcie i osiągnięcia wymaganego poziomu jakości.
 
Nie wszystkie decyzje dotyczące wymaganej staranności testowania oraz jego metod pozostawione są producentom – wiele z nich określają standardy dla produkcji danego rodzaju systemów.
Temat tego artykułu można by równie dobrze rozszerzyć na trzy obszary naraz: 1) testowanie systemów wbudowanych, 2) krytycznych jeśli chodzi o bezpieczeństwo oraz 3) czasu rzeczywistego, lub ograniczyć do ich części wspólnej – dość obszernej. Dodatkowo, możliwe byłoby omówienie osobno testowania oprogramowania, a osobno – platformy sprzętowej. Dla wielu systemów wbudowanych, złożoność, krytyczność i czasochłonność testowania zarówno elektroniki, jak i części mechanicznych systemu są znacznie bardziej wymagające, więc i ciekawsze, niż testy oprogramowania.
 
Ze względu na profil konferencji „Testwarez”, dla krórej artykuł został napisany, jak i na dostępny czas, nasz wybór padł na omówienie specyfiki testów wyłącznie oprogramowania, osobno dla aspektu wbudowania, osobno dla aspektu działania w czasie rzeczywistym, a osobno dla aspektu krytyczności dla bezpieczeństwa, choć oczywiście wiele konkretnych systemów jest jednocześnie wbudowanych, i krytycznych, i działająca w czasie rzeczywistym zarazem.
 

Skąd wybór tematu?


Ta tematyka jest ogromnie znacząca. Choć systemy wbudowane + krytyczne, które omawiam, to dziś ponad 60% systemów na świecie, a ich znaczenie dla jakości i bezpieczeństwa życia jest jeszcze większe, to ich specyfika jest osobom mieniącym się „testerami” zwykle nieznana. Z drugiej strony, nasi koledzy stamtąd, choć merytorycznie łączy nas niemal wszystko, naszych fascynacji i konferencji nie podzielają: mają swoje. Tester oprogramowania sterującego, na przykład, mechanizmem ABS hamulców samochodowych, ma za kolegów inżynierów z branży motoryzacyjnej, a nie innych testerów oprogramowania.
 
My, testerzy „niewbudowani” i „niekrytyczni”, możemy się od nich bardzo wiele nauczyć – i na to staramy się położyć nacisk w naszej prezentacji. Oni od nas też, ale to temat na inną konferencję, która dopiero się odbędzie.
   

Specyfika testowania systemów wbudowanych

Znacie model Kano? Nie, skądże, więc go streszczę: to jest taki kluczowy dla osób mieniących się odpowiedzialnymi za jakość model, dzielący wymagania na trzy grupy: na (1) wymagania zwykłe, na (2) „zachwycacze” i na (3) „rozwściekacze”.
 
Zachwycacze to te, których niespełnienie nikomu specjalnie nie doskwiera, ale kiedy choć w części się je zrealizuje, wywołują efekt wielkiego WOW. Te wymagania są ważne dla takich produktów IT, których zawodność i zwykłe bugi są do zaakceptowania, ale atrybut trafnie nazwany przez Jamesa Bacha „charyzmą”, choćby dostępny tylko trochę, zaraz wywołuje lawinę lajków. Do nich zaliczają się gadżety, telefony, gry, wszelkie fejsbuki, twitery oraz instagramy, a nawet zupełnie normalne aplikacje internetowe: sklepy, portale informacyjne i plotkarskie, i te pokazujące pogodę.
 
Natomiast dla systemów wbudowanych / krytycznych dominują rozwściekacze: cechy, których płynnego działania wręcz nie zauważamy, ale najmniejsze potknięcie ciężko przeżywamy, albo i nie przeżywamy, jeśli zawiedzie na przykład ABS w hamulcach, czy system sterowania ruchem kolejowym, czy rozrusznik serca. One są jak powietrze, dlatego ci, którzy je testują, są cisi, solidni, mało mówią i dobrze pracują, i mało mają czasu na uleganie mistycznym modom typu XP, TDD, eksploracja i inne. Kto się nie lansuje, tego nie ma?
  

Na wielu platformach testowych


Autorzy wielu programów już od pierwszej udanej kompilacji mogą je testować w środowisku docelowym. Budujący wielkie systemy administracyjne, czy bankowe, są w nieco gorszej sytuacji, ale i tam dostęp do środowiska ograniczają raczej względy organizacyjno-biznesowe, a nie bezwzględna, fizyczna niemożność.
 
Kiedy tworzy się (nie chce mi przejść przez wargi to komiczne nowe słówko „rozwija się”, oprogramowanie to nie nitka na szpulce) nowe urządzenie, wówczas nie można z pisaniem mającego nim sterować oprogramowania czekać, aż wszystko inne będzie gotowe, bo to by po pierwsze, strasznie przedłużyło cały projekt, a po drugie, częściowo działające oprogramowanie potrzebne jest także, aby pomóc testować sprawność samej platformy (elektronicznej, mechanicznej, hydraulicznej, cokolwiek tam mamy). Testuje się je więc wielokrotnie, zmieniając miejsca po drodze: najpierw na miękkim symulatorze procesora, albo i reszty całego układu, potem na tak zwanej karcie testowej (właściwy mikroprocesor, brak całej reszty), potem na właściwej karcie, ale jeszcze bez systemu, którego będzie częścią, wreszcie w gotowym systemie, ale ostrożnie: tak, by nikogo nie zabił, ani sam nie wyleciał w powietrze.
 
Praca domowa: jaki ma to wpływ na proces testowania, i czego możemy pozazdrościć i naśladować?
 

Projektowanie aplikacji pod kątem możliwości testowania, również na środowisku docelowym


Dla wielu, wielu z nas – testerów – propozycja, by stymulować system inaczej, niż przez klawiaturę, myszkę albo ekran dotykowy, a wyniki testów oglądać inaczej, niż na ekranie czy innym wyświetlaczu, jest niemal obrazoburcza. Jeśli wykonujemy test „INSERT Jan Kowalski”, to jak sprawdzamy jego wynik? Albo system sam uprzejmie wyświetla na ekranie „Jan Kowalski INSERTED”, a my w to wierzymy, albo robimy „FIND Jan Kowalski”, i… również wierzymy. Ale urządzenia wbudowane często nie mają ekranu, myszki, ani klawiatury. Niech nas nie zmyli smartphone: ma om wprawdzie wyświetlacz i ekran dotykowy, ale tylko do niektórych funkcji, cała reszta jest gołym okiem i gołym palcem niedostępna.
 
Co wtedy? Trzeba sięgać po przemyślne, czasem niełatwe w obsłudze narzędzia, twarde lub miękkie, dające nam dostęp do niewidocznych czeluści w głębi gadżetu. Dodatkowo, warto od samego początku ten gadżet i jego oprogramowanie projektować tak, żeby ten dostęp ułatwić, w przeciwnym razie będą kłopoty. Nam zdarzyło się nawiercać nieprzebijalne obudowy, lutować dodatkowe druciki na karcie, a na nich diody, żeby móc mierzyć chytrze schowany sygnał, a nawet mocować przylepcem czujniki urządzeń pomiarowych na dolnej stronie karty o dwustronnym montażu J. Efekt? Następnym razem, będzie się projektować tak, żeby nie utrudniać niepotrzebnie przyszłych testów. Jakie z tego warto wyciągnąć lessons learned?
 

Równoległe projektowanie, tworzenie i testowanie sprzętu i aplikacji


Kiedy w 1998 roku usłyszeliśmy po raz pierwszy o certyfikacji ISEB (tak się nazywał bezpośredni przodek ISTQB), wrażenie na nas zrobiła zarówno marketingowa genialność tego prostego pomysłu, jak i szereg podstawowych błędów w sylabusie. Notabene, nikt ich nie poprawił do dziś. Szczególnie efektowny jest najzupełniej niepoprawny, rażąco niefrasobliwy i głęboko wprowadzający w błąd podział testów na „czarną skrzynkę” i „białą skrzynkę”. Czemu niby biała skrzynka zatrzymuje się na poziomie kodu źródłowego aplikacji, skoro poniżej jest mnóstwo poziomów, będących dla przeciętnego programisty najprawdziwszą czarną skrzynką?
 
Budując urządzenie, nawet tak proste, jakie tkwi w pralce za 699 złotych, nie programuje się, i wobec tego nie testuje, chyba tylko mikroprocesora. Piętro wyżej jest ASIC – układ scalony wykonany specjalnie na potrzeby danego urządzenia. To droga rzecz, więc akurat w pralce raczej go nie zobaczymy. Testy jego projektu (symulowanego prototypu) spadają wprawdzie na inżyniera-elektronika, ale są to identyczne testy, jak nasze, miękkie. No, solidniejsze. Jednak potem taki ASIC jeszcze dodatkowo dotestowuje się na karcie, i tutaj nasz inżynier często prosi testera-programistę o napisanie specjalnie do tego celu dedykowanych kawałków kodu.
 
Kolejny poziom, to układy programowalne (FPGA). To z punktu widzenia testów to samo, co ASIC, tyle że mniej kosztowny i dający się łatwo przeprogramować. Typowe testowanie, takie samo, jak oprogramowania. Bezprzedmiotowość pytania, czy to biała, czy czarna skrzynka, rzuca się w oczy.
Programowaniem PROM zajmuje się już zwykle programista. Wiele systemów wbudowanych ma wyłącznie to oprogramowanie. Można je zmieniać, ale nie po dostarczeniu klientowi.
Testowanie na co najmniej czterech poziomach. Jednoczesne. Wnioski?
 

Stosowanie języków niskopoziomowych, które wymagają od programistów dużej staranności i unikania błędów


Może i Ruby wymyślono po to, by – cytuję – zapewnić szczęście programistom, ale wszystkie języki wysokopoziomowe, obudowane uszczęśliwiającymi środowiskami, powodują, że nie wiadomo, co tak naprawdę dzieje się w systemie. To wyklucza je z zastosowania dla systemów czasu rzeczywistego. Ponadto, są ogromnie zasobo-chłonne i pamięciożerne, co wyklucza je z wielu systemów wbudowanych. Trzeba pamiętać, że pamięć nie tylko kosztuje (dziś już niewiele), ale zajmuje miejsce i, co najgorsze, grzeje. Kto chciałby mieć kilkadziesiąt psujących się wentylatorków w samochodzie?
 
Czyli wracamy na poziom C++, C i asemblera. To, w połączeniu z wymaganiami niezawodności, odświeża, tak niemiłosiernie wydrwione przez Mistrzów Javy i innych miłośników kreatywności, znaczenie analizy statycznej oraz pomiarów pokrycia testowego kodu.
 
I powraca też staranne testowanie, także pod kątem braku bugów, a nie tylko UX (user experience), charyzmy i doświadczeń mistyczno-ludycznych.
 

Ze względu na ograniczoną dostępność testów w środowisku docelowym


Znacie te pięknie brzmiące zasady: nie paraliżować projektu zbyt precyzyjnymi wymaganiami, dostarczać MVP (minimalny możliwy produkt, minimum viable product), wyjść jak najwcześniej z częściowym choćby produktem do ludzi i w bezpośredniej interakcji z nimi sprawdzić, czy produkt im się podoba. Tak, mamy na myśli ten produkt wbudowany, pocisk typu cruise
 
Pośmialiśmy się? To dobrze, bo tak, jak groteskowo śmieszne jest stosowanie zasad budowania rakiet do tworzenia rozrywkowych portali, równie śmieszna – czy może tragiczna? – byłaby sytuacja odwrotna. Każde wbudowane oprogramowanie dla złożonego i potencjalnie niebezpiecznego systemu musi być w jakimś sensie zintegrowane skokowo – w pewnym momencie wszystko nagle musi działać.
 
To wymaga umiejętności testowania po kawałku, w różnych środowiskach symulowanych, oraz takiego projektowania testów integracyjnych, by uniknąć losu tej międzyplanetarnej misji, gdzie wstrząs wywołany rozłożeniem nóg lądownika wyłączył hamownice, lub tej, gdzie jeden system zaprogramowano w metrach, a drugi – w jardach.
 
Umiejętność realizacji stopniowych, wielopoziomowych testów integracyjnych tak, aby na koniec procesu wszystko chodziło jak w zegarku, może się przydać budowniczym nie tylko rakiet, ale też innych produktów.
 
Przy okazji – wbrew obiegowym opiniom, to nie wyklucza realizowania takich projektów częściowo w trybie agile, na poziomie, gdzie pracuje się w środowisku symulowanym.
 

Pełny nadzór, co jest testowane, w jakim środowisku


To jest kwestia organizacyjna, nie techniczna. Skoro testowanie przychodzi wykonywać w kilku różnych środowiskach, to po przemnożeniu liczby kombinacji przez liczbę regresji, otrzymuje się wynik wskazujący, że warto to dobrze zaplanować i podzielić, by uniknąć zarówno niebezpieczeństwa pominięcia tego, co przetestować należało, jak i niepotrzebnego i kosztownego dublowania. Czyli – nie wykluczając pewnego wykorzystania testów eksploracyjnych, jako możliwego uzupełnienia – testy trzeba starannie zaprojektować i opisać zawczasu, i odpowiednio je rozplanować w czasie.
 
W sytuacji, gdy koszty wykonywania każdego z testów są znaczne, bo sumują się koszty tak samych środowisk, jak i czasochłonnego ich wykorzystania, nie mamy ochoty przedłużać tego kosztownego procesu, wykrywając potrzebne wymagania, testując na chybił-trafił, metodą prób i błędów.
Systemy wbudowane likwidują w pewnej mierze charakterystyczną cechę oprogramowania, czyli względną taniość (czasem złudną!) wykonywania zmian, w porównaniu z branżami, działającymi w mniej plastycznej materii. To powoduje, że wyraźniejsza niż na innych obszarach IT staje się przewaga zapobiegania, zamiast naprawiania, jako sposobu osiągnięcia potrzebnej jakości.
 

Bardzo dokładne planowanie


Dla oprogramowania wbudowanego maleje, czasem znika zupełnie zasada, żeby jak najszybciej wejść z pierwszą wersją na rynek i zdobyć klientów, a potem dostarczać kolejne wersje.
Nie tylko koszty awarii bywają kosmiczne, ale możliwości naprawy w tak zwanym środowisku produkcyjnym, może w ogóle nie być.
 
Krzywa Boehma, w czasach sekwencyjnych oficjalnie poważana, ale w praktyce ignorowana, w czasach iteracyjno-zwinnych doczekała się słusznych, także teoretycznych zastrzeżeń, że wypacza obraz biznesowej opłacalności starań o zdobycie precyzyjnych wymagań z góry, mówiąc tylko o kosztach zmiany/naprawy, a pomijając koszty, czy wręcz niemożność, uzyskania dobrych wymagań na samym początku, bez prototypowania. Niemniej, nie oznacza to, że krzywa Boehma przestała obowiązywać, a systemy, które wysyłamy na inne planety, na dno Rowu Mariańskiego, czy nawet tylko 200 metrów pod powierzchnię morza i platformy wiertniczej, mocno nam o tym przypominają.
 

Używanie narzędzi, programistycznych i sprzętowych, umożliwiających bardzo dokładny oraz niskopoziomowy nadzór nad przebiegiem testów oraz ich wynikami


Jak już pisaliśmy, tradycyjny, miękki tester, z trudem uznaje potrzebę stosowania innych narzędzi do wprowadzania i rejestrowania wychodzących z systemu danych, niż myszka, klawiatura, joystick, ekran i głośniki. Niemniej, wykonując testy, dajmy na to, odporności systemu na burze piaskowe, pewnie weźmie do ręki dmuchawę piasku, jednak z poczuciem, że to trochę śmieszne i niepoważne narzędzie… w porównaniu z takim Selenium, JTest, JMeter, Quality Center, albo Cucumber!
Natomiast narzędzia sprzętowe, elektroniczne, budzą zwykle u miękkiego testera podziw, ale i przerażenie, niczym operacja na otartym sercu, zaproponowana wizażyście.
 
Testerzy oprogramowania wbudowanego muszą się jednak nimi posługiwać, żeby w ogóle móc testy uruchomić, ale też żeby wiedzieć, co ono tam w środku porabia. Czym różni się wynik 9 od wyniku 8, ale nie na ekranie, bo go nie ma, tylko na 4-bitowej magistrali? 9, to binarne 1001, zaś 8, to binarne 1000 – różni je wartość bitu po prawej stronie. Można to zmierzyć – nie bójmy się brzydkiego słowa – oscyloskopem!
 
To samo zadanie, tylko w drugą stronę – jak bez klawiatury wepchnąć do środka maszyny wartość 7? No cóż, trzeba nałożyć 3V napięcia na następujące bity: 0111. To umożliwia generator sygnałów.
To samo zadanie, co oscyloskop, ale jednocześnie dla całej magistrali adresowej, danych lub instrukcji, wykonuje analizator logiczny.
 
ICE – debuger sprzętowy – pozwala do celów testowania dokładnie widzieć i manipulować czynnościami mikroprocesora.
 
JTAG (skrót ładnie brzmiącej nazwy Joint Testing Action Group) służy do testów prawidłowości podłączenia układów scalonych, ale przydaje się i testerom.
 

Bliskie związki testowania z debugowaniem, na dobre (współpraca) i złe (możliwa rywalizacja o dostęp do środowiska)


Poprzedni akapit pokazał urządzenia, w pierwszym rzędzie służące do debugowania, jako groźne narzędzia testerskie. To prawda – każde z nich wykorzystuje do badania tego, co dzieje się wewnątrz komputera zarówno inżynier-elektronik, jak i programista, szukający przyczyny awarii.
 
Programista systemów wbudowanych pracuje w środowisku innym, niż docelowe. Bugi, powodujące awarię w środowisku docelowym, też nie zawsze ujawniają się w symulowanym. Wobec tego debugowanie musi się czasem odbywać w środowisku docelowym. O ile symulowane daje się niedrogo powielać, o tyle docelowe bywa kosztowne i odstęp do niego staje się towarem „deficytowym”, jak mawiano w czasach PRL. Wtedy dostęp do niego trzeba racjonować, stosować listy kolejkowe, pilnować porządku. Tej idealnie konfliktogennej sytuacji zapobiegać musi albo przewidujący ją szef, albo narzędzie do rezerwacji i kontroli dostępu do środowiska testowego – warto się o nie postarać.
 
Podobne kłopoty występują także w testach miękkich wszędzie tam, gdzie o dostęp do środowiska docelowego, lub prawie-docelowego (przedprodukcyjnego) rywalizuję różne osoby – na przykład w bankach, w dużych portalach informacyjnych. Organizacji dostępu do nich można się uczyć od naszych wbudowanych kolegów.
 

Nowość – testowanie zdalne przez łącze internetowe


Kiedy w laboratorium testowym stoi takie urządzenie, jak centrala telefoniczna, chłodzenie utrzymuje w pomieszczeniu stałą temperaturę 19o, co jest bardzo miłe latem, ale nieprzyjemne zimą. Ponieważ jednak testy, wykorzystujące centralę telefoniczną, wykonuje często nawet kilkadziesiąt osób, dostęp zdany staje się koniecznością, niezależnie od pory roku.
 
Podłączając urządzenia, wykorzystywane do testowania, do internetowego łącza, oraz oczywiście nadzorując, kto i kiedy z niego ma prawo korzystać, można umożliwić zdalny dostęp i zdalne testowanie nawet dla naprawdę małych urządzeń wbudowanych, nie mających nawet tych interfejsów dostępowych, które oferuje centrala telefoniczna.
 
Nie każdy oscyloskop czy ICE daje się łatwo podłączyć do Internetu wprost. Dobrym rozwiązaniem jest podłączenie tych urządzeń – zwykle przez specjalne łącze zwane GPIB – do komputera, zaopatrzonego w specjalne sterowniki GPIB, i program do zarządzania nimi. Ten komputer powinien być także dostępny jako serwer przez Internet.

    

Jakie specjalne testy stosuje się dla systemów czasu rzeczywistego?

Systemy czasu rzeczywistego nie muszą być specjalnie szybkie. To, co odróżnia je od innych systemów, to wymóg, aby pewne czynności odbyły się w określonym przedziale czasowym, albo trwały nie dłużej i nie krócej, niż pewna liczba nano-, mili-, albo sekund.
 
Dla innych systemów powolne działanie to problem z zakresu osiągów: dotkliwy, nawet dyskwalifikujący pod względem biznesowym, ale nie powodującym awarii funkcjonalności. Zbyt szybkie działanie – takie cuda się czasem zdarzają – to problem z zakresu interakcji / użyteczności / HCI. Dla systemów czasu rzeczywistego, brak zgodności z wymaganiami czasowymi, powoduje niepoprawne funkcjonowanie, albo zupełną awarię systemu.
 

Testy szybkości oraz czasowej przewidywalności nie tylko aplikacji, lecz również platformy sprzętowej i systemu operacyjnego

  
Podobnie jak dla testów osiągów, testów systemu czasu rzeczywistego nie wystarczy przeprowadzić raz, w korzystnych warunkach. Ważne, że wymagania czasowe spełnia w różnych sytuacjach i pod różnym obciążeniem także platforma sprzętowa (nie tylko „komputer” - elektronika, ale także elementy mechaniczne, chemiczne, elektryczne, wszystkie, które mają razem działać w czasie rzeczywistym), oraz system operacyjny.
 
W różnych sytuacjach – także pod obciążeniem, lub przy braku danych. W formie fabularnej, możliwe zagrożenia tych właściwości, biorące się nawet ze specyfiki procesu wytwarzania, znakomicie opisuje „Ananke” Stanisława Lema.
 

Długotrwałe testy stabilności

  
Przetestowanie, dostatecznie staranne, wymagań podanych na poprzedniej ilustracji, wymaga z reguły testów długotrwałych, zwanych czasem testami stabilności.
  
Aby osiągnąć potrzebny rozrzut i zróżnicowanie obciążenia, niekiedy dane testowe do tego celu generuje się automatycznie.
  

Testowanie poprawności implementacji wymagań czasowych

  
W systemach czasu rzeczywistego występują pewne typy awarii, nie mające odpowiednika w systemach, dla których czynnik synchronizacji czasowej nie ma znaczenia. Można im zapobiegać poprzez odpowiednie projektowanie, ale potrzebne są także testy dla dodatkowej kontroli, że takie sytuacje dla danego systemu nie występują. Trzeba je rozumieć, aby móc pod ich kątem zaprojektować testy.
 
„Deadlock” (wzajemne blokowanie): dwa procesy wzajemnie czekają na siebie, a brak time-out powoduje, że zatrzymanie trwa w nieskończoność.
 
„Resource starvation” oznacza, że proces o niskim priorytecie zbyt rzadko i na zbyt krótko uzyskuje dostęp do potrzebnych mu zasobów, w związku z czym zatrzymuje się, lub działa błędnie, lub zbyt wolno.
 
„Priority inversion” to dość zawiła sytuacja, w wyniku której do głosu, zamiast czekającego procesu o najwyższym priorytecie, dochodzi proces o niższym priorytecie; zapobiega się jej poprzez odpowiednie manipulowanie obsługą przerwań.
 
„Race conditions” to sytuacja, kiedy przez to, że jeden proces – wbrew intencjom programisty – zdąży zmienić wartość semafora przez innym procesem, system podejmuje błędne działania.
 

Testowanie niezawodności (MTBF)

 
Zasady testowania niezawodności (inne nazwy: Statistical Usage-Based Testing, Reliabiilty Testing) zakładamy są znane czytelnikom.
 
Wielokrotnie, niepoprawne działanie systemu może się zdarzać od czasu do czasu (nie jest zero-jedynkowe między „zawsze” a „nigdy”), byle niezbyt często. Jak często? – to określa wymaganie sformułowane jako MTBT, albo MTTF. Testowanie niezawodności sprawdza, czy – na pewnym poziomie statystycznej istotności – to wymaganie jest spełnione.
    

Testowanie systemów krytycznych dla bezpieczeństwa

Systemy krytyczne dla bezpieczeństwa (ang. safety-critical) to takie, których niepoprawne działanie, lub awaria, może stanowić bezpośrednie zagrożenie dla zdrowia i życia ludzi.
 

Normy – warto je poznać

 
Ta celowo nieczytelna ilustracja poniżej, wskazuje z jednej strony na wielość obszarów, gdzie mamy do czynienia z systemami krytycznymi dla bezpieczeństwa, a z drugiej strony, na zbędne, uzasadnione historią branżowych odrębności, oddzielne (i redundantne) opisywanie tych samych zasad w wielu różnych miejscach.


 

Nacisk norm na zapobieganie, nie tylko na testy


Testowanie jest swego rodzaju strażą pożarną: odkrywa awarie tam, gdzie nie powinno ich w ogóle być. W społeczności, aby obniżyć ryzyko pożaru, nie mnoży się liczby ani intensywności patroli straży, tylko stosuje szereg kroków zapobiegawczych (które nb. straż pożarna może nadzorować, ale tylko mając szczególne kompetencje i odpowiednie uprawnienia).
Ta sama zasada dotyczy systemów krytycznych szczególnie, że wykrywane bugi dotyczące bezpieczeństwa, często nie dają się łatwo naprawić, lecz wymagają gruntownej rekonstrukcji zasad budowy systemu.
 

SIL a testowanie


SIL (Safety Integrity Level) to miara, określające jak „bezpieczny”, czyli mający niezbędne dla bezpieczeństwa funkcje i właściwości, dostatecznie niezawodne.
 
Miarą SIL są dla danego możliwego zagrażającego zdarzenia: jego konsekwencje x prawdopodobieństwo x dostępne czynności ratunkowe (zmniejszające skutki).
 
SIL dla jednoczesnej awarii wszystkich silników w samolocie jest różny dla samolotu wojskowego i pasażerskiego, mimo że ryzyko może być identyczne, ponieważ ten pierwszy wyposażony jest w katapultę i spadochron, a drugi nie. Dlatego w odniesieniu do samolotów pasażerskich wymagane jest znacznie mniejsze prawdopodobieństwo takiej awarii.
 
Wielkość SIL określają specjaliści branżowi, a jego wielkość wpływa na wymagania bezpieczeństwa i niezawodności komponentów, co określa m.in. niezbędną staranność testowania.
 

Jeszcze o testach systemów krytycznych dla bezpieczeństwa

   
Analiza bezpieczeństwa jest całościowa – nie tylko miary niezawodności komponentów IT. Analiza musi być zawsze wykonywane łącznie, przez specjalistów w różnych dziadzin, nie ma ona sensu osobno w odniesieniu do samego oprogramowania.
   
Normy bezpieczeństwa wymagają wykonywanie testów statycznych, w tym analizy statycznej kodu certyfikowanymi narzędziami.
  
Normy bezpieczeństwa wymagają osiągnięcia określonych poziomów pokrycia kodu testami, różnych dla różnych poziomów SIL. Pomiar pokrycia musi być wykonany przez certyfikowane narzędzia. 
   
Istnieje, wyglądające paradoksalnie, pewne podobieństwo między systemami wymagającymi wysokiej „charyzmy” (jak gry, portale plotkarskie itp.), a systemami krytycznymi dla bezpieczeństwa. Dla obu drobiazgowe testowanie nie wystarcza, aby ocenić to, co najważniejsze. Dla systemów charyzmatycznych, to poziom UX (user experience), a dla bezpiecznych – czynniki organizacyjne i psychologiczne, w tym HCI, mogące sprowadzić niebezpieczeństwo dla użytkownika systemu, przetestowanego jako dostatecznie niezawodny.
   
Automatyzacja testów - tylko wyniki testów wykonanych przez certyfikowane narzędzia, traktowane są jako miarodajne, dostateczne. Certyfikuje się zarówno poziom inwazyjności narzędzia, jego wiarygodność oraz trafność (accuracy) i dokładność (precision) wyników.