Mapowanie funkcjonalności ERP pod kątem budowy systemu testów automatycznych - proszę o pomoc

3
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....

0
piotrpo napisał(a):
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.

Niżej napisałeś żeby zacząć od robienia porządku w backlogu. To od czego faktycznie lepiej zacząć? Najpierw zbieranie wymagań, czy porządki w backlogu

No i jak teraz proponujesz zrobić porządki w backlogu? W ramach projektu, zamiast epic = kwartał, poskładać to tak, żeby epici np. dotyczyły konkretnych modułów? I jak w apce jest 6 modułów to zrobić 6 epiców + jakiś bufor na inne rzeczy? Czy coś innego?

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.

Czy to koniecznie musi być automat od początku? A nie może zwykły przypadek testowy składający się z kroków do wykonania manualnie? (chociaż na początku, mniej komplikacji przy starcie).

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

Nie mamy testów napisanych. Najpierw bym pewnie podopisywał do tych testowalnych itemów user story i potem dopiero pod to pisał testy. Co sądzisz? I powiesz mi jak to "praktycznie" powiązać w azure? Po prostu do testowanego itemu dodać item test case i tam rozpisać test? Czy jakaś inna magia tu potrzebna? (dodam, że w azure kompletnie raczkuję)

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 :)

nawiązując do pogrubionego... 1) porządek w backlogu 2) dopisanie user story do testowalnych itemów 3) rozpisanie test casów 4) jak z tych test casów utworzyć dashboard żeby to zebrać do kupy? Podeślesz jakiś materiał? Ewentualnie krótko byś mi wskazał gdzie tego szukać?

Da się to ogarnąć bez dokupowania tego pakietu TEST PLANS w Azure?

Jaki tool w azure może mi zastąpić tą macierz śledzenia, żebym wiedział co jest pokryte testami a co nie? Czy odnajdę coś takiego bez tego dodatkowego pakietu Test plans?

Dziękuję za wyczerpującą odpowiedź :)

1
wesolynamdziendzisnastal napisał(a):

Niżej napisałeś żeby zacząć od robienia porządku w backlogu. To od czego faktycznie lepiej zacząć? Najpierw zbieranie wymagań, czy porządki w backlogu

Proponuję to połączyć, czyli robisz porządek w backlogu i organizujesz go tak, żeby być w stanie wylistować wszystkie wymagania biznesowe

No i jak teraz proponujesz zrobić porządki w backlogu? W ramach projektu, zamiast epic = kwartał, poskładać to tak, żeby epici np. dotyczyły konkretnych modułów? I jak w apce jest 6 modułów to zrobić 6 epiców + jakiś bufor na inne rzeczy? Czy coś innego?

Nie wiem "jak" to zależy od specyfiki projektu. Natomiast warto użyć hierarchi epic>feature>story w sposób, który pozwoli grupować pracę. To kiedy praca ma/była wykonana jest możliwe do określenia za pomocą pola iteration

Czy to koniecznie musi być automat od początku? A nie może zwykły przypadek testowy składający się z kroków do wykonania manualnie? (chociaż na początku, mniej komplikacji przy starcie).
Mogą być testy manualne, pytanie jak je umieścić w backlogu

Nie mamy testów napisanych. Najpierw bym pewnie podopisywał do tych testowalnych itemów user story i potem dopiero pod to pisał testy. Co sądzisz? I powiesz mi jak to "praktycznie" powiązać w azure? Po prostu do testowanego itemu dodać item test case i tam rozpisać test? Czy jakaś inna magia tu potrzebna? (dodam, że w azure kompletnie raczkuję)

Tak, dopisujesz puste US, dodajesz scenariusz, zamykasz story. Możesz sobie odfiltrować wszystko bo było w tym zakresie do zrobienia i ile zostało do zrobienia

nawiązując do pogrubionego... 1) porządek w backlogu 2) dopisanie user story do testowalnych itemów 3) rozpisanie test casów 4) jak z tych test casów utworzyć dashboard żeby to zebrać do kupy? Podeślesz jakiś materiał? Ewentualnie krótko byś mi wskazał gdzie tego szukać?

