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

Cześć.

Dostałem zadanie przygotowania koncepcji mapowania funkcjonalności systemu ERP, przy którym pracuję.
Ma to zostać wykorzystane do dalszych kroków w celu budowy systemu testów automatycznych.

W sumie jedyne założenia na ten moment to:

• powinno powstać coś na kształt mapy wszystkich funkcjonalności systemu;
• powinno być to łatwe w obróbce, w aktualizacji, w obsłudze, w zrozumieniu,
• pracujemy w azure devops, jeśli ma to jakieś znaczenie w tym wypadku.

Także temat mocno ogólnikowy i otwarty. Koncepcja powinna być ogólna, chociaż każda wskazówka i porada mile widziana.

Może powiedzcie jak to wygląda w waszych firmach?

W mojej poprzedniej firmie pokrywanie testami automatycznymi odbywało się na ścieżce:

dokument wymagań -> rozbicie dokumentu na moduły systemu -> możliwe przypadki użycia w ramach każdego modułu -> utworzenie kategoryzacji testów dla przypadków użycia (przez QA engineera, albo autora modułu) -> w ostatnim kroku na podstawie kategoryzacji rozpisanie testów przez testerów

Nie spotkałem się z czymś co miałoby przypominać jakąś komplementarną "mapę". Wiem, że były plany, żeby stworzyć jakiś rodzaj diagramu funkcjonalności, na podstawie którego można by było potem ustalać pokrycie przez testy, ale nie mam kompletnie wiedzy na ten temat.

Dodam, że mam niewielkie doświadczenie w QA. Nigdy wcześniej nie zajmowałem się czymś takim.

Z góry dziękuję za każdą pomoc i serdecznie pozdrawiam

Myśle że mało kto bawi się w takie "formalne" opisy, szczególnie dla istniejącego systemu. Większość firm pisze testy na bieżąco na zasadzie: piszemy nowy ficzer i częścią definition of done jest przygotować testy integracyjne i e2e.
Jeśli chodzi o formalne dokumentowanie to np. wg ECSS-E-ST-40C robisz to zgodnie z dokumentem wymagań, tzn musisz w dokumencje specyfikacji testów umieścić macierz, która przyporządkowuje testy do wymagań, a każdy test zawiera sekcje która wyjaśnia dlaczego ten konkretny test dowodzi że funkcja systemu działa.

Niestety w twoim przypadku obawiam sie że główny problem to będzie wyczarowanie listy funkcji systemu.

@Shalom: dziękuję za odpowiedź.

Niestety w twoim przypadku obawiam sie że główny problem to będzie wyczarowanie listy funkcji systemu.

i właśnie dokładnie o to chodzi. Masz jakąś choćby mglistą koncepcje na wyczarowanie takiej listy?

mogę prosić o sparafrazowanie? W jakim sensie macierz? Jak mogłoby to wyglądać?

Tabelka która w jednej kolumnie ma ID wymagania a w drugiej kolumnie ID testu który dowodzi ze to wymaganie jest spełnione :)

i właśnie dokładnie o to chodzi. Masz jakąś choćby mglistą koncepcje na wyczarowanie takiej listy?

Nie i to nie jest trywialna sprawa. Nawet jeśli macie dokumentacje to na 99% jest nieaktualna i na dobrą sprawę teraz to już tylko użytkownicy znają dostępne funkcje i pewnie nawet nie wszystkie. Dlatego testy pisze się razem z kodem, bo wtedy niczego się nie gubi.

@Shalom: o tej macierzy zdążyłem poczytać dlatego usunąłem, ale bardzo dziękuję za zainteresowanie tematem :)

Nie i to nie jest trywialna sprawa. Nawet jeśli macie dokumentacje to na 99% jest nieaktualna i na dobrą sprawę teraz to już tylko użytkownicy znają dostępne funkcje i pewnie nawet nie wszystkie. Dlatego testy pisze się razem z kodem, bo wtedy niczego się nie gubi."

Z tego co się orientuję to nawet dokumenty wymagań są dziurawe i raczej można to traktować bardziej jako wskazówkę niż pewnik. Ja wykonuję testy, albo eksploracyjnie, albo typowo zadaniowo i w określonym obszarze i charakterze.

Czyli najprościej jak teraz można byłoby spisać te funkcjonalności?

Każdy programista odpowiedzialny za dany moduł powinien spisać funkcjonalności dla swojego modułu? Chyba nie ma innej drogi?

No i w jakiej formie?

Wystarczyłoby np. techniką:

MODUŁ A
system powinien robić A.1
system powinien robić A.2
system powinien robić A.3

