GoldenLine
Zaloguj się
Łukasz K.

Łukasz K. powrot do biegania

Temat: czy mierzycie w jakis sposob jakosc testow?

tak sobie wczoraj pomyslalem, ze w kazdej firmie w ktorej pracowalem to my (testerzy) bylismy od sprawdzania jakosci, szukania bledow innych itp a nas nikt nie kontrolowal, nie mielismy zadnego systemu oceny testow a w obecnym miejscu pracy parwdziwe testy dopiero powstaja wiec moze warto by zaczac cos takiego robic, chociazby po to, zeby moc pokazac ze cos idzie ku lepszemu, moze to by przekonalo skostniale urzedowe umysly...
czy stosujecie cos takiego u Was w firmach albo moze macie pomysly jak mozna by ocenic/zmierzyc jakosc testow (funkcjonalnych)?
na pewno mozna zmierzyc stopien pokrycia kodu, mozna policzyc liczbe zgloszonych bledow w trakcie testow a takze liczbe bledow zauwazonych juz po wdrozeniu...
a jakies inne pomysly?
chodzi mi o testy zarowno manualne jak i automatyczne...
Link do wypowiedziLink
Dawid K.

Dawid K. Head of QA

Temat: czy mierzycie w jakis sposob jakosc testow?

U nas korzystamy z nastepujacej definicji jakosci: ..."jakos to bedzie" i ogolnie jest dobrze...zreszta Lukasz doskonale to wiesz :)
Link do wypowiedziLink
Krzysztof Kukla

Krzysztof Kukla Test Manager

Temat: czy mierzycie w jakis sposob jakosc testow?

Hej Lukasz,

Metryki:
1) Tracebility - pokrycie wymagan testami
2) Code Coverage - nie musze tlumaczyc

I teraz jesli:
1) Traceblity ~100% dla najwazniejszych wymagan (nie dla wszystkichm, ale tych najwazniejszych)
2) CC > 30%
to jest b. dobre pokrycie (b. dobra jakosc testowania).

Ponadto, przydalo by sie wdrozyc proces review test procedur oraz
test case-ow, tak aby miec pewnosc, ze test faktycznie pokrywa dana funkcjonalnosc.

PS Oczywiscie to tylko teoria, w praktyce jest tak, jak pisal Dawid "jakos to bedzie" :)

KKKrzysztof Kukla edytował(a) ten post dnia 08.07.08 o godzinie 10:57
Link do wypowiedziLink
Dariusz P.

Dariusz P. Wdrażanie i
zarządzanie
innowacją w
korporacjach, m.in.
R...

Temat: czy mierzycie w jakis sposob jakosc testow?

Krzysztof Kukla:
>
2) CC > 30%

O proszę - czyli robicie też white-box testing jak rozumiem? To chyba rzadkość. Mam wrażenie, że większość testerów specjalizuje się w black-boxie :)
Ponadto, przydalo by sie wdrozyc proces review test
procedur oraz test case-ow, tak aby miec pewnosc, ze
test faktycznie pokrywa dana funkcjonalnosc.

To zachowanie, z którym ja spotykam się praktycznie od początku swojej przygody z QC. O ile w Eracencie była to lekka partyzantka o tyle, na przykład, w LHSie proces review testów był całkiem konkretnie opisany i konkretny: specjalne formularze do zgłaszania 'findingów' etc. Według mnie b. fajna (i praktyczna) sprawa :) (chociaż oczywiście wydłuża sam proces przygotowania testów).

Pozdr,
DP.
Link do wypowiedziLink
Łukasz K.

Łukasz K. powrot do biegania

Temat: czy mierzycie w jakis sposob jakosc testow?

no wlasnie Dawid wiem, ze jest tak, ze jakos to bedzie:) niestety...
ale to co Krzysztof proponuje jest ok, ale czy naparwde nie ma jakichs innych miar? kto kontroluje kontrole?:) zastanawiam sie, czy wynika to z tego, ze testy i tak wielu uwaza za zbedny wydatek, wiec testy testow sa podwojnie zbedne czy tez raczej z przeswiadczenia, ze skoro mamy testy to juz jestesmy wspaniali, wiec po co robic cos wiecej...
a jesli chodzi o sprawdzanie dokumentacji, przeciez na to nigdy nie ma czasu ani chetnego by sie tym zajal...;/Łukasz K. edytował(a) ten post dnia 08.07.08 o godzinie 12:21
Link do wypowiedziLink
Krzysztof Kukla

