Redakcja
Wpis na blogu Attila Vágó, inżyniera oprogramowania z firmy Prezi, porusza bardzo ważny aspekt - shift left (early testing – wczesne testowanie) nie jest przesunięciem testerów bliżej początku wytwarzania oprogramowania, ale jest zaangażowaniem osób z początków wytwarzania w jego testowanie. Należy więc nadać wyższy priorytet testom na wcześniejszych etapach cyklu życia oprogramowania.
Przyjrzyjmy się najważniejszym aspektom poruszanym przez Atillę, bo to ważny wkład do zrozumienia testowania przez programistów. Co prawda rzeczy i reguły omawiane przez autora są testerom doskonale znane, ale jest to perspektywa programistyczna, którą warto poznać.
Atilla otwiera: […] chcę przedstawić temat testowania oprogramowania, ale nie z jakiejś ogólnej perspektywy, ale z perspektywy programisty. Przyjrzymy się, dlaczego testowanie może, ale nie musi być tak popularne, jak pirania jako domowe zwierzątko dla twojego 5-letniego dziecka, dlaczego nigdy nie jest trendującym hashtagiem na Twitterze i TikTok-u; dlaczego zarówno Martin Fowler, jak i Kent C. Dodds są jego zwolennikami, i wreszcie, co możesz zrobić, aby zapobiec udarowi mózgu u twojego użytkownika podczas próby kliknięcia przycisku.
Atilla tłumaczy: Czym do diabła jest testowanie oprogramowania? - W jednym zdaniu, jest to rzecz, która zabrała nas w kosmos. […] I nie, nie przesadzam. Kod źródłowy Apollo Guidance Computer został bardzo dokładnie przetestowany. W rzeczywistości, 60% wysiłków związanych z rozwojem było testowaniem oprogramowania!
Atilla w swoim wywodzie wprowadza koncept piramidy testowania rozpropagowanej przez Martina Fowlera, by pomóc lepiej zrozumieć testy.
Atilla tłumaczy, że "testowanie != QA" jednak robi to na swój sposób. Testerów nazywa QA-ami uznając, że jakość oprogramowania to nie tylko odpowiedzialność zespołu QA. Odrzuca koncepcję dewelopera, który pisze kod, a następnie przerzuca go przez płot do QA, który następnie spędza dwa razy więcej czasu na tworzeniu raportów błędów niż deweloper spędza na pisaniu funkcji. Pisanie testów jednostkowych, testów integracyjnych i dalsza walidacja przepływów użytkownika za pomocą testów E2E jest czymś, co uważam za dobrą, codzienną praktykę deweloperską. Dobry test może odkryć problemy architektoniczne w aplikacji, ale także w UX – pisze autor. Kiedy tylko mam możliwość, po napisaniu nowego epic-a lub user stories, lubię uruchomić wszystkie istniejące testy, przejrzeć wyniki i patrzeć jak zautomatyzowane testy przepływów robią swoje. Daje mi to błyskawiczne wprowadzenie do aktualnego zachowania aplikacji, a nawet kilka dodatkowych technicznych szczegółów, zwłaszcza, jeśli testy są dobrze opisane. Da mi to nie tylko bardzo potrzebny kontekst, ale także umożliwi mi budowanie lub rozszerzanie funkcji w taki sposób, by zapewnić mi wystarczającą pewność co do gotowości do jego przekazania do QA w celu weryfikacji.
Atilla tłumaczy, że Pokrycie to nic nie znaczy! - Chociaż bardzo polecam korzystanie z tych narzędzi [red. pokrycia kodu], bądź świadomy, że kod może być w 100% przetestowany i nadal nie być przetestowanym w ogóle. Wszystko, co trzeba zrobić, to wywołać metody w pliku testowym i voilà, przypadek testowy pokryty. Uważaj na tych podstępnych cwaniaków, którzy piszą testy bez asercji! Jednak same asercje też nie gwarantują dobrych testów.
Atilla zachęca by rozszerzać zbiory danych testowych – Więc twoje dane wejściowe to ciąg i oczekujesz, że test podwoi długość tego ciągu? Świetnie. To jednak tylko jeden test. Co jeśli zasilisz go pustym ciągiem, liczbą całkowitą, NaN, funkcją i dowolną inną szaloną rzeczą […]. Bardzo duża część błędów na produkcji dzieje się z uruchamiania nieoczekiwanych scenariuszy, a to są właśnie te, których nie obejmujesz!
Atilla uświadamia, że istnieje również coś takiego jak zbyt wiele testów – W tworzeniu oprogramowania, jedną z najważniejszych - ale rzadziej omawianych - umiejętności jest zdolność do analizy kosztów i korzyści. Częstym przypadkiem zbyt dużej ilości testów jest sytuacja, w której testy jednostkowe i integracyjne pokrywają się w znacznym stopniu, co sprawia, że masz wrażenie, że piszesz testy dwa razy dla tej samej rzeczy i marnujesz zasoby […].
Atilla przekonuje, że rozmowa o testerach to rozmowa o kulturze organizacyjnej. Opisuje to tak: Żadne zasady, diagramy i narzędzia automatyzacji nie zajdą daleko, jeśli w Twoim zespole nie będzie właściwej kultury. Nie ma substytutu dla kultury zorientowanej na jakość. Poza wymyślnym żargonem i korporacyjną gadką, tak naprawdę sprowadza się do kilku kluczowych aspektów.
Uwzględnij w swoich historiach czas na testy. […] Może nie 60% sprintu, jak w przypadku Apollo, ale na pewno 25-40% czasu programisty powinno być poświęcone na zapobieganie awariom produkcji poprzez solidne testowanie.
Zachęcaj członków swojego zespołu do osiągania wysokiego pokrycia kodu. Jeśli musisz, zrób to w formie gry. Zamień to nawet w konkurs.
Dziel się trudnymi przypadkami testowymi i rozwiązaniami z innymi zespołami w firmie. Nawet mgliste pamiętanie, że ktoś w pewnym momencie poradził sobie z czymś podobnym, może szybciej wykopać cię z króliczej nory.
Stwórz arkusz wpływu, który pomoże śledzić testy vs. błędy w dłuższej perspektywie, i ucz się bazując na tym jako zespół i jako firma. Błędy są nieuniknione, ale wielu z nich można zapobiec.
I na koniec Atilla wraca do klasycznego podejścia do testowania: Pisanie testów może nie jest najprzyjemniejsze, ale patrzenie jak przechodzą, na pewno jest!
Polecamy zapoznać się z całym wpisem Atilli, bo choć wyciągnęliśmy z niego esencję, to warto prześledzić go chociażby na użyty przez autora barwny język.
