Tester systemów wbudowanych

Tytułowe stanowisko może występować pod różnorakim nazewnictwem, od „Embedded QA Engineer” czy „Embedded Tester” czyli dosłownie tester systemów wbudowanych, aż do w pełni zakamuflowanego „Software QA Engineer”, „Quality Assurance Engineer” czy „Software Tester”, gdzie dopiero po zaznajomieniu się z opisem stanowiska dowiadujemy, że tyczy się ono systemów wbudowanych. Wszystko zależy od przyjętego przez daną firmę nazewnictwa. Ale może nie zajmujmy się liczeniem, na ile sposobów można nazwać to stanowisko, lecz czym zajmuje się tester systemów wbudowanych? Żeby odpowiedzieć na to pytanie, zacznę od przybliżenia w telegraficznym skrócie, czym są systemy wbudowane.

Systemy wbudowane

Są to urządzenia, w których sprzęt i oprogramowanie są ściśle powiązane. W odróżnieniu od wielofunkcyjnych komputerów PC, systemy wbudowane wykonują ograniczoną liczbę ściśle zdefiniowanych zadań. Taki system zawiera mikroprocesor lub mikrokontroler, który posiada oprogramowanie przeznaczone jedynie na to urządzenie (firmware) lub system operacyjny ze specjalnym oprogramowaniem. Użytkownik korzystający z urządzenia opartego o system wbudowany może nawet nie zdawać sobie sprawy z jego istnienia.

Gdzie spotkamy się z systemami wbudowanymi?

Mógłbym wypisać ścianę tekstu, samego wypunktowania różnorakich zastosowań systemów wbudowanych, ale może zamiast tego wypiszę, w jakie skrajności możemy zabrnąć w tych systemach.

Smartwatch’e
Systemy sterujące samolotami czy rakietami
Drukarki
Bankomaty
Konsole do gier
Klimatyzatory

I wiele innych sprzętów codziennego i niecodziennego użytku nawet w tak prozaicznych, jak szczoteczka elektryczna czy suszarka.

Testowanie systemów wbudowanych

Testowanie to w odróżnieniu od innych typów testów oprogramowanie jest skupione na urządzeniu lub różnych wariantach tego urządzenia. Wymusza to ciągłą „walkę” z czyhającymi na nas ograniczeniami i pokusami oddalenia się od samego urządzenia. Testy oprogramowania systemów wbudowanych sprawdzają jakość oprogramowania i urządzenia, na którym jest ono zainstalowane, czy urządzenie spełnia wszystkie zdefiniowane wymagania (np. w specyfikacji) i czy jest zgodne z oczekiwaniami użytkownika. Choć możliwe jest symulowanie i emulowanie testowanych urządzeń, w wielu przypadkach jest niezalecane i może dać całkowicie inne wyniki testów niż na realnym urządzeniu.

Testowanie Embedded

Testy wykonywane są zarówno czarno jak i biało skrzynkowe.

Testy dotyczą zarówno oprogramowania jak i sprzętu.

Podstawowymi obszarami testowania jest testowanie zachowań sprzętu i oprogramowania na zadane dane wejściowe.

Testowanie Oprogramowania

Większość testów jest wykonywana czarnoskrzynkowo.

Testy dotyczą wyłącznie oprogramowania.

Podstawowymi obszarami testowania jest GUI, posiadane funkcjonalność, walidacja i testowanie korelacji z bazami danych.

Myślenie na poziomie ograniczeń

Przygotowując środowisko testowe do testów systemów embedded, musimy przewidzieć wiele problemów, które możemy napotkać już podczas samych testów. To jak gra w szachy z diabłem. Na każdym kroku czyha wieszający się, przeciążony router, źle przylutowane przewody czy braki w samym urządzeniu (zbyt mała ilość urządzeń, by przetestować wszystkie warianty oprogramowania równolegle). Już na poziomie pisania testów (jeżeli zajmujemy się automatyzacją) musimy wiedzieć gdzie i jak się wpiąć/wlutować. Pozwoli to zasymulować „ruchy” użytkownika, nie ingerując na tyle w urządzenie, by testy były dalej wiarygodne.

I pomyślisz pewnie, że próbuję was odstraszyć od testowania systemów wbudowanych. Otóż nie, jest zupełnie odwrotnie. W tym zmaganiu jest cały urok tej pracy, że składa się ona z ciągłych deliberacji. Bo gdzie ciekawe przemyślenia tam i ciekawi ludzie.