Krzysztof Kukla Test Manager

Temat: czy mierzycie w jakis sposob jakosc testow?

Dariusz P.:
Krzysztof Kukla:
>
2) CC > 30%

O proszę - czyli robicie też white-box testing jak rozumiem? To
chyba rzadkość. Mam wrażenie, że większość testerów specjalizuje się w black-boxie :)

Darek,

To, ze to napisalem to wcale nie znaczy, ze to robimy :).

I jeszcze jedno zdanie odnosnie tego co napisal Lukasz - testerzy nie sa od jakosi tylko od znajdowania bugow (temat rzeka oczywiscie, ale to znajdowanie bugow wlasnie jest pryncypalem testowania). Pozwole sobie otworzyc nowy watek odnosnie tego tematu (co by to wicej watkow na forum bylo).
Link do wypowiedziLink
Dawid K.

Dawid K. Head of QA

Temat: czy mierzycie w jakis sposob jakosc testow?

Łukasz K.:
a jesli chodzi o sprawdzanie dokumentacji, przeciez na to nigdy nie ma czasu ani chetnego by sie tym zajal...;/[edited]Łukasz K.

W tym momencie uczestnicze w projekcie, w ktorym poswieca sie jednak duzo czasu na dokumentacje i musze powiedziec, ze efekty od razu widac. Praktycznie wszystko jest na czas i zgodnie z oczekiwaniami klienta. Szkoda tylko ze niektorzy tam na gorze dopiero teraz sobie przypomnieli ze takie podejscie moze przyniesc wiele korzysci :)
Link do wypowiedziLink
Łukasz K.

Łukasz K. powrot do biegania

Temat: czy mierzycie w jakis sposob jakosc testow?

ale to jest sytuacja marzenie, gdzie prawdopodobnie jest to nowy projekt...a czasem mozna wpasc w gowno po sama szyje, projekt 20 letni, dokumentacja zniknela w mrokach dziejow i co tutaj zrobic? ;/
Link do wypowiedziLink
Krzysztof Kukla

Krzysztof Kukla Test Manager

Temat: czy mierzycie w jakis sposob jakosc testow?

Lukasz,

Pisalem o tym na innym forum SJSI ale pozwole sobie skopiowac. Metoda jest sprawdzona.

###

Zakladamy, ze Systemu nie posiada wymagan (lub sa ale niekompletne, przestarzale, etc.). Zakladamy rowniez, ze System jest znany przez testera (tester to zwykle jedyna osoba, ktora wie najwiecej :).

Bierzemy, siadamy i robimy analize, czyli rozkladamy system na w miare atomowe kawalki/funkcjonalnosci, spisujemy je w postaci listy (chodzi o spisanie tytulow, bez zadnych opisow !!!). Czesem do tego celu mozemy posluzyc sie manualem (jesli jest) lub jakas inna dokumentacja.

Mogbym tu wkleic przykladow liste tytulow wymagan ale wolalbym tego nie robic ze wzgledu na Policy.

Czasem mozna zalozyc, ze kazdy formularz aplikacji to 1 wymaganie. Wszystko zalezy od systemu. Czasem oczywiscie jest to bardzo zlozone (nie latwe) zadanie. Jednakze, w ciagu 1-3 dni jestesmy w stanie przygotowac taka liste 100 - 500 tytulow wymagan (im wiecej tym lepiej), przy czym wymagania moga byc pogrupowane w tzw. Functional Area.

Nastepnie zbieramy wszystkie istniejace testy i probujemy zmapowac je do tych wymagan. Czasem jest tak, ze jeden test pasuje do wielu wymagan, czasem jedno wymaganie jest pokryte wieloma testami.

I tu uwaga, jesli mamy wymaganie i do niego podlaczone sa jakies testy, ale czujemy, ze wymaganie nie jest wystarczajaco pokryte to:
1) Testy sa kiepskie (lub)
2) Wymaganie to nie jest atomowe tzn. mozna je rozbic.

Jesli mamy jakis test nie podlaczony do zadnego wymagania, to znaczy, ze... nie wypisalismy wszystkich.

