Proszony kilka razy postanowiłem wreszcie zająć się tematem zarządzania jakością i testami w projektach agilowych i poświęcić kilka postów aby podzielić się z Wami moją wiedzą na ten temat. Chciałbym zacząć od prezentacji znanej już od 2003 roku koncepcji Briana Maricka czyli „Agile Testing Quadrants” Link do oryginalnego posta Briana Maricka.Koncepcji rozszerzonej w 2009 roku przez Lisę Crispin i Janet Gregory w ramach pracy nad ich książką „Agile Testing A practical guide for testers and agile teams” do formy którą możemy zobaczyć poniżej. Formy która specyfikuje różne rodzaje testów które można/czasem należy wykonać na poszczególnych etapach prac nad produktem wraz z sugestią w jaki sposób dane testy powinny zostać wykonane i na co mają wpływ/od czego zależą.
W ramach tego postu chciałbym szczególnie skupić uwagę na pierwszej ćwiartce czyli testach jednostkowych. Należy tutaj nadmienić iż oznaczenie ćwiartek od 1 do 4 nie oznacza kolejności wykonywania testów i zależy od rodzaju projektu i ryzyk z nim związanych. Macierz należy traktować bardziej jako checklistę, zbior testów spośród których należy wybrać te testy które są aplikowalne/zasadne dla naszego projektu.
1 ćwiartka reprezentuje jedną z corowych praktyk stosowanych w projektach agile mianowicie testy jednostkowe. Ten rodzaj testów polega na rozpoczynaniu tworzenia nowych funkcjonalności od napisania testów które testują daną funkcjonalność, przy każdym uruchomieniu potwierdzają poprawny lub błędny wynik testu (należy wspomnieć tu o koncepcjach TDD – Test Driven Development oraz ATDD – Acceptance Test Driven Development). Dobrą praktyką jest dzielenie testów jednostkowych tak aby testowały tylko wybraną metodę lub obiekt począwszy od najprostszych do bardziej zaawansowanych funkcjonalności w ramach testów komponentów takich jak grupy klas. Testy jednostkowe z założenia mają dawać zespołowi szybki feedback wobec czego zwykle są to testy automatyczne, stworzone w tej samej technologi (języku programowania) co testowana aplikacja. Wykorzystywanie koncpecji TDD czy ATDD powoduje zminimalizowanie ilości błędów które będą wykryte na wyższych poziomach. Deweloperzy dobrze przykładając się do pisania testów unitowych zapewniają członkom zespołu odpowiedzialnym za testy czas na testowanie w wyższych ćwiartkach poważniejszych reguł biznesowych przez co maksymalizują potencjalną wartość biznesową która zostanie dostarczona klientowi.
Testy jednostkowe z założenia mają dawać poszczególnym członkom zespołu pewność i swobodę pisania kodu (refaktorującego stare rozwiązania czy dostarczającego nowe funkcjonalności), bez strachu o spowodowanie tzw. side effect w innych obszarach aplikacji. Uzyskany po kilku minutach wynik egzekucji testów pozwala w szybki sposób zweryfikować jakość zaproponowanego rozwiązania a także upewnić pozostałych członków zespołu o dojrzałości ich wewnętrznego quality assurance. Pozwala developerom na swobodny refactoring rozwiązań poprzez to utrzymywanie kodu w odpowiednim standardzie. Pisanie najpierw testów a poźniej kodu wymaga pisania kodu który jest testowalny, developer tym samym dostarcza bardziej przemyślane rozwiązania. Testy powinny być uruchamiane przy każdej nawet małej zmianie kodu, dając tym samym nieustanny feedback na temat jakości i spójności kodu. W przypadku wykrycia błędu osoba której zmiana w kodzie spowodowała błąd powinna się nim niezwłocznie zając, aby zawsze utrzymać system we właściwym stanie i nie blokować kolegów.
Mając zbudowany zestaw automatycznych testów jednostkowych warto zintegrować go z systemem zarządzania wersjami SVN oraz serwerem CI ang. continuous integration. Rozwiązaniami które mogą reagować automatycznie na zmiany w kodzie i wykonywać odpowiednie testy jednostkowe. Aby takie rozwiązanie było skutecznie czas odpowiedzi z corowych testów jednostkowych nie powinien przekraczać max. 10 minut. Jeśli zdarzy się że przekracza należy dokonać przeglądu, zidentyfikować miejsce wykonujące się najdłużej i dokonać niezbędnych modyfikacji tak aby przyspieszyć feedback. Oczywiście zespół może mieć kilka zestawów testów automatycznych które są dużo bardziej rozbudowany i testują poza corem aplikacji również interfejsy, warstwę GUI, połączenia z bazą, itp. Czas trwania wykonania full testów mniej wpływa na pracę zespołu ponieważ mogą być uruchamiane na przykład poza godzinami pracy zespołu przez automatyczny scheduler (e.g. Jenkins).
Należy przy okazji pisania o automatycznych testach jednostkowych wspomnieć o pojęciu długu technicznego, nie mając zaimplementowanej tej praktyki bardzo łatwo jest się wpędzić w spiralę długu przez co uczynić pisany kod z iteracji na iterację coraz trudniejszy do utrzymania. Dobre testy jednostkowe automatyczne dbają o przejrzystość i transparentność kodu, utrzymując dług techniczny na zarządzalnym poziomie.
0 komentarzy