Pracuję w średniej wielkości firmie (150 pracowników, zespół inżynierów wielkości około 10), a większość moich projektów dotyczy współpracy ze sprzętem laboratoryjnym (oscyloskopy, analizatory spektrum optycznego itp.) Do celów półautomatycznych aplikacji testowych. Natknąłem się na kilka różnych scenariuszy, w których nie jestem w stanie skutecznie rozwiązywać problemów lub testować nowego kodu, ponieważ nie mam już lub nigdy nie miałem dostępnej konfiguracji sprzętu.
Przykład 1: Konfiguracja, w której 10-20 procesów „wypalania” jest uruchamianych niezależnie przy użyciu czujnika typu stołowego - byłem w stanie uzyskać jeden taki czujnik do testów i czasami mogłem ukraść drugi do symulacji wszystkich aspektów interfejsu wiele urządzeń (wyszukiwanie, łączenie, przesyłanie strumieniowe itp.).
W końcu pojawił się błąd (który ostatecznie znalazł się w oprogramowaniu sprzętowym i sterownikach urządzenia), który był bardzo trudny do dokładnego odtworzenia za pomocą tylko jednej jednostki, ale uderzył w pobliżu poziomów „pokaż stopper”, gdy 10-20 z tych urządzeń było używanych jednocześnie. To jest nadal nierozwiązane i trwa.
Przykład 2: Test wymagający drogiego analizatora widma optycznego jako jego głównego komponentu. Urządzenie jest dość stare, jak twierdzi producent, który został przejęty przez większą firmę i w zasadzie rozwiązany, a jego jedyną dokumentacją był długotrwały (i nieinformacyjny) dokument, który wydaje się źle przetłumaczony. Podczas początkowego rozwoju byłem w stanie trzymać urządzenie przy biurku, ale teraz jest ono powiązane, zarówno fizycznie, jak i zgodnie z harmonogramem podczas wielotygodniowych testów 24/7.
Kiedy pojawiają się błędy związane z urządzeniem lub niezwiązane z nim, często muszę przejść trud testowania kodu zewnętrznego dla aplikacji i instalowania go, lub pisania kodu na ślepo i próbowania wcisnąć się w jakiś czas między kolejnymi testami, tak dużo logika programu wymaga zainstalowania OSA i pozostałej części sprzętu testowego.
Myślę, że moje pytanie brzmi: jak mam do tego podejść? Mógłbym potencjalnie spędzić czas na opracowywaniu symulatorów urządzeń, ale ustalenie, że w szacunkach dotyczących rozwoju spowoduje to balon, bardziej niż większość z nich by to doceniła. Może również nie odtwarzać dokładnie wszystkich problemów i dość rzadko widuje się tutaj ten sam sprzęt używany dwukrotnie. Mógłbym być lepszy w testowaniu jednostkowym ... itd. Mógłbym również głośno mówić o tym problemie i sprawiać, aby inni rozumieli, że będą wymagane tymczasowe opóźnienia, nie więcej niż ból głowy w zakresie badań i rozwoju, ale zwykle postrzegany jako żart po rozłożeniu na produkcję.