Mierzenie Requirements Coverage jest teraz banalnie proste. Oczywiscie dla duzej ilosci testow i wymagan nalezy wykorzystac toola w stylu QC, choc Excel tez moze byc!

My wykorzystujemy Quality Center w nastepujacy sposob:
1) Requirements - tu wrzucamy tytuly wymagan
2) Test Plan - tu umieszczamy testy
3) Test Lab - tu jest robiona egzekucja (testow).

Dziala to fajnie a Coverage jest obliczany automatycznie.

Metoda daje oczywscie szacunkowey poglad, ale zawsze lepsze to niz nic czyli zgadywanie.
Link do wypowiedziLink
Łukasz K.

Łukasz K. powrot do biegania

Temat: czy mierzycie w jakis sposob jakosc testow?

dzieki za info
niestety wszystko opiera sie na zalozeniu ze tester zna system, a w obecnym miejscu pracy (KE) jest to zalozenie bledne:) systemu nie zna nikt, wymagan nie zna prawie nikt (3 losowe osoby odpowiedza inaczej na pytanie o wyjasnienie jak to wlasciwie powinno dzialac), nie ma dokumentacji projektu od wielu wielu lat, nowy release dostajesz z notatka - jest nowa wersja(koniec notatki)...zero info o tym co zostalo zmienione...koszmar testera:D
i to tyle, probuje walczyc, zmieniac mentalnosc, ale nie jest lekko:)
Link do wypowiedziLink
Jakub Thiele-Wieczorek

Jakub Thiele-Wieczorek Software QA
Specialist/QA
Manager

Temat: czy mierzycie w jakis sposob jakosc testow?

Dariusz P.:

To zachowanie, z którym ja spotykam się praktycznie od początku swojej przygody z QC. O ile w Eracencie była to lekka partyzantka o tyle, na przykład, w LHSie proces review testów był całkiem konkretnie opisany i konkretny: specjalne formularze do zgłaszania 'findingów' etc. Według mnie b. fajna (i praktyczna) sprawa :) (chociaż oczywiście wydłuża sam proces przygotowania testów).

Darku,

Co dokladnie uwazasz za partyzantke? Chetnie dowiem sie, w czym proces w LHS jest lepszy od naszego (poza "specjalnymi formularzami" :) ) aby wiedziec, co nalezy ewentualnie poprawic. Co oznacza "calkiem konkretny"?
Link do wypowiedziLink
Krzysztof Kukla

Krzysztof Kukla Test Manager

Temat: czy mierzycie w jakis sposob jakosc testow?

Jeszcze odnosnie "script review"...

W mojej poprzedniej firmie, jako, ze pracowalismy zgodnie z CMM Level 5 przeglady skryptow testowych byly formalnymi inspekcjami i nawet byl specjalny tool do tego stworzony. Proces review wygladal doslownie jak w sylabusie ISTQB, czyli planning, kick-off meeting, review, follow-up, etc. Wymagana ilosc osob to 3-5 i nie bylo przepros. Ktos madry wyliczyl, ze podczas code review ZNAJDOWANYCH JEST 60-70% BLEDOW!!! Czyli jak widac potezne narzedzie to jest.

W obecnej firmie robimy to w mniej formalny sposob, jako peer-to-peer meting, ale nigdy nie jest tak, ze dany skrypt jest konczony bez takowego review.

KK
Link do wypowiedziLink
Dariusz P.

Dariusz P. Wdrażanie i
zarządzanie
innowacją w
korporacjach, m.in.
R...

Temat: czy mierzycie w jakis sposob jakosc testow?

Jakub Thiele-Wieczorek:

Darku,

Co dokladnie uwazasz za partyzantke? Chetnie dowiem
sie, wczym proces w LHS jest lepszy od naszego (poza
"specjalnymi formularzami" :) ) aby wiedziec, co
nalezy ewentualnie poprawic.

Cześć Kuba,

skoro działa to po co coś poprawiać? ;)
Co oznacza "calkiem konkretny"?

1) po pierwsze - primo - jest to formalny proces (z własnymi dokumentami, procedurami, terminami), w zasadzie nie wiem czy jest możliwość pominięcia tego etapu