Coś w tym rodzaju? Z czymś takim się spotkałem w projekcie systemu informatycznego jakiejś przychodni bodajże. Ale nie jestem pewien, czy to oto chodzi.

Może da się prościej, jeśli to jest pisane w miare "nowocześnie" i backend wystawia np. jakieś RESTowe API. Wtedy można by bazować na dostępnych endpointach.

@Shalom: 1) Czyli należałoby jakoś wygenerować listę dostępnych endpointów? Czy ona po prostu gdzieś powinna być dostępna?
2) po uzyskaniu endpointów, tak jak wyżej pisałem, można umieścić je w kolumnie A, a w kolejnych kolumnach zamieszczać przypadki testowe i pokrycie zaznaczać sobie krzyżykami np.?
3) Czy pokrycie wszystkich endpointów przez testy da nam całkowite pokrycie funkcjonalności systemu przez testy?
4) jak zrobić żeby aktualizować tą listę endpointów żeby pokrycie testami nadążało za zmianami w systemie? Ręcznie dopisywać te endpointy do listy, załóżmy? Czy istnieje jakaś koncepcja żeby to było bardziej zautomatyzowane?

1. Kwestia technologii której używacie. Większość nowoczesnych rozwiązań pozwala opublikować specyfikacje OpenAPI albo w ogóle wygenerować Swaggera gdzie są wszystkie endpointy
2. Prawie, bo jeden endpoint może ogarniać więcej niż 1 rzecz
3. Z punktu widzenia backendu - tak. W praktyce warto mieć też jakieś testy selenium, żeby upewnić się że frontend i backend w ogóle się spinają
4. Nic nie robić. Określić definition of done w ludzki sposób. Nie ma zmiany w systemie która ląduje na produkcji zanim są do niej testy. Brak testów = task nie skończony. W ten sposób nie trzeba za niczym "nadążać".

@Shalom:

1. Czy żeby mieć aktualną listę funkcjonalności należałoby co jakiś czas generować tego swaggera? (tu muszę doczytać bo nie znam tej technologii) Czy może to już się samo jakoś aktualizuje?
2. Czy koncepcja generowania endpointów jest lepsza niż rozpisanie funkcjonalności systemu naturalnym językiem?
3. Wygenerowanie swaggera co jakiś czas powodowałoby, że i tak trzeba by "ręcznie rozszerzać" listę endpointów w arkuszu żeby móc sprawdzać/zaznaczać pokrycie endpointów przez testy?

1. Raczej sam się generuje :) Znów: kwestia technologii. Taki Spring w Javie czy FastAPI w Pythonie automatycznie generują i wystawiają i nic nie trzeba specjalnie robić.
2. Tak, bo kod to źródło prawdy i nigdy nie kłamie. Jeśli endpoint jest, to jest, a jak nie ma to nie ma. Nie można tego samego powiedzieć o pisanej słowno-muzycznej dokumentacji, która jutro będzie nieaktualna.
3. Jeśli chcesz mieć taki "arkusz" to tak. Ale tak jak pisałem, problem polega raczej na tym że chcesz oddzielić pisanie kodu od pisania testów, a to jest zwyczajnie zły plan. Jedyny sposób na utrzymanie dobrego pokrycia systemu testami to pisać je razem z kodem.

I tak jak pisałem, same endpointy to mało. Załóżmy że masz endpoint /getFile który pozwala pobrać plik z systemu. Ale gdzieśtam w kodzie programista zrobił sobie ifa że jak nazwa pliku kończy się na .zip to zipuje ten plik przed wysłaniem. Z samego endpointu nijak tego nie "widać".

@Shalom:

I tak jak pisałem, same endpointy to mało. Załóżmy że masz endpoint /getFile który pozwala pobrać plik z systemu. Ale gdzieśtam w kodzie programista zrobił sobie ifa że jak nazwa pliku kończy się na .zip to zipuje ten plik przed wysłaniem. Z samego endpointu nijak tego nie "widać".

zatem jak to udoskonalić żeby to było komplementarne? i żeby nie było "za mało"?

Ad. 3. a) A jest możliwe, że programista będzie pisał kod, a tester pisał testy do tego kodu? Czy raczej kompletnie niestosowana praktyka?
b) I w tym punkcie masz na myśli testy jednostkowe?

Potrzebujesz listy funkcji biznesowych, takich jak np. system pozwala na dodanie dokumentu WZ, system generuje raport stanów magazynowych itp. Nie wiem w jakiej formie macie wymagania od biznesu i gdzie jest dokument, który mówi co właściwie ten system ma robić. Dla każdego z tych punktów musisz podać w jaki sposób udowadniasz, że to czego chciał biznes działa, podając identyfikator testu, który to potwierdza. Google: Requirements Traceability Matrix

