Jak testować, by nie zwariować2023-10-11Cześć! W tym tygodniu chciałem rozwinąć temat jakości. Inspiracją jest komentarz znajomego – że testy się opóźniają i nigdy nic nie wychodzi na czas. To jak to zrobić, by testy nam przyśpieszały pracę. 🤔 A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaOto, co przygotowałem w dzisiejszym newsletterze w ramach inżynierskiej prasówki. 1. When Taylor Swift crashed Ticketmaster: A lesson on scaling for spikes Fahim opisuje sytuację, gdy system TicketPro upadł podczas sprzedaży biletów na koncert Taylor Swift. Sam przeżywałem podobną sytuację kilka razy, gdy sprzedawaliśmy bilety na konferencję WROC#. Aby dowiedzieć się na jakie problemy możesz się natknąć i jak je rozwiązać przeczytaj powyższy post. 2. The workflow pattern https://blog.bittacklr.be/the-workflow-pattern.html Mocno techniczne przejście po procesie budowania workflow. Zamiast wykorzystywać niejasne statusy, tworzymy workflow oparty o zdarzenia. Kod napisany w F# może nieco utrudniać zrozumienie przekazu, ale ogólnie bardzo wartościowe podejście. Stosuję takie podejście podczas mapowania złożonych procesów biznesowych. 3. De-risk the Team—Behind the scenes on team coaching https://craftingtechteams.substack.com/p/de-risk-the-teambehind-the-scenes Denis oferuje wgląd jego w praktyki coachingowe w zespołach technicznych. Dowiesz się, jak efektywnie wprowadzać zmiany w zespole produktowym. Przystępny opis 3 kluczowych filarów skutecznego zespołu. 4. Organisational design for knowledge-based workplaces https://blog.kurtov.pro/organisational-design-for-knowledge-based-workplaces/ Zaletą absurdalnego raportu od McKinsey o produktywności było to, że na jego podstawie w blogosferze powstało wiele wartościowych analiz i przemyśleń. Tutaj autor opisuje jak organizacje zoptymalizowane pod pracę fabryczną są niedostosowane do pracy typowo software’owej. 5. Scaling product discovery https://herbig.co/scaling-product-discovery/ Tim Herbig pisze o skalowaniu discovery w waszym produkcie. Celnie uchwycone problemy, jakie pojawiają się w dowożeniu w skali. Problemy dookoła testówCzęsto pomagam zespołom, którzy narzekają na testy w swojej codziennej pracy. Ale nie narzekają na testy pod względem technologicznym. Problemy jakie się pojawiają to:
Posiadamy testy w zespole, ale testy nam bardziej przeszkadzają niż pomagają. Stają się kotwicą, która nas ściąga na dno (efektywności). Niedawno pisałem na LinkedIn:
Jak nie mamy odpowiednich procesów to samo testowanie nie działa. Mamy narzędzie jednej grupy. Trzeba je jeszcze odpowiednio wdrożyć do zespołu. Procesy, które działająA więc jakie procesy mieć? Chcemy się skupić na tym by jakość było obywatelem pierwszej klasy. Proponuję tutaj 5 praktyk: Jakość jako część definicji wykonaniaNajważniejszym problemem jest brak priorytetu na zapewnianie jakości. Testy automatyczne są porzucane jako zbyt mało istotne w ramach pracy zespołowej. Developerzy skupiają się jedynie by wypchać jak najwięcej pracy. Aby testy były dostarczane trzeba im nadać odpowiedni priorytet. Inaczej zawsze będą spadać w odchłań kolejki prac. Praca w zespole jest zakończona dopiero wtedy, kiedy całość jest przetestowana automatycznie i manualnie. Można to przeprowadzić np. w ramach Definition of Done. Testy stają się elementem kontraktu w zespole. Częścią pracy nad nową funkcją jest odpowiednie zapewnienie jakości. Tylko jak to zrobić by nie zabić prędkości dostarczania? Przesunięcie jakości w lewoNie da się zapewniać jakości szybko, jeśli robimy to na samym końcu dostarczania. Pętla zwrotna jest zdecydowanie zbyt długa. Za duży rework. Zagadnienia jakości (testy, wymagane atrybuty jakości) powinny być omawiane i przepracowywane możliwie najszybciej. Zamiast przeprowadzać tę pracę na końcu, trzeba to wykonywać na początku. Już w ramach analizy, designu, programowania warto angażować inżynierów jakości. Jak to pisali w Implementing Lean Software Development Mary and Tom Poppendieck:
To wymaga odpowiedniej współpracy w ramach zespołu. Jakość jest własnością zespołuW wielu zespołach testy są odpowiedzialnością 1-2 inżynierów jakości. O testach nawet się nie rozmawia po stronie innych członków zespołu. A przez to nie ma możliwości zastosowania praktyk shift-left jako całego zespołu. Cały zespół powinien być odpowiedzialny za testy w projekcie. Nie chodzi o to, by każdy te testy pisał (chociaż może i warto do tego zachęcać). Ale powinniśmy wspólnie pracować nad tym aby:
Jeśli zespół dba o testy, to testy automatyczne też muszą stać się produktem. Testy automatyczne są kodem produktuW wielu produktach testy są obywatelem drugiej kategorii. Kod testów jest chaotyczny, brakuje tam jakichkolwiek standardów. To sprawia, że ostatecznie nie da się tych testów utrzymywać. Aby testy długofalowo dawały nam wartość musimy dla testów trzymać te same standardy co dla kodu funkcji. Dbać i wdrażać odpowiednie wzorce. Modernizować biblioteki. Refaktoryzować kod. To się powiedzie, jeśli posiadamy odpowiednią współpracę Dev-QA. Developerzy uczą i rozwijają kompetencje inżynierów jakości w obszarze dbania o standardy. Dzięki temu każdy dba o testy. Ale nawet wtedy można po prostu nie uruchamiać testów odpowiednio często… Testy uruchamiane przy każdej zmianieTesty, które nie są uruchamiane często dziczeją. Trwają bardzo długo. Są niedeterministyczne. Przez to nikt ich nie uruchamia. Testy muszą być uruchamiane jak najczęściej. W zasadzie przy każdej integracji z główną gałęzią trzeba uruchamiać testy. Dzięki temu dostajemy feedback natychmiastowo. Czy to nie będzie bolesne, jeśli testy automatyczne słabo działają? Takie podejście zadziała na nas jak Enabling Constraints – wymusi pisanie szybkich i stabilnych testów oraz podzielenie domeny tak, aby móc uruchomić tylko część testów. Jeśli nie narzucimy sobie takiego ograniczenia, to testy naturalnie nam się zdegenerują. Martin Fowler pisał na blogu:
PodsumowanieTo jest 5 praktyk, które u mnie niesamowicie zadziałały. Spowodowały skrócenie czasu poświęcanego na testy, jednocześnie bardzo wysoko zwiększając ogólną jakość. Co jeszcze polecisz? 📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |