wesolynamdziendzisnastal napisał(a):
@piotrpo: Tak. Jestem w stanie przygotować taką listę. Nie będzie to ani szybkie, ani łatwe, ale jak najbardziej i wydaje mi się, że to powinien być w ogóle pierwszy punkt programu w moim przypadku. Zgadza się?
Tak, dlatego warto to zrobić starannie i w sposób zorganizowany, żeby ułatwić sobie życie w przyszłości.
Tak. Płaska struktura. Obok siebie, na tym samym poziomie mogą występować zarówno requirementy, ficzery, a pod to podpięte są taski. A to wszystko jest zapakowane w EPICi, które są po prostu do dzielenia tego wszystkiego na kwartały. Czyli Epic I = Kwartał III 2019, Epic II = Kwartał I 2021 itd.
Moim zdaniem taka organizacja backlogu w ADO jest pozbawiona większego sensu. Epopeje są jednostkami pracy a nie okresami. Każdą jednostkę pracy jesteś w stanie przypisać do okresu, za pomocą pola iteration (w każdym razie w moim ADO....). Warto zastanowić się nad bardziej produktywnym wykorzystaniem epopei do grupowania roboty pod względem obszaru (bezpieczeństwo, monitoring, zwiększenie możliwości integracji, rozbudowa funkcjonalności biznesowej (w jakimś obszarze). Gdybyś miał ficzery biznesowe zgrupowane w kilku epopejach, to wystarczyłoby oznaczyć te epopeje jakimś tagiem typu biznes functionality
i sru - masz z głowy problem utrzymania listy z początku postu rozwiązany na zawsze.
Wszystko co napisałeś się zgadza. Są w projekcie itemy, które nadają się do pokrycia testami funkcjonalnymi, a są takie, wyrwane z czapy, dla których już nie bardzo. Więc ogólnie trochę by się to rozjeżdżało - część itemów będzie/byłaby pokryta testami, a część nie.
To uzgadniacie sobie, że pod ficzerem będącym wymaganiem biznesowym trzeba dopisać user stories na testy funkcjonalne. Czyli dopisujecie sobie historyjkę do przygotowania pojedynczego testu automatycznego. Jak ktoś zamyka historyjkę, to dopisuje do niej informację o id testu, który został przygotowany.
Co do dashboarda masz na myśli konkret już w azure devops? Ja myślałem, żeby na początek żeby w ogóle ruszyć zrobić to w formie macierzy śledzenia, nawet w excelu. Co sądzisz?
W ADO da się robić własne dashboardy i kwerendy. Więcej roboty niż excel, ale pojedyńcze narzędzie, dostępne on-line ma swoje zalety.
Jak wszystko jest na zielono, to wiecie, że system robi to, co miał robić. To nie koniecznie jest związane z pisaniem nowych testów, masz udowodnić, że testowane jest wszystko, czego biznes oczekuje od systemu.
Jak już macie testy napisane, to wystarczy je powiązać z wymaganiem
Reasumując, od czego byś zaczął w moim przypadku?
Napisałem wyżej:
- zrobić porządek w backlogu
- dopisać historyjki na przygotowanie testów
- zacząć pisać testy
- dorobić kwerendę / dashboard whatever co pozwoli śledzić postęp tych prac
- powiązać wyniki testów (np. nightly) z wymaganiami, za pomocą jakiegoś dashboardu
- patrzeć na managerów ćpających zielone z wyników testów :)
i w innym arkuszu rozpisuję szczegółowo te przypadki, a w macierzy tylko zaznaczam na zielono, że przeszło i na czerwono, że nie przeszło.
Szkoda życia na robienie spredszitów.
Dopiero jak to utworzę (chociaż draft) to wrócić do tematu azure? Czy już w trakcie próbować to jakoś korelować? Tylko jak wtedy? Pod item w azure podpinać konkretny przypadek testowy? Czy tylko na początek poopisywać w itemach np. w description: pt 3.1.Z żebym wiedział jaki przypadek testowy go waliduje? A w arkuszu z macierzą numery itemów w azure, żebym łatwo mógł je wyszukać.
Nie ma co czekać z przerzuceniem do Azure. Albo robić to na początku, albo wcale. To tak jak byś najpierw pomalował mieszkanie, a później kupił drabinę.
Najważniejsze to zacząć w prosty sposób i żebym prosto mógł to wyjaśnić pm-owi.
heh....