2) po drugie - primo - proces jest przeprowadzany nie tylko przez innych testerów (których w ten sposób weryfikują pracę swoich kolegów) ale przez programistów oraz analityków (biznesowych) - co daje oczywistą korzyść w postaci spojrzenia na problem z różnych poziomów i podejść do tematu

3) po trzecie - primo ultimo! - jest konkretna kategoryzacja 'findingów', np. pod kątem tego czy tester napisał coś niezgodnego ze specyfikacją, czy źle zrozumiał ideę/skonstruował coś co w zasadzie nie nadaje się do przetestowania danej właściwości produktu, czy też pominął jakąś funkcjonalność, etc.

4) po czwarte - Carpie Diem Bonaparte! - te "specjalistyczne formularze" mają wbrew pozorom wiele zalet -> na ich podstawie jasno widać czy ktoś w ogóle się wziął za to review czy nie (jeżeli nie to wiadomo, że należy go spacyfikować aby to zrobił), team leaderzy testowi/menadżerzy testowi mogą na podstawie takich dokumentów wyciągać wnioski co do najczęściej popełnianych przez testerów błędów i ewentualnie na ich podstawie przygotowywać 'best practices'. Jest to też podstawa aby z testerem porozmawiać na temat popełnianych przez niego pomyłek. I wg mnie jest to również podstawa aby raz na pół roku/rok zrobić review "specjalistycznych formularzy" i podsumować co należy poprawić a czym możemy się pochwalić.

5) po piąte - piąty grosik dla Jadzi... - taki sformalizowany i udokumentowany review zdejmuje część odpowiedzialności z testera. W końcu X (zazwyczaj ~4-5) kompetentnych osób sprawdziło to co zrobił i zatwierdziło tą pracę. Jeszcze jedna uwaga: w tym punkcie ktoś mógłby się przyczepić, że takie podejście pozwala testerowi na odwalanie swojej pracy: bo po co się wysilać i przepracowywać skoro i tak wyniki pracy zostaną później skorygowane bądź też zostaną wytknięte pominięte przez testera rzeczy. W najgorszym wypadku i tak jeżeli osoby dokonujące review nie zauważą braków/błędów/niedociagnięć to i tak odpowiedzialność się rozmyje. Cóż... to fakt - ale po to są te "specjalistyczne formularze", żeby można było dokumentować pracę leserów a później wyciągać z niej konsekwencje ;)

Czy to przydatne podejście? Mi się bardzo podoba... ale być może wynikać to z tego, że jestem zwolennikiem tego, żeby (w miarę możliwości) wszystko zostało sprawdzone nie przez jedną a przez kilka osób. I najlepiej, żeby zostały dowody tej radosnej twórczości na wypadek gdyby trzeba je wyciągać (do obrony) przy okazzji jakiejś wpadki.

W Eracencie... cóż - sam wiesz jak jest. Z drugiej strony biorąc pod uwagę, że przez 1.5 roku mogło się coś zmienić to przepraszam za moje pochopne stwierdzenie o 'partyzanckim' podejściu do tematu. Pisałem oczywiście o moich wrażeniach sprzed pracy w Capie.

Pozdrawiam i mam nadzieję, że mój monolog pozwolił Ci chociaż w podstawowym stopniu zaspokoić ciekawość. Jeżeli nie to czekam na pytania, chętnie podejmę rękawicę i stanę na ubitej ziemi ;)

DP of former Eracent employees ;)Dariusz P. edytował(a) ten post dnia 09.07.08 o godzinie 09:15
Link do wypowiedziLink
Jakub Thiele-Wieczorek

Jakub Thiele-Wieczorek Software QA
Specialist/QA
Manager

Temat: czy mierzycie w jakis sposob jakosc testow?

Darek,

Dziękuję za wyczerpującą odpowiedź.

