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ę.
Odpowiedzi:
Kierownictwo rozumie, że opracowanie i utrzymanie oprogramowania potrwa dłużej, jeśli nie masz pełnego dostępu do sprzętu testowego. Musisz wziąć to pod uwagę przy dokonywaniu szacunków. Częścią kryteriów akceptacji dla wprowadzenia oprogramowania do produkcji powinno być to, że masz sposób na utrzymanie oprogramowania w większości przypadków bez zatrzymywania produkcji. Jeśli ćwiczysz TDD, powinno to nastąpić w sposób naturalny.
Pisałem oprogramowanie dla samolotów o wartości 60 milionów dolarów. Oczywiście wymagany jest wysoki stopień niezawodności i niechętnie dają każdemu programistowi jeden za swoje biurko. Zasadniczo mieliśmy 5 poziomów środowisk testowych, z większą ilością rzeczywistego sprzętu na każdym poziomie, aż do pełnego samolotu. Szacuję, że 95% naszego oprogramowania można opracować i debugować tylko za pomocą emulatorów i testów jednostkowych. 95% pozostałych funkcji można było uruchomić na wyższym poziomie i tak dalej.
Spróbuj skonfigurować dla siebie podobne poziomy środowisk testowych. Nie możesz oczekiwać, że nigdy nie będziesz potrzebować dostępu do prawdziwego sprzętu, ale jeśli skonfigurowałeś go tak, abyś nie mógł pracować nad GUI oprogramowania bez dostępnego sprzętu, tracisz cenny czas na drogie zasoby (nie na wspomnieć, że masz pewne problemy ze sprzężeniem z architekturą). Weź pod uwagę, że inni programiści prawdopodobnie mają takie same problemy jak Ty. Zapytałbym sprzedawcę sprzętu, czy ma już dostępne emulatory lub inne zasoby testowe.
Musisz także nieco zmienić sposób myślenia, jeśli masz ograniczony dostęp do sprzętu. Zamiast próbować debugować aplikację w normalny sposób szeregowy, często musisz napisać kod specjalnie w celu zebrania informacji tak szybko, jak to możliwe.
Na przykład może masz błąd i możesz wymyślić 10 możliwych przyczyn. Jeśli jedynym czasem, w którym można dostać się na maszynę, jest 15 minut, gdy operator jest na przerwie, napisz krótki, samodzielny, poprawny (możliwy do skompilowania) przykład, który wyzwala błąd i napisz 10 automatycznych testów przy użyciu tego SSCCE do przetestowania swoich teorii i zaloguj wiele danych. Następnie z powrotem przy biurku możesz przeszukiwać dane tak długo, jak to konieczne. Chodzi o maksymalizację użyteczności twojego ograniczonego czasu ze sprzętem.
źródło
Próbujesz rozwiązać problem, który nie jest twój.
Kierownictwo musi nadać priorytet dostępowi do sprzętu. Może to oznaczać, że uzyskasz większy dostęp, ale może również oznaczać, że będziesz mieć mniej.
Przedstaw swoje wyzwania zespołowi zarządzającemu w obiektywnym formacie i poproś o wskazówki. Twoja prezentacja byłaby o wiele silniejsza, gdybyś współpracował z innymi, którzy również potrzebują dostępu, abyście wszyscy mogli przedstawić swoją sprawę w tym samym czasie.
Stamtąd firma (zarząd) musi ustalić, kto i kiedy ma dostęp. Muszą podjąć decyzję biznesową, ponieważ (brak) dostępności zasobów ma wpływ na rozwój firmy.
źródło
Skutecznie kodujesz w ciemno.
Jeśli zarządzanie nie zapłaci za urządzenia testowe, istnieje duże prawdopodobieństwo błędów, a nawet rozwoju zajmie więcej czasu niż gdybyś miał prawdziwe urządzenia do użycia.
Koszt urządzeń nie musi być całkowicie przypisany do cyklu „programowania”. Być może można je zamienić do użytku produkcyjnego lub jako kopię zapasową. Czy mogą być odsprzedane z drugiej ręki gdzie indziej?
Spróbuj kosztować fazy usuwania błędów, zarówno pod względem czasu, jak i pieniędzy, i pokaż ogólny koszt swojego zespołu / firmy.
źródło
Kłócenie się z bossami jest znacznie łatwiejsze, gdy masz pod ręką jakieś liczby, a przynajmniej niektóre zalety i wady, więc moja sugestia próbuje dokonać analizy kosztów w porównaniu z benfit. Szorstki pomysł wygląda następująco:
Jakiego nakładu pracy spodziewasz się napisać symulator urządzenia? (Należy pamiętać, że symulator urządzenia nie może zastąpić oryginalnego sprzętu w 100%, szczególnie gdy sprzęt ma pewne nieoczekiwane dziwactwa).
ile oczekujesz wysiłku testowania / debugowania bez takiego narzędzia? Uwzględnij koszty pracowników laboratorium, ponieważ musisz zablokować sprzęt do celów testowych. Uwzględnij także koszty czasu, gdy system nie może być używany z powodu błędów i masz problem ze znalezieniem przyczyny.
ile kosztuje dodatkowy sprzęt do testowania?
ile czasu będziesz potrzebować do zablokowania sprzętu do celów testowych?
Oczywiście rzeczywistość może nie być taka prosta i w tym równaniu znajduje się wiele nieznanych zmiennych, ale spróbuj dokonać pewnych oszacowań, a jeśli nie jesteś pewien, zapytaj innych ludzi ze swojego środowiska.
Przedstaw wyniki kierownictwu, omów alternatywy, a następnie pozwól im podjąć decyzję.
źródło