Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (12)
Similaire à SkładQA 2018 - Daniel Dec
Similaire à SkładQA 2018 - Daniel Dec (20)
Plus de kraqa
Plus de kraqa (20)
SkładQA 2018 - Daniel Dec
- 1. DevQAOps - wyścigi na linii produkcyjnej - wczoraj, dziś i jutro. czyli o wąskich gardłach zespołów IT
- 2. O mnie Twitter: @_decu_ daniel.dec@qualitykeys.pl Quality Keys Blog: decunadaje.pl
- 3. Motywacja ● Artykuł testerów o statusie testerów ● Selenium ● Projekt Feniks ● GATC ● WORLD QUALITY REPORT 2017-18 ● Przyszłość QA ● Nowy klient/praca
- 5. 1. Czy testujesz efektywnie?* * a może przynajmniej efektownie ;)
- 6. 2. W jakim kierunku rozwinie się rola QA w ciągu najbliższych lat?
- 7. 3. Jaki “waste” spróbujesz usunąć w najbliższych iteracjach ?
- 9. LEAN ● Muda – Strata, czyli każdy element procesu, który nie dodaje wartości z punktu widzenia klienta. ● Muri – Przeciążenie ludzi lub maszyn prowadzące do problemów z bezpieczeństwem i jakością. ● Mura – Nierównomierność wynikająca z fluktuacji zamówień. TPS - Toyota Production System Taiichi Ohno and Eiji Toyoda, Japanese industrial engineers, developed the system between 1948 and 1975.[1]
- 10. Chalk circle - Gemba ● This exercise is also known as circle exercise or standing in the circle. ● “Watch!” ● Who should stay in chalk circle? ● Kizuki - Awarness, realization ● Retrospekcja?
- 12. Czym są “mudy” w projektach softwarowych?
- 13. 1. Nadprodukcja - “waste of overproduction” “Building the Wrong Feature or Product Building features (or worse, whole products) that no one needs, wants, or uses obviously wastes the time and efforts of everyone involved. We observed this waste affecting team morale, team code ownership, and customer satisfaction” ● Potrzeby użytkowników vs “to czego chce biznes” ● 64% bardzo rzadko lub nigdy nie używana https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used https://www.researchgate.net/publication/313360479_Software_Development_Waste
- 14. 1. Nadprodukcja - “waste of overproduction” ● Ficzery których nikt nie użyje ● Zduplikowane “ficzery” ○ Gdziekolwiek są (backlog, design, kod) ● Nieskończone udoskonalnie ○ Przeciwieństwo MVP ● Duplikacja testów ○ Pokrycie (warstwy) ○ Selenium (ścieżki) ○ Ręcznych ● Testy? ○ Które nie przynoszą wartości Miernik zapaszku: critical w nowym ficzerze … ale użytkownicy nie zgłosili
- 15. 2. Praca w toku ● Wszystko co zostało rozpoczęte, ale jest nieukończone, “in progress”, “suspended” → grube story ● Wszystkie uruchomione “projekty” ● Przetwarzanie zbyt wielu wymagań → up-front design ● Rozwijane długo żyjące branche/ficzery w dużych ilościach ● Nieprzetestowana funkcjonalność ● Niezintegrowane komponenty → czas od ostatniego “release” na środowisko testowe ● Przetestowana funkcjonalność, ale niezwolniona na produkcję Miernik zapaszku: czasy od ostatnich “release” na produkcję/UAT; nie kończymy sprintów
- 16. 3. Overprocessing, extra processing ● Niepotrzebne kroki w procesie ○ Np. powtarzanie tych samych informacji w różnych narzędziach ● Nieodpowiednie narzędzia ● Ręczne przygotowywanie raportów które można wygenerować ● “Raportowanie” swojej pracy przez zgłaszanie błędów które mogłyby być naprawione od razu ● Dokumentacja dla dokumentacji (np. Przypadki testowe) Miernik zapaszku: wszystko co musi być ręcznie utrzymywane i omijanie narzędzi bo są zbyt “ciężkie”, narzędzia “armaty” na wróbla
- 17. 4. Zbędny transport - Transportation Co transportujemy w IT? ● Transport wiedzy ● Czym więcej węzłów tym transport dłuższy → Oczekiwanie ● Pomidor - bo transport naraża na uszkodzenie przewożonej informacji ○ wymagania ● Transport kodu? → spawanie/mergowanie Miernik zapaszku: nie tego chciał klient, “zgubiły się” wymagania
- 18. 5. Zbędne ruchy - Motion … Extraneous cognitive load ● Multitasking → Context switching ● Suffering from technical debt ● Complex or large stories ● Inefficient tools and problematic APIs, libraries, and frameworks ● Unnecessary context switching ● Inefficient development flow ● Poorly organized code ● Unreadable code Miernik zapaszku: zawyżone estymacje, pracujemy wolniej, mała zmiana trwa dłużej
- 19. 6. Waiting - czasy oczekiwania ● Niestabilne wymagania i priorytety ● Decyzje ● Długi i późny deployment ● Długie i późne testy ● Niemiarodajne, niedeterministyczne testy i środowisko ○ “ 46% citing lack of data and unstable environments as the biggest hurdles” ● Feedback od klienta ● Developerzy czekają na testerów? Miernik zapaszku: późna informacja zwrotna, przełączanie pomiędzy zadaniami, długie cykle
- 20. 7. Defekty → przeróbki, poprawki ● Błędy w user stories, mock-upach ● Błędy w wymaganiach ● Nieprecyzyjne/błędne Definition of Done, kryteria akceptacyjne ● Techniczne skróty → impact na testowanie? ○ Dług techniczny ● Brak Root Cause Analysis (zapobieganie vs wykrywanie) ● Uboga strategia testów (brak strategii) ● Błędy które nie są naprawiane od razu? (switching context, wrzucane do narzędzia) Miernik zapaszku: Stosunek nowych błędów do naprawianych
- 22. ● Wyjście z mroku - Strategia ● Wymagania ● Jakie błędy są akceptujemy → czy musimy wszystko testować ● Ciągłe usprawnianie - Kaizen ● Testowanie funkcjonalne - krytyka ● Testy automatyczne ● Prewencja
- 23. Strategia testów! ● Context is the king! ● Jak? ● Nie chodzi o szablon ISTQB ● Jak powstaje dług?
- 24. Kick off Feature Do we need it? When it`s done?How do we test it?How do we deploy it? How much would that cost? When could it be ready? How would that fit to our architecture How fast should it work? Do we understand it? Are there any security risks? Where do we test it? Can we test it by end users directly? Is it small enough to cover minimal business need?
- 26. “Sometimes there will be commercial reasons to trade-off quality against other factors, or to watch out for situations where attention to quality costs more than the issues you are trying to avoid. ”
- 27. “Powinniśmy stać się częścią zespołu redukującą straty, nie produkującą je.” SkladQA - Daniel Dec 2018
- 28. Akceptowalne błędy - Analogia Spotify - Testy A/B - Przycisk z serduszkiem - Jakie testy wykonują? - Czy odejdę od nich? - Czy to mnie wkurza? - Czy jestem wliczony w koszt testów? - Do jakiej kategori userow zostalem zaliczony
- 30. QA and DEVs “Liz, we are also asking that coders help testers, and vice versa. And each side no longer looks at the other side as an enemy. Still, the testers are always trying to "break it." So, they maintain that attitude. And each coder views any break identified now as a 'win' for the team, not as a loss for his ego.” https://www.101ways.com/how-does-qa-fit-in/
- 31. Ile czasu poświęcamy na usprawnienia?
- 32. Motivation by improvement ● “Show them, tell them, have them do it, and then praise them.” ● Bohaterowie w akcji - troubleshooting, awarie itp. ● Nie mamy czasu na usprawnienia ● Japan vs Europa - kto “ciągle” się usprawnia → kultura
- 34. Quality build-in
- 36. Functional testing is not enough ● Testy strukturalne ● Przeglądy kodu ● Tester architektury? ● Skille Selenium nie pomogą, tu trzeba wejść na wyższy poziom tego jak działa software.
- 37. Automatyzacja
- 38. Jak wygląda technicznie nasza automatyzacja? ● Architektura ● Wolne, wciąż oparte mocno o GUI (Selenium) ● Struktura kodu, konwencje … Niedeterministyczność ● Typowa pętla ○ Mała odporność na zmiany ○ Ciągle w tyle ● Nie ma osoby która pilnuje podejścia i kodu! ● Inwestuj w code review!
- 39. Integration testing are a scum
- 41. 1. Czy testujesz efektywnie?* * a może przynajmniej efektownie ;)
- 42. Co tymi QAmi? → Kariera
- 43. Co mówimy nowym testerom? “Naucz się Selenium” Gall anonim “Zrozum i naucz się jak dostarczać wartościowe informacje w zespole które wpłyną na eliminację strat i wyższą jakość” Daniel Dec
- 44. Co jeszcze? ● Naucz i zrozum technologię w której realizujecie projekt ● Dowiedz się jak działa komputer, pamięć, procesor, wątki, przerwania … ● Naucz się rozumieć kod … po to aby rozumieć jakie jego części są niepokryte testami aby proponować brakujące ● Pracuj jak najbliżej klienta aby współtworzyć wymaganie które będzie dla Ciebie testowalne, bądź adwokatem klienta ● Nie specjalizuj się w pisaniu testów na poziomie interfejsu użytkownika (koszt, utrzymanie, długie pętle) ● Podejdź do testowania jakbyś miał zapłacić za produkt który dostarczacie ● Eliminuj “waste” z projektu
- 45. Co z tym DevOps? ● Dlaczego nie DevOps? ○ Nie można, nie da się ... ● Testowanie nieuchronnie wiąże się ze środowiskiem ○ ej programisto postaw mi srodowisko bo nie umiem ● Infrastructure as a Code ○ Wolałbym zainwestować w automatyzację środowisk niż Selenium ● Test environments - co drugi tester ma problem ze środowiskiem testowym #docker #ansible #puppet #octopust #terraform #aws #azure #etc.
- 46. 2. W jakim kierunku rozwinie się rola QA w ciągu najbliższych lat?
- 47. Future belongs to us - so what`s next? ● Więcej monitoringu, sztucznej inteligencji rozpoznającej anomalie ● Mniejsze zmiany, szybsze testy JIT, healthchecki → produkcja ● Mniej ciężkich testów integrujących → Contract Testing ● Mniej testów na najwyższej warstwie (selenium) → być może znikną zupełnie (enzyme etc.) ● Więcej eksploracji → testy strukturalne, śledzenie całego flow na niskim poziomie ● Zrezygnowanie z niektórych testów na rzecz A/B ● Większy nacisk na testy jednostkowe, TDD, XP ● Blockchain ● AI ● Naukowe podejścia
- 48. rEwolucja roli QA ● Techniczny tester “ninja” rozumiejący przepływy aplikacji, technologie, domenę, wpływ zmiany, analizujący ryzyka, wspomagający programistów, lidera i klienta w podejmowaniu decyzji ● Tester “artysta” → startupy, dobry kontakt z klientem, user-center-design, bardziej projektant aplikacji → kierunek “analyst” ● Genchi Genbutsu - Chalk circle → Quality Advisor/Coach → usprawniający procesy pod kątem optymalizacji i jakości, Kaizen QA ● Full-Stack engineer ● DevOps ● Selenium Testerzy … ● “Klikający testerzy” ….
- 49. 3. Jaki “waste” spróbujesz usunąć w najbliższych iteracjach ?
- 50. Wasty QA ● Brak DoR, DoD ● Brak automatyzacji - w ogóle ● Nieoptymalna automatyzacja - np. Odwrócony stożek zamiast piramidy ● Reagowanie zamiast prewencji ○ Współpraca przy testach jednostkowych ○ Przegląd kodu ● Środowiska testowe - !DevOps ● Brak umiejętności technicznych ● Brak strategii - optymalne testy ($$$) ● Brak czasu na usprawnianie!
- 52. Testing Cup Test Strategy challenge http://testingcup.pl/speaker-gawronska.html Zapraszamy ● Kamila Gawrońska ● Wojciech Gawroński ● Tomasz Wierzchowski ● Daniel Dec