Podsumowując, wygląda na to, że najważniejsze punkty (poza lepszą dokumentacją) są następujące:
-Review jest przeprowadzane przez większą ilośc osób, co poza niezaprzeczalnymi zaletami o których wspomniałeś ma tę wadę, że stanowi dodatkowe obciążenie dla przedstawicieli działów innych niż QC. W związku z tym myślę, że w sytuacjach, w których pracy jest więcej niż ludzi (a zdarza się to wyjątkowo często), albo takie dodatkowe review jest praktycznie nie do wyegzekwowania albo powoduje dodatkowe opóźnienia w projekcie. Cóż, coś za coś...
-Większa formalizacja - tu zgodzę się, że pomimo dodatkowego "overheadu" gra jest warta świeczki.
-Kategoryzacja znalezionych błędów - świetny pomysł. U nas na razie wprowadzona na zasadzie określenia, po której stronie produktu wystąpił błąd (BE/FE) oraz jak bardzo jest istotny (LOW/MED/HIGH/CRITICAL, oczywiście istnieje zbiór kryteriów, które określają, która z kategorii najbardziej do niego pasuje; tak, za Twoich czasów jeczcze tego nie było ;) ). Ale dodanie kategorii typu błąd w specyfikacji/scenariuszu/wykonianiu testu na pewno zwiększyłoby czytelnośc wyników, a przy tym byłoby przydatne w celach statystycznych, mogących niekiedy służyc do znajdywania słabych punktów procesu.

Czasem dobrze jest dowiedziec się, jak wygladają podobne procesy w innych firmach. Można z tego wyciągnąc ciekawe wnioski.

Chętnie jeszcze podyskutuję o tym z Tobą przy piwie :)
Link do wypowiedziLink
Dariusz P.

Dariusz P. Wdrażanie i
zarządzanie
innowacją w
korporacjach, m.in.
R...

Temat: czy mierzycie w jakis sposob jakosc testow?

Jakub Thiele-Wieczorek:
>
-Review jest przeprowadzane przez większą ilośc osób,
co poza niezaprzeczalnymi zaletami o których wspomniałeś
ma tę wadę, że stanowi dodatkowe obciążenie dla
przedstawicieli działów innych niż QC.

To fakt. Ale musisz wziąć pod uwagę pewną konkretną różnicę pomiędzy Eracentem i - na przykład - LHSem: tam KLIENT płaci za czas, który pracownik LHSu poświęci na analizę pracy testera. Tak więc czasem może być tak, że w interesie firmy jest zaprząc do projektu kilka dodatkowych osób o ile klient za to zapłaci ;)
W związku z tym myślę, że w sytuacjach, w których pracy
jest więcej niż ludzi (a zdarza się to wyjątkowo często),
albo takie dodatkowe review jest praktycznie nie do
wyegzekwowania albo powoduje dodatkowe opóźnienia w projekcie. Cóż, coś za coś...

To nie do końca prawda. Jeżeli proces przeprowadzany jest 'partyzancko' to może brakować zasobów do jego przeprowadzenia ale tak jak pisałem wcześniej: w projekcie, w którym biorę aktualnie udział taki review to integralny element procesu. Na ten
etap przewidziane jest XX czasu i zasobów. I tyle... podchodzi się do niego tak samo jak do planowania, pisania i wykonywania testów :)
Chętnie jeszcze podyskutuję o tym z Tobą przy piwie :)

Ty to umiesz namówić... ;)

Do zobaczenia,
DP.Dariusz P. edytował(a) ten post dnia 09.07.08 o godzinie 12:59
Link do wypowiedziLink
Adam Pucko

Adam Pucko Quality Engineer

Temat: czy mierzycie w jakis sposob jakosc testow?

Z testami możemy postąpić tak, jak ze wszystkim inny, czyli:
spisujemy nasze cele/zadania w danym kontekście (organizacja/projekt) uzgadniając je z klientami - w przypadku procesu testowego są to przeważnie: management, kierownicy projektów, programiści, itd.
Uważa się, że sensowne cele powinny być SMART, czyli min. mierzalne, więc:
opisujemy miary, których chcemy/musimy/możemy używać, aby wiedzieć czy realizujemy nasze cele i jak nam idzie.
Zaczynamy wykonywać nasze zadania, mierzyć, porównywać i podnosić jakość.
Często dopytujemy się klientów czy są zadowoleni (pamiętając, że klienci są wybredni, często zmieniają swoje wymagania i w ogóle rzadko kiedy wiedzą czego chcą i czego tak na prawdę potrzebują...)

Najistotniejsze w tym wszystkim jest to, aby razem z klientem dojść do tego, co jest dla niego tak na prawdę najważniejsze i czy możemy mu to dostarczyć (i na kiedy, i ile będzie to kosztować :) (w kontekście testów dobrym miejscem na opisanie tego jest np. Test Plan).