Na początek zerknij na query. Robi się je w prosty sposób i pewnie wystarczą. Zapisujesz po prostu warunki filtrowania.
https://docs.microsoft.com/en-us/azure/devops/boards/queries/using-queries?view=azure-devops&tabs=browser
Dashboards:
https://docs.microsoft.com/pl-pl/azure/devops/report/dashboards/overview?view=azure-devops

Da się to ogarnąć bez dokupowania tego pakietu TEST PLANS w Azure?

Jak widać wyżej - da się. Jedyne co mnie trochę zastanawia, to jak przeprowadzić te testy, czy raczej zaznaczyć, że zostały one wykonane (scenariusz po scenariuszu)

Jaki tool w azure może mi zastąpić tą macierz śledzenia, żebym wiedział co jest pokryte testami a co nie? Czy odnajdę coś takiego bez tego dodatkowego pakietu Test plans?

Jak nie chcecie płacić, to trzeba kombinować :) Moim zdaniem rozsądnie zorganizowany backlog + parę widoków jest w stanie dać ci to czego chcesz, ale trzeba to zrobić na własną rękę.

0

dzięki za odpowiedź :)

piotrpo napisał(a):
wesolynamdziendzisnastal napisał(a):

Niżej napisałeś żeby zacząć od robienia porządku w backlogu. To od czego faktycznie lepiej zacząć? Najpierw zbieranie wymagań, czy porządki w backlogu

Proponuję to połączyć, czyli robisz porządek w backlogu i organizujesz go tak, żeby być w stanie wylistować wszystkie wymagania biznesowe

Wylistować po prostu w wordzie (i tam robić odniesienia np. poprzez numery ficzerów w azure żeby to potem łatwo znaleźć), czy w azure jakoś to ogarnąć.

No i jak teraz proponujesz zrobić porządki w backlogu? W ramach projektu, zamiast epic = kwartał, poskładać to tak, żeby epici np. dotyczyły konkretnych modułów? I jak w apce jest 6 modułów to zrobić 6 epiców + jakiś bufor na inne rzeczy? Czy coś innego?

Nie wiem "jak" to zależy od specyfiki projektu. Natomiast warto użyć hierarchi epic>feature>story w sposób, który pozwoli grupować pracę. To kiedy praca ma/była wykonana jest możliwe do określenia za pomocą pola iteration

Czy to koniecznie musi być automat od początku? A nie może zwykły przypadek testowy składający się z kroków do wykonania manualnie? (chociaż na początku, mniej komplikacji przy starcie).
Mogą być testy manualne, pytanie jak je umieścić w backlogu

Nie mamy testów napisanych. Najpierw bym pewnie podopisywał do tych testowalnych itemów user story i potem dopiero pod to pisał testy. Co sądzisz? I powiesz mi jak to "praktycznie" powiązać w azure? Po prostu do testowanego itemu dodać item test case i tam rozpisać test? Czy jakaś inna magia tu potrzebna? (dodam, że w azure kompletnie raczkuję)

Tak, dopisujesz puste US, dodajesz scenariusz, zamykasz story. Możesz sobie odfiltrować wszystko bo było w tym zakresie do zrobienia i ile zostało do zrobienia

Nie rozumiem co oznacza dopisać "puste US". Mam napisać user story w DESCRIPTION danego ficzera po prostu? I co to znaczy zamykać story? Z itemów, które mogę dodać do itemu ficzer/wymaganie mam mam tylko task, test case, bug.

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.

Rozumiem kawałek o dodaniu tagu, ale reszty nie kumam. Jak już pododaje sobie tag "business funcionality" do itemów odnoszących się do konkretnych testowalnychh funkcjonalności (wraz z moimi user story w description), to mogę je jakoś wyfiltrować? Porządkować? Sortować? Jakbyś mógł powiedzieć 2 słowa jak mógłbym to wykorzystać.

ps. Dziś i jutro zapoznam się z dokumentacją, do której podesłałeś mi linki :)

1

#1 W Azure
#2Masz przygotować listę potrzebnych testów (pustych US), później wypełnić te US treścią i staną się scenariuszami. Może być task, czy test case - nie wiem, to jest element parametryzacji ADO.
#Tak, wchodzisz w Boards, klikasz filtr (lejek) i wybierasz, że chcesz mieć takie, a nie inne tagi

0
piotrpo napisał(a):

#1 W Azure

  1. jest jakieś narzędzie w Azure do tego, żeby sobie taką listę utworzyć?

