Testowanie developerskie

U mnie działa!

Wydarzenia ostatnich dni natchnęły mnie, żeby napisać parę słów o testowaniu aplikacji. Jako, że jest to blog programistyczny spodziewacie się pewnie, że napiszę o testach jednostkowych lub testach integracyjnych. Pokażę narzędzia do automatyzacji testów. Może będę zachwalał Cucumber i próbował Was przekonać jakim to super wynalazkiem jest BDD. Otóż nie :). Dziś chciałbym napisaś o najbardziej podstawowym sposobie testowania, czyli przeklikaniu się przez system. Nie chcę teę zgrywać specjalisty od QA dlatego pisać będę o testach wykonywanych przez developerów, a nie specjalistyczne zespoły testerskie.

Na początek zacznę od postawienia dość kontrowersyjnej tezy. Developerzy nienawidzą testować funkcjonalnie kodu, który napisali. Klikanie po ekranie? Sprawdzanie, czy niewypełnienie jakiegoś pola spowoduje błąd? Przeklikanie jakiegokolwiek scenariusza poza happy path? Po co to komu? Przecież pokrycie testami jednostkowymi jest na poziomie 100%, przecież jestem genialny i napewno wszystko działa :). Wiecie jaki jest rezultat większości testów funkcjonalnych wykonywanych przez developerów? U mnie działa.

Happy path to za mało

Developerzy dzielą się na tych co, mimo że nienawidzą tego robić, testują oraz na tych co …. nie testują (lub robią to niewystarczająco dobrze).

W moim aktualnym projekcie jesteśmy właśnie świeżo po pierwszej fazie smoke testów. Testy te objęły tylko cztery ekrany aplikacji. Dodam tylko, że jest to skomplikowany system backendowy z rozbudowanymi formularzami. System ten idealnie wpasowuje się w słynnego, wśród programistów mema.

yourproduct

Development do momentu pierwszych testów, wykonanych przez zespół QA, szedł książkowo. Terminów dotrzymywaliśmy. Projekt Manager był zadowolony bo wszystko mu się w MS Project zgadzało. Niestety przysłowiowy kij w mrowisko wsadzili nam testerzy po wspomnianej pierwszej fazie smoke testów.

Rezultat był zatrważający. Siedemdziesiąt dwa błędy zgłoszone do czterech ekranów. Sześćdziesiąt pięć procent przypadków testowych ze statusem FAILED.

Po spotkaniu statusowym zbierałem szczękę z podłogi. Jak to się mogło stać pytałem? Jak każdy (tak mi się wydaje) team leader w tym momencie odebrałem to bardzo osobiście. Zacząłem zastanawiać się, co było przyczyną takiego stanu rzeczy i jak to poprawić? Przecież to dopiero początek projektu. To nie może się powtórzyć w kolejnych etapach.

Crosscheck developerski

Jednym z rozwiązań, jakie niejeden by zastosował, byłoby zebranie całego zespołu i opierdzielenie bez przebierania w słowach niczym kapitan Bednarz ze słynnego na youtube „Apelu wojskowego bez cenzury”. Jednak to nie są moje metody. Jedyny efekt jaki bym tym osiągnął to wprowadzenie złej atmosfery w zespole. Podczas codziennego stand up’a przedstawiłem na spokojnie zespołowi sytuację. Zaproponowałem przeprowadzenie testów funkcjonalnych typu „crosscheck”. Założenia tych testów były takie:

  1. Ekrany, których jeszcze nie oddaliśmy do testów QA, a które mamy skończone, zostaną przetestowane wewnętrznie przez innego developera
  2. Developer ma przeklikać się przez ekran opisując wszystkie przypadki, które sprawdza
  3. W przypadku natrafienia na bądd developer zgłasza go w JIRA

Cele tego ćwiczenia były dwa. Pierwszy to wyłapać część błędów, zanim zrobi to zespół QA. Drugi, dużo bardziej dla mnie ważny, to zobaczyć w jaki sposób poszczególni członkowie zespołu testują ekran. Zakładałem, że podczas takiego zleconego crosschecku, przetestują go dużo dokładniej, niż testują ekran, który sami tworzą 😀 Chciałem poznać różne podejścia do testowania developerskiego, namierzyć kto testuje dobrze, wyłapać dobre praktyki i sporządzić na ich podstawie ogólne wytyczne dla całego zespołu. Jednocześnie dyskretnie pokazać tym co robili źle jak powinno to wyglądać.

W chwili obecnej jesteśmy w połowie tego ćwiczenia. Część ekranów poddaliśmy już wewnętrznym testom i poprawiamy błędy, które znaleźliśmy. Pierwsza wersja wytycznych została spisana.

Z niecierpliwością czekam na oddanie kolejnych ekranów w ręce zespołu QA, żeby potem móc powiedzieć: wyciągnęliśmy wnioski i poprawiliśmy nasz proces developmentu. Przecież w każdej porażce o to właśnie chodzi, żeby nauczyć się czegoś nowego na własnych błędach. Mam nadzieję, że w tym przypadku tak właśnie będzie.