zatem jak to udoskonalić żeby to było komplementarne? i żeby nie było "za mało"?

Pisać testy równolegle z kodem :)

A jest możliwe, że programista będzie pisał kod, a tester pisał testy do tego kodu? Czy raczej kompletnie niestosowana praktyka?

Czemu ma być niemożliwe? To kwestia procesu w firmie. Możecie robić tak że jak developer skończy to przepina task na testera który pisze do tego testy e2e. Dużo częściej nie masz dedykowanych "testerów" tylko developerzy piszą testy do tego co napisali.

I w tym punkcie masz na myśli testy jednostkowe?

Nie, niekoniecznie. Mam na myśli testy automatyczne przynajmniej na poziomie jednego serwisu (czyli stawiamy serwis w teście, puszczamy odpowiednie requesty HTTP i sprawdzamy wyniki), a najlepiej w ogóle e2e.

@Shalom: A skąd będzie znane pokrycie przez testy korzystając ze swaggera?
W ramach niego istnieje jakieś narzędzie, które pozwala to wszystko połączyć: aktualizowanie endpointów + oznaczenie pokrycia przez testy?

To są zupełnie niepowiązane kwestie. Swagger służy do dokumentowania API i tyle.
Jak chcesz automatycznie liczyć pokrycie kodu to odpalasz testy z mierzeniem pokrycia, ale to ci pokaże pokrycie linii kodu, co niekoniecznie przekłada się na pokrycie endpointów czy biznesowych use-case.

@piotrpo: @Shalom Znowu potrzebuję waszej porady chłopaki.

Pracujemy w azure devops, jak już wspomniałem.

Znacie jakieś narzędzia, które mogą być przydatne do tworzenia, zarządzania dokumentami wymagań, a następnie określania ich pokrycia przez testy, w ramach tej platformy? Narzędzia, które można do tego celu wykorzystać i współpracują z azure devops?

Na razie potrzebuję głównie do tworzenia/zarządzania dokumentacją wymagań, z perspektywą na późniejsze wykorzystanie tego do pomiaru pokrycia.

Moim zdaniem to są zupełnie niepowiązane kwestie. To czy odpalacie się na Azure czy AWSie nie ma żadnego związku z dokumentowaniem wymagań systemu czy pokrycia testami. To trochę jakbyś pisał Jeżdże czarnym BWM, jaki polecacie plecak do chodzenia w góry?.

Wiele organizacji korzysta z https://en.wikipedia.org/wiki/Rational_DOORS

@Shalom: Na wykazie dostępnych integracji DOORS nie widzę Azure devops :| https://jazz.net/extend/integrations/#tool=Rational%20DOORS%20Next%20Generation

@Shalom: jak dobrze patrzę to rational doors od IBM kosztuje ponad 790 euro za 5 użytkowników miesięcznie.

Dramatycznie dużo jak na nasze potrzeby, wydaje mi się.

Kojarzysz jakieś tańsze alternatywy?

Nie i trochę wątpie żeby istniały, bo to się razem nie kompiluje. Albo ktoś ma projekty za dużo euro i potrzebuje takie formalizmy i dupochrony, albo yolo agile http://programming-motherfucker.com/ ;) Generalnie DOORsy widziałem używane namiętnie w ESA i w ESO, tylko że jak masz projekt za > 1mld euro to kilkaset miesięcznie to jak splunąć.

@Shalom: To żeś mi pomógł! Nie no, żartuję :).

A tak serio jakie mam tańsze alternatywy? Widzę w necie informacje na temat zarządzania wymagań za pośrednictwem Azure devops.

Istnieją tam jakieś wtyczki, które by pozwalały na te operacje, których potrzebuję?
Tworzenie wymagań
zarządzanie wymaganiami
tworzenie relacji wymagań z innymi artefaktami
oznaczanie pokrycia wymagań przez testy

Wydaje mi się, że na pierwszy rok ogarniania tego to i tak byłoby dużo.

Tych narzędzi są setki, tylko najgorsze, że nie ma podanych cen często + mało opinii w internecie, a do niektórych wcale. Potrzebuję czegoś sprawdzonego, bo inaczej to równie dobrze mogę rzucić lotką.

Tych narzędzi są setki, tylko najgorsze, że nie ma podanych cen często + mało opinii w internecie, a do niektórych wcale. Potrzebuję czegoś sprawdzonego, bo inaczej to równie dobrze mogę rzucić lotką.

@wesolynamdziendzisnastal może czas żeby firma zatrudniła jakiegoś specjalistę/managera od QA który się na tym zna? :)