Przykładowe cele zespołu testowego:
testy mają oszacować i wizualizować jakość produktu lub usługi - a więc czy klient podobnie oceni jakość produktu?
(mierzymy ile i jakie defekty zgłosi klient np. przez najbliższe dwa lata ;). To czy dobrze szacujemy jakość produktu możemy oszacować na podstawie szacowanego pokrycia (kodu różne standardowe metryki)/wymagan).

Inny cel:
Testy mają raportować ważne defekty jak najszybciej - a więc można spojrzeć na histogram zgłaszanych defektów - czy najważniejsze defekty były zgłaszane na początku?

Inny cel:
testerzy mają wykonać jak najwięcej testów! Jakość mierzymy poprzez liczbę wykonanych testów...

Najważniejsze: ustalić cele testów w danym projekcie.

adam
Link do wypowiedziLink

konto usunięte

Temat: czy mierzycie w jakis sposob jakosc testow?

Krzysztof Kukla:
Hej Lukasz,

Metryki:
1) Tracebility - pokrycie wymagan testami
2) Code Coverage - nie musze tlumaczyc

I teraz jesli:
1) Traceblity ~100% dla najwazniejszych wymagan (nie dla wszystkichm, ale tych najwazniejszych)
2) CC > 30%
to jest b. dobre pokrycie (b. dobra jakosc testowania).

Ponadto, przydalo by sie wdrozyc proces review test procedur oraz
test case-ow, tak aby miec pewnosc, ze test faktycznie pokrywa dana funkcjonalnosc.

Hej!

Stary, ale bardzo sensowny watek. Mam pare pytan.

1) A skad wiesz, ze testy pokrywaja wymagania w dostatecznym stopniu? Ok, masz np. takie instrumenty jak class partitioning. A skad wiesz, ze wziales pod uwage wszystkie zmienne?

2) A skad wiesz ze specyfika pokrywa wszystkie wymagania? W jaki sposob to sprawdzasz?

3) Czy test review procedure rozwiazuje te dwa pierwsze problemy? W jaki sposob? Moge jakis link?

4) Raport z saymi metrykami wydaja mi sie suchy. Co z tego, ze np. przetestowales 90% wymagan funkcjonalnych, jesli np. test typu invalid input przeprowadziles tylko dla 40% funckjonalnosci, i to tych mniej waznych? Tego mi metryka nie powie. W jaki sposob raportowac takie detale?
Link do wypowiedziLink
Piotr Tomasz Piotrowski

Piotr Tomasz Piotrowski Inżynier Testów,
Analityk Danych,
Menedżer, Działacz
społ...

Temat: czy mierzycie w jakis sposob jakosc testow?

Jeżeli klient testuje po nas to samo, to można podpatrzyć w bazie zgłoszonych błedów, czy nieprzeoczyliśmy czegoś, a znalazł to klient.
Link do wypowiedziLink

konto usunięte

Temat: czy mierzycie w jakis sposob jakosc testow?

Piotr Tomasz Piotrowski:
Jeżeli klient testuje po nas to samo, to można podpatrzyć w bazie zgłoszonych błedów, czy nieprzeoczyliśmy czegoś, a znalazł to klient.

No ale to mustardza po obiedzie, tzn. feednack przydatny na przyszlosc do ulepszenia procesu, tak mi sie wydaje.

A ty Piotr jak planujesz testy i masz niekompletna specyfikacje, to jak sie upewniasz ze masz wszystkie testy?
Link do wypowiedziLink
Piotr D.

Piotr D. Tester
Oprogramowania

Temat: czy mierzycie w jakis sposob jakosc testow?

Przed dalszą dyskusją może wyciągnijmy nielubianego wampira z szafy, bo to mimo wszystko ważna rzecz: czy mówimy o jakości PROJEKTU testów czy WYKONANIA testów (realizacji tego projektu)... bo to jakby dwie różne rzeczy...niby końcowo dają podobne objawy, ale mimo wszystko.
Łukasz K.:
...a czasem mozna wpasc w gowno po sama szyje, projekt 20 letni, dokumentacja zniknela w mrokach dziejow i co tutaj zrobic? ;/

http://www.youtube.com/watch?v=BQnF5aRNQF4Piotr D. edytował(a) ten post dnia 25.03.12 o godzinie 22:38
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj