Przemyślenia architekta IT

Menu
  • Strona główna
  • O mnie
  • Co czytam
  • Czego się uczę
Menu

Testowanie developerskie

Posted on 26 października 20161 sierpnia 2019 by Tomasz Sokół

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.

Jeśli podobają Ci się treści na moim blogu zostaw swój email. Będę Cię informował o nowych artykułach. Zero spamu same konkrety.

* pola wymagane

Chcesz dostawać powiadomienia o nowych artykułach? Zostaw swój email.

Ostatnie wpisy

  • Wzorzec Post/Redirect/Get plus twierdzenie CAP jako recepta na problem
  • 7 kroków do przejęcia systemu od innego dostawcy
  • Młody programisto! 7 porad od starszego kolegi
  • Jak dorosłem do tego, żeby nie używać ORM’a
  • Drivery architektoniczne. Czym są i co może się wydarzyć, gdy odkryjemy je zbyt późno. Historia prawdziwa.

Kategorie

  • Architektura
  • Procesy
  • Zespół
Polityka prywatności
©2022 Przemyślenia architekta IT | WordPress Theme by SuperbThemes
Serwis wykorzystuje pliki cookies. Korzystając ze strony wyrażasz zgodę na wykorzystywanie plików cookies.Tak. Zgadzam się Reject Dowiedz się
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.

Necessary Always Enabled

Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

Non-necessary

Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.