Shalom napisał(a):

Moim zdaniem to są zupełnie niepowiązane kwestie. To czy odpalacie się na Azure czy AWSie nie ma żadnego związku z dokumentowaniem wymagań systemu czy pokrycia testami. To trochę jakbyś pisał Jeżdże czarnym BWM, jaki polecacie plecak do chodzenia w góry?.

@Shalom - ta Twoja analogia to tak trochę jak zapijanie martini zsiadłym mlekiem, bo Azure DevOps to nie jest alternatywa dla AWSa, ale dla połączenia Gita, Jiry i TeamCity.
Jako, że ADO odpala testy, to mogłoby też porównać listę testów, które przeszły z jakąś trzymaną gdzieś listą przypadków testowych czy innych wymagań. To pewnie się da jakoś ogarnąć, definiując jakieś własne pola dla user story, i pisząc jakiś skrypt, który potem porównuje run testów w pipelinie z tym, co wymagane w story.

@somekind - dzięki, że włączyłeś się w dyskusję.

Wołam pozostałych zainteresowanych @piotrpo: , @Shalom i temat idzie dalej :D

Na tą chwilę sprawa wygląda tak, że odpuszczamy wszelkie zewnętrzne narzędzia i rozszerzenia i skupiamy się na tych podstawowych możliwościach, które daje nam azure devops. Nawet ta część "Test Plans" na razie schodzi na drugi plan.

Mam ogarnąć póki co Test Case'y i w ogóle sposób na ROZPOCZĘCIE jakichkolwiek działań w tym kierunku.

Na tą chwilę nasza organizacja w projekcie, w azure devops wygląda tak:

• brak user story w ogóle
• mamy EPICi (które u nas stanowią okresy czasowe), w ramach których mamy zrealizować (lub w czasie przeszłym zrealizowano) jakieś wymagania, np.
  Epic - zadania na kwartał III
  i w ramach tego EPICa znajdują się requirementy, lub featury - do których popodpinane są taski.

I to jest wszystko.

Na dodatek w większości przypadków te itemy nie mają żadnych opisów. Jest zazwyczaj pusty item, bez opisu z samym tytułem (który stanowi cały opis danego ficzera, lub wymagania) oraz porobione relacje z innymi itemami - przydzielony do programisty.

Dokumentacja wymagań (chyba wcześniej wspominałem) nie istnieje. Wszystko jest klepane na zasadzie luźno zebranych wymagań/sugestii/błędów od ludzi korzystających z systemu a wymagania są rozproszone w wordach, mejlach itd.

Celem jest zbudowanie podstaw do tego, aby sukcesywnie pokrywać ficzery (na początku manualami, a potem automatami) żeby w ogóle ruszyć. Mogą być od razu automaty i manualne. Byleby zbudować te podstawy jakiejkolwiek organizacji testów.

I teraz w końcu pytanie do was ( @somekind :D), po zobrazowaniu wam obecnego stanu od czego powinienem zacząć, żeby najmniej bolało i żeby angażować jak najmniej osób?

Żeby było jasne. To nie musi trwać tydzień, czy miesiąc. To może trwać nawet rok, byle by nakreślić wizję co trzeba zrobić.

Czy tutaj na tym etapie jakieś szarpane pokrywanie test case'ami poszczególnych wymagań/ficzerów ma jakiś sens?

Czy w ogóle bez takiej solidnej dokumentacji wymagań spisanej naturalnym językiem jestem tu coś w stanie zrobić?

Jakie możliwości dają te podstawowe opcje testowe w azure, bez dokupowania pakietu Test plans? Dobrze rozumiem, że jedynie napisanie test case'a pod konkrenty ficzer, bez żadnej możliwości tego sortowania/porządkowania/automatyzowania?

Jeszcze raz dziękuję za pomoc i zainteresowanie tematem, który notabene jest bardzo ciekawy :) tylko moje małe doświadczenie trochę mnie teraz dławi.

Czy jesteś w stanie zidentyfikować co jest wymaganiem ze strony biznesu?

Udzieliłem się w dyskusji, żeby sprostować, iż Azure DevOps to nie to samo co Azure, no i poza tym myślałem, że szukasz jakiejś inspiracji jak tego ADO użyć do zautomatyzowania weryfikacji testów.
Ale jak w taskach nie ma nawet wymagań, to nie ma też kryteriów akceptacji, więc nie ma jak testować. Ergo - nie musisz chyba niczego robić, bo w obecnym stanie to i tak niemożliwe.

@piotrpo:
ale w odniesieniu do czego?

W odniesieniu do każdego requirementu/ficzera/taska w azure?

