Between Scrum and Kanban - define test process for Agile methodologies

Editor's Notes

• #7: Dynamic changes in projects (suite your process to actual needs) – ex. When client not deliver requriements/not answer on question you can’t plan sprint, so you can’t use scrum
• #9: Musielismy sie zmierzyc z wizualizacja stanu projektu za pomoca taskboarda. Minimalizacja raportow QA, jak informowac o statusie testow na biezaca – integracja z taskboardemJak dobrze zarzadzac testami eksploracyjnymiJak zarzadzac statusami nowych funkcjonalnosciStatus pracy qa na taskboardzie – czyli w tym samym miejscu gdzie i status pracy reszty zespoluProject status on TaskboardStatus of all tasks visualised on Taskboard for client/ PMNo need of additional reportsQA ReportsRemove the need of qa reportsVisualistion issue state incliding testingVisualisation QA activitiesOne tool – how to repleace Test Case Management reportsHow to manage exploratory testingHow to manage issues status according to visualisationDefine QA role in projectsDefine the place of qa in our processOne process for different methodologies: Scrum, Scrum-approach, KanbanMeasure the quality and qa workScripting doesn’t work
• #11: Kiedy konczymy prace – czy mozemy polegac na kliencie.W Scrum, aby skonczyc sprint wszystkie itemy musza trafic w stan Done, ciezko tutaj polegac na kliencie.Sprint konczy sie demo, po ktorym klient robi sign off, niestety czest jest niedostepny lub nie czeka z sing off, wiec chcemy sie pozbyc tej zmiennejdo czesci z funkcjonalnosci dodaje poprawkiStan done w naszym wypadku jest ostatnim na po prawej stronie w taskboard, aby latwo klient widzial co czeka na niego. Jesli klient naprawde wspolpracuje, to dodajemy oczywiscie kolumne sign off.W Kanbanie nie jest to juz konieczne, nie mamy ograniczenia czasoweg, mozemy spokojnie czekac
• #12: Tutaj kilka slow dlaczego jest wazne aby qa byl kolejny stanem w etapie wytwarzania oprogramowani. Standrdowe workflowy niestety ich nie maja u musimy je edytowac
• #13: Zmieniaj tylko te czesci ktore nie sa widocznie dla klientow, nie wymagaja ich udzialu jesli to mozliwe
• #14: Jak rozroznic taski, dlaczego dla niektorych warto uproscic workflowy, punkt widzenia – czy mamy klienta dla taska czy niSingle – czyli bez klienta, jestesmy sami sobie klientem, np dzielimy prace na pewne kawalki – na przyklad takie jakie mozemy zrobic przez jeden dzien – planowanie pracy.- Client oriented – czyli takie ktore wymagaja wspolrpacy z roznymi rolami, nie zawsze to qa musi zaakceptowac taski, moze to byc technical lead, project manager, analityk, ...
• #16: Obrazek do poprawy,Cykl zycia softwaru – blecy akceptacji podczas wytwarzania funkcjonalnosci, bledy regresyjne sa dla juz oddanej funkcjonalnosci
• #17: Regresyjne – standard issue type (czyli dla rzeczy ktore juz skonczylismy – patrz slajd o Done)Akceptacyjne sub issue type, zawsze pod funkcjonalnoscia dla ktorej byly znalezione
• #18: Sub issue as failed test scenario (usuniete, ale rowniez wazne)
• #20: Dlaczego warto miec scisly proces i furtkeCzyli o wypinaniu i konwersji do standard issue typeesionCzy naprawde musimy wszystko naprawiac, moze czesc zechcemy naparwic pozniej, wiec zmienmy je z akceptance na reg
• #21: Przypomnijmy ze story posiada zawsze cala historie pod soba- All failed issues attached to storyHelicopter view - Zawsze patzym an calosc a nie czastkeQa testuje tylko story, gdy juz cale jest naprawione, testownaie pomniejszych rzeczy nie ma sensu:Przelaczanie sie miedzy wieloma funkcjonalnosciami nie jest efektywnieWplyw wprowadzonych zmian na reszte funkcjonalnosciPotrzebujemy retetowac cala funkcjonalnosc, czy nie? Decyzja do qa co tak naprawde musimy powtorzyc
• #23: Klienta interesuje ostateczny status, czy cos zostalo skonczone, lub w jakim miejscu sie znajduje, nie interesuje go ilosc skryptow testowych, ktore przeszy, ktore nie, tylko czy funkcjonalnosc jest gotowa czy nie. Praktycznie zaden PM czy klient mimo dostepu do narzedzi zarzadzania testami tam nie zagladal, zawsze wymagali oddzielnych raportow, na prosbe klienta, zawsze byl potrzebny test amnager ktory przedstawial dodatkowe stanyGoogle wygralo bo poprostu zwracala informacje ktore szukalismy. Tak samo u nas z taskboard. Jedno miejsce ktore dostarcza tego czego potrzebujemyAcceptance issues are hidden – widzimy jedynie ich liczbe dla konkretnergo taska - ale to juz konfiguracja
• #25: Skrypting nie dziala, nie chcemy tak pracowac jednak:Musimy informowac jakos o statusie funkcjonalnosciZarzadzac testami automatycznymiZarzadzac testami regresjiDostarczac skrypty testowe dla klienta – wykonywane przez nich w czasie UATScripting nie sprawdza sie w testach akceptacyjnych, gdy poznajemy aplikacje – chcemy ja poznawac tak jak nasz uzytkownik, mamy problem ze znalezieniem statusu funkcjonalnosci bo jest rozbity, zawsze sa jakies bledy z jirze mimo 100% wykonalnosci testowBardzo wazne tutaj. Poniewz ccemy szybko wykrywac bledy, mamy testowanie ciagle, tak naprawde nie ma czasu na scripting creation in advance
• #26: Raport wykoania testow nie mial sensu, nigdy nie bylismy w stanie napisac ile, ..Liczby klamalyUsuniete ze slajdow, ale warto wspomniec: -Infinite space in finite time - Manage your tests depends on timeMimo 100% egzekucji i tak trzba bylo sprawdzac status w 2 miejscach jira i qmetryOddzielne jiryStatus wymagan – ciezko bylo go znalesc, czy polaczyc go – JIRA – test Case managemen tool, zeby autoamtycznie sie updatetowalCo ma retestowc 0 tylko testy ktore poszly failedCo jesli zostala przepisana czesc funkcjonalnosci jeszcze raz wykonac testy ktore byly pass (jesli to zrobie z raportu wyjdzie ze nic nie zrobilem tego dnia)Opowiadanie czeczkaNot all issues assigned to test case4 failed tests – 6 issues assigned10 more issues in JIRA without test scenarion in test runAutomated tests in scope or not (CI)
• #27: Ciag dalszy poprzedniego slajduTesty eksploracyjne okazaly sie lepsze bo daja wieksza mozliwosc zarzadzania testerom, szczegolnie przy akceptaycjnych, retescie, oszczedzaja czas, sa wydajniejsze, koncentruja sie na calej funkcjonalnosci, a nie konkretnym przypadku testowym. Ich wyniki sa tez bardziej miarodajne i mowia wiecej. Latwiej je tez planowac jesli jestesmy ograniczni czasem, wykryc najbardziej krytyczne bledy najszybciej. Czy tez uczyc sie z uzytkownikiemAgile manifesto – postawienie na czlowieka, jego wiedze i doswiadzcenie, to on podejmuje decyzje, no i mozliwosc zarzadzania czasem –dostosowanie poziomu testow do mozliwosci czasowych
• #28: Heuristics, TestingDojos, SessionBasedTesting, CrossTesting, Checklists, RapidTesting, Tools, Context-Aware, DomainKnowledgeTesting Dojos – pair testing, work with othere, learn from themCross Testing – not pair testing but the idea that the same part should be tested by two testers / one after another. review other works, check what he find, talk and compare results. Different testers may be sensitive to differentfactors, or make different observations. The same tester may see different things atdifferent times or when intentionally shifting focus to different things.
• #29: Inne spojrzenie na metryki - 2 lata temu jedna z przentacjina testwarez byla o metrykach, rpzeczytalem wiele artylulow, jednak nigdzie nie znalezlem nic o tych ktore sa dla mnie najwazniejsze.
• #30: Qa do not improve quality, so measure on qa level .
• #31: Screen z metryka – szybkosc qa zalezy od jakosci jaka dostajemhy. Jest to tak naprade suma wszelkich testow jak i retestow. Czyli jesli cos dostaniemy zlego, odrzucimy to kilka razy, to nasza efektywnosc jest roznie mierzonaManager – przetestowaliscie tylko jedno storyQA przetestowalismy 4 story (za jazdtm razem to samo), ale za kazdym razem dostawalismy je z bledem