#2Masz przygotować listę potrzebnych testów (pustych US), później wypełnić te US treścią i staną się scenariuszami. Może być task, czy test case - nie wiem, to jest element parametryzacji ADO.

  1. Okey, czyli zakładając, że scenariusze będą w test case'ach to chodzi Ci o to, żeby sobie poprzypinać te TC do testowalnych ficzerów/wymagań w pierwszym kroku, na potrzeby takiego jakby "oznaczenia ich", a w drugim kroku dopiero rozpisać scenariusze?

  2. Czy user story, jako zestaw wymagań ze strony biznesu mam sobie wpisywać językiem naturalnym w danym ficzerze/wymaganiu?

#Tak, wchodzisz w Boards, klikasz filtr (lejek) i wybierasz, że chcesz mieć takie, a nie inne tagi

ok :)

1
wesolynamdziendzisnastal napisał(a):
  1. jest jakieś narzędzie w Azure do tego, żeby sobie taką listę utworzyć?

Backlog

#2Masz przygotować listę potrzebnych testów (pustych US), później wypełnić te US treścią i staną się scenariuszami. Może być task, czy test case - nie wiem, to jest element parametryzacji ADO.

  1. Okey, czyli zakładając, że scenariusze będą w test case'ach to chodzi Ci o to, żeby sobie poprzypinać te TC do testowalnych ficzerów/wymagań w pierwszym kroku, na potrzeby takiego jakby "oznaczenia ich", a w drugim kroku dopiero rozpisać scenariusze?
    Tak
  1. Czy user story, jako zestaw wymagań ze strony biznesu mam sobie wpisywać językiem naturalnym w danym ficzerze/wymaganiu?
    Na moje, to możesz sobie to wpisywać nawet krzaczkami logiki symbolicznej, ale łatwiej będzie w języku naturalnym.
0

#2Masz przygotować listę potrzebnych testów (pustych US), później wypełnić te US treścią i staną się scenariuszami. Może być task, czy test case - nie wiem, to jest element parametryzacji ADO.

  1. Okey, czyli zakładając, że scenariusze będą w test case'ach to chodzi Ci o to, żeby sobie poprzypinać te TC do testowalnych ficzerów/wymagań w pierwszym kroku, na potrzeby takiego jakby "oznaczenia ich", a w drugim kroku dopiero rozpisać scenariusze?
    Tak
  1. Czy user story, jako zestaw wymagań ze strony biznesu mam sobie wpisywać językiem naturalnym w danym ficzerze/wymaganiu?
    Na moje, to możesz sobie to wpisywać nawet krzaczkami logiki symbolicznej, ale łatwiej będzie w języku naturalnym.

chciałeś się jakoś odnieść do tego? Bo wkleiłeś, a brak Twojej odpowiedzi, albo nie zrozumiałem jakiejś aluzji :D

0

@piotrpo: jeszcze kilka niuansów (ta, na pewno kilka :D)

  1. Załóżmy, że robimy porządek w backlogu. To jak najlepiej zrobić hierarchię itemów?

W tej kolejności?

Epic = nazwa modułu (1z6 w apce)
Feature
User Story
Taski
?

Gdzie tam requirementy wcisnąć? Czy traktować je po prostu na równi z ficzerami?

  1. Albo nie mam jakichś uprawnień w naszym projekcie, albo mam problemy ze wzrokiem, ale nie widzę nic takiego jak user story. W żadnych opcjach konfiguracji itd żeby dodać w backlogu taki widok. Cokolwiek.

Opierałem się na tym tutorialu od ms:

Dziewczyna z filmu wchodzi do boarda i od razu ma "stories backlog", a ja kolejno: Board, Analytics, View as Backlog

Powinienem mieć tu możliwość utworzenia dodatkowego backlogu dla samych user stories?

1
wesolynamdziendzisnastal napisał(a):

W tej kolejności?

Epic = nazwa modułu (1z6 w apce)
Feature
User Story
Taski

Tak, pytanie czy potrzebujecie akurat tyly poziomów - warto mieć uzasadnienie dla istnienia każdego z nich.

Gdzie tam requirementy wcisnąć? Czy traktować je po prostu na równi z ficzerami?