Czy po prostu dla każdej funkcjonalności systemu wypisanej "na piechotkę"?

Pytam, bo nie wiem czy dobrze zrozumiałem pytanie.

Ogólnie jestem w stanie ustalić każde wymaganie, w stosunku do każdego aspektu systemu, odnosząc się bezpośrednio do autora modułu, osoby odpowiedzialnej za jego aktualne utrzymanie, bądź pm. Więc (chyba) odpowiadając na Twoje pytanie - Tak.

Przekładając to na robociznę to by wyglądało np. tak:

A) w module x, w formularzu y, system ma ograniczenie wprowadzonych znaków od 0 do 100.

Wiem, że jest takie wymaganie, w ten sposób to funkcjonuje, zgodnie z założeniem więc mogę to spisać i pod to mogę rozpisać przypadki testowe.

B) w module Y, w formularzu Z, system blokuje mi możliwość zapisu zmian jeśli użyję znaków specjalnych.

Nie wiem, czy to w ten sposób ma funkcjonować, więc zwracam się do autora kodu i go o to pytam. Autor kodu mówi mi, że tak to ma funkcjonować. Zatem piszę pod to wymaganie i rozpisuję przypadki testowe (nawet i w tym azure devops).

I tak moduł po module, funkcjonalność po funkcjonalności, wymaganie po wymaganiu.

I dopiero jak z tym etapem się uporamy to wówczas możemy zacząć się bawić w porządkowanie tego na azure, tworzenie test planów, automatyzowanie tego.

@somekind odniesiesz się też?

Dzięki za zainteresowanie chłopaki :)

Pytanie jest proste: czy jesteś w stanie przygotować listę wymagań biznesowych. Takich typu "system obsługuje wiele magazynów", "system umożliwia wprowadzenie dokumentu WZ", "system generuje raport stanów magazynowych".

Pytam, bo z tego co zrozumiałem, macie w backlogu płaską strukturę elementów, które mogą pochodzić od biznesu, architekta, spajków itd. Nie każde z tych wymagań powinno być pokryte testami funkcjonalnymi. Twoim zadaniem jest przygotowanie tabelki, lub jej funkcjonalnego odpowiednika (np. jakiś dashboard), gdzie masz wymaganie biznesowe, przypadki testowe, które je walidują i wyniki walidacji. 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.

wesolynamdziendzisnastal napisał(a):

@somekind odniesiesz się też?

Nie mam pojęcia jak wygląda praca QA ani jak QA oznacza sobie co już przetestował, a czego nie.
Ja QA w zespole nie mam, mam za to acceptance criteria w story i piszę kod, który je spełnia.

@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ę?

**Pytam, bo z tego co zrozumiałem, macie w backlogu płaską strukturę elementów, które mogą pochodzić od biznesu, architekta, spajków itd. **

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.

**Nie każde z tych wymagań powinno być pokryte testami funkcjonalnymi. Twoim zadaniem jest przygotowanie tabelki, lub jej funkcjonalnego odpowiednika (np. jakiś dashboard), gdzie masz wymaganie biznesowe, przypadki testowe, które je walidują i wyniki walidacji. **

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.

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?

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.

Możesz rozwinąć podkreślone?

Reasumując, od czego byś zaczął w moim przypadku?

Wypisania wszystkich wymaganych od systemu funkcjonalności, dla każdej funkcjonalności - wymagania i dopiero na końcu przypadki testowe?

Rozbić to np. na moduły, sekcje itd i schodzić coraz niżej aż do pojedynczych funkcjonalności?

Moduł A
Sekcja A.1
Funkcjonalność A.1.1
F A.1.2
F A.1.3
Sekcja A.2
Funkcjonalność A.2.1.
F A.2.2.
F A.2.3.
Sekcja A.n+1
F A.n+1.1
Moduł B
i jw.

I np. w macierzy śledzenia dla każdej funkcjonalności oddzielnie np.:

funkcjonalność 3.1. -> przypadek testowy 3.1.z, pt 3.1.y, pt 3.1.x
funckjonalność 5.1 -> pt 5.1.k, pt 5.2.m

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.

Coś w tym rodzaju Piotrze?

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

Czy to mogą być testy typu e2d?

Czy mówimy cały czas o przypadkach testowych = scenariuszowych, pisanych językiem naturalnym np. Step 1 = kliknij formularz a Step 2 = wpisz 200 Step 3 = kliknij Save? Czy o czymś w szerszym kontekście? (cały czas rozmawiając w kontekście samego początku :) )

Najważniejsze to zacząć w prosty sposób i żebym prosto mógł to wyjaśnić pm-owi.