Moim zdaniem na poziomie ficzera będzie ok. Idealnie jak to będzie po prostu ficzer, oznaczony tagiem requirement (albo przypisany do obszaru biznes, pole value area)

  1. Albo nie mam jakichś uprawnień w naszym projekcie, albo mam problemy ze wzrokiem, ale nie widzę nic takiego jak user story. W żadnych opcjach konfiguracji itd żeby dodać w backlogu taki widok.

Patrzę w swojego Azure i mam, ale możliwe, że ktoś dodał tam taką jednostkę (nie wiem, nie znam się). Mam też pełne prawa na tej instancji, więc może to jest przyczyną.

Powinienem mieć tu możliwość utworzenia dodatkowego backlogu dla samych user stories?

Żaden problem - wyświetlasz cały backlog i ustawiasz filtr na typ wpisów.

0
piotrpo napisał(a):
wesolynamdziendzisnastal napisał(a):

Powinienem mieć tu możliwość utworzenia dodatkowego backlogu dla samych user stories?

Żaden problem - wyświetlasz cały backlog i ustawiasz filtr na typ wpisów.

Ale w moim projekcie (z moimi uprawnieniami) nie funkcjonuje w ogóle coś takiego jak user story. Nie mogę dodać takiego itemu, boarda, ani query :/

0

Jednej rzeczy jeszcze nie rozumiem, którą napisałeś @piotrpo .

piotrpo napisał(a):
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ę?

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.

User story = krótki opis biznesu co ma robić dana moduł/element - 1 zdanie zazwyczaj (np. system powinien sumować faktury).

Wymagania = szczegóły dotyczące powyższej funkcjonalności (np. 1. System powinien sumować faktury zaznaczone checkboxami. 2. Można zaznaczyć checkboxem maksymalnie 1000 faktur. 3. Sumowanie powinno się odbywać automatycznie po zaznaczaniu kolejnych faktur. itd.)

Testy piszę się dla sprawdzenia wymagań.

A z tego co napisałeś trochę wynika, że test pisze się pod User story.

I co to znaczy zamknąć historyjkę? Historyjka jest tworzona na początku przed rozpoczęciem ustalania detali i tworzenia kodu. Po historyjce tworzy się wymagania, które w trakcie realizacji projektu mogą ulegać zmianie. To raczej testy powinny być wtedy tworzone dosyć elastycznie, ALE pod wymagania? User story powinna być raczej sztywna, ale pod us nie napiszesz testów, bo to powinno być zazwyczaj maks. jedno zdanie na temat potrzeby biznesu.

Coś źle zrozumiałem?

1

Mój błąd - to co ci opisałem, ma sens w moim projekcie, nie koniecznie w twoim.
ADO pozwala na organizowanie backlogu w drzewo na kilku poziomach. To co wzięliśmy sobie z SAFe, to podział na epic / feature / user story. To jak wykorzystujemy te typy elementów backlogu jest dość daleko od tego co proponuje sam SAFe:

- (E) Stworzenie możliwości raportowania
    - (F) Przygotuj raport stanów magazynowych
         - (US) Przygotuj projekt raportu (UX)
         - (US) Implementacja raportu
         - (US) Przygotuj testy integracyjne *

Na poziomie ficzera, masz możliwie prostą i drobną funkcjonalność, która daje jakąś wartość do produktu. Czyli stanowi wymaganie biznesowe. Pod tym masz zadanie z gwiazdką, podczas którego, może zostać utworzone kolejne zadanie, albo task, albo test case (wybierz co wolisz) gdzie będzie umieszczony scenariusz testu.
Jak odpytasz ADO o te test case'y, to dostaniesz pełen test suit do wykonania przez kogoś.

ADO nie mówi ci jak masz zorganizować backlog - masz zestaw możliwości, które możesz użyć tak jak ci się podoba.

0
piotrpo napisał(a):

Mój błąd - to co ci opisałem, ma sens w moim projekcie, nie koniecznie w twoim.

ADO pozwala na organizowanie backlogu w drzewo na kilku poziomach. To co wzięliśmy sobie z SAFe, to podział na epic / feature / user story. To jak wykorzystujemy te typy elementów backlogu jest dość daleko od tego co proponuje sam SAFe:

- (E) Stworzenie możliwości raportowania
    - (F) Przygotuj raport stanów magazynowych
         - (US) Przygotuj projekt raportu (UX)
         - (US) Implementacja raportu
         - (US) Przygotuj testy integracyjne *

Na poziomie ficzera, masz możliwie prostą i drobną funkcjonalność, która daje jakąś wartość do produktu. Czyli stanowi wymaganie biznesowe. Pod tym masz zadanie z gwiazdką, podczas którego, może zostać utworzone kolejne zadanie, albo task, albo test case (wybierz co wolisz) gdzie będzie umieszczony scenariusz testu.
Jak odpytasz ADO o te test case'y, to dostaniesz pełen test suit do wykonania przez kogoś.

ADO nie mówi ci jak masz zorganizować backlog - masz zestaw możliwości, które możesz użyć tak jak ci się podoba.

czyli teoretycznie mógłby zostać ten układ itemów jaki mamy teraz, bo ostatecznie i tak taguje sobie te itemy, do których chce podpiąć test case i potworzyć relacje między nimi?

Bo właściwie po co mi teraz mieszać w tej hierarchii, którą mamy skoro na końcu i tak mogę sobie utworzyć query z parametrami jakie chce?

Nie wiem, czy się jasno wyraziłem :D

Nie do końca widzę teraz sens porządkowania itemów w ado. Jest na to jakiś konkretny argument? Biorąc pod uwagę sam proces pokrywania istniejących testowalnych itemów test case'ami.

Na upartego to i user story wtedy mi nie są potrzebne. Bo w sumie po co US skoro w ficzerze w opisie mogę napisać wymagania, do ficzera popodpinać test case'y i rozpisać pod te wymagania scenariusze?

Teoretycznie. Bo wiadomo, że pewnie byłoby to najlepsze rozwiązanie. Ale nie widzi mi się jakoś, jak przedstawię to wizję pm-owi, że nagle na zawołanie wywrócimy do góry nogami cały porządek itemów w 3 letnim projekcie :D To by była mała rewolucja. Nie wiem czy faktycznie potrzebna. Muszę poznać to uzasadnienie dla tego jednego punktu, o którym gadamy.

1

Potrzebujesz powiązania pomiędzy ficzerem (biznesowym) a scenariuszem testowym. Jednym ze sposobów powiązania jest umieszczenie tego test casa jako gałęzi ficzera.
Burdel w backlogu zawsze jest problemem, ale można wykonać zadanie bez zrobienia porządku. Problemy mogą się pokazać na poziomie raportowania - np. czy będziesz w stanie powiedzieć ile pracy związanej z tworzeniem testów zostało już wykonane i ile jeszcze musi zostać zrobione. Jeżeli świadomie podejmiecie decyzję "będzie jak będzie" to luz. Ja wolę mieć możliwość stwierdzenia, że mamy 500 testów do napisania, przygotowanie 20 zajęło nam miesiąc, już za ~2 lata będziemy mieć całość.

0
piotrpo napisał(a):

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.

@piotrpo, a powiedz mi, czy zamiast dodawania tagu, można byłoby sobie pooznaczać wszystkie te testowalne itemy poprzez odpowiednią, unikatową kombinacje Type i Vaue area w sekcji Classification? (Tag to ostateczność w naszym przypadku). Czy tag byłby w czymś lepszy od tego?

555.PNG

0

Znowu potrzebna porada Panowie, @piotrpo ;)

Jakieś koncepcje na dokumentowanie zmian, które wchodzę do releasów? Aby to można było też wykorzystać jako bazę do wyselekcjonowania potrzebnych test casów i móc przetestować dane obszary przed wypuszczeniem release'a?

Jakbyście to widzieli?

Fajnie jakby można było to trzymać w jednym miejscu i żeby nie było konieczności dodawania nowych itemów w Azure.

Czyli krótko mówiąc, mamy release nr 4675.

Dokument określa, że w release 4675 wchodzą zmiany:
x
y
z

Przetestowano je test caseami:
x: x1, x2, x3
y: y1, y2, y3
z: z1. z2, z3

Pozaznaczać w jakiejś macierzy na zielono i klepnąć z tego raport.

Coś w tym stylu.

Jak to jest u was rozwiązane?

0

Jak robisz release, to powinieneś przetestować wszystko, a nie to co "weszło". Skąd wiesz, że jakas zmiana nie rozwaliła czegoś w innym miejscu?

1 użytkowników online, w tym zalogowanych: 0, gości: 1