Wpis z mikrobloga

Jaka jest wasza rola w scrumowych meetingach jako zwykli testerzy (nie test lead)? Czy oprócz takich oczywistości jak estymowanie story pointów dla testerów (ale to chyba jako test lead)bierzecie czynny udział w rozmowach na planowaniach, refinementach itd, nie mając wglądu w kod i nie uczestnicząc w jakichś technicznych czy ważniejszych meetingach?

Pytam się, bo w sumie w obecnej robocie na tych meetingach testerzy nie za wiele mają coś do powiedzenia i zastanawiam się czy powodem tego jest ogólna #!$%@? organizacja w firmie i traktowanie testerów jak botów od przeklikiwania apki, a do tego moja wielka lacha wyłożona na stół z różnych powodów, czy zazwyczaj tak jest, że testerzy raczej najwięcej do powiedzenia będą mieli po testach i na retro?

#testowanieoprogramowania #testowanie #qa #pracait
  • 15
@Piks0n: co kraj to obyczaj. Jak stack sie pokrywal z backendem to zawsze mialem glos w sprawach backendowych, a jak z frontendem to trzymalem sie blizej frontendowcow. Byly projekty gdzie tylko mowilem jak tam sytuacja w apce i nic wiecej. A w teamie samych testerow to kazdy mowi po kolei co tam i nie rozni sie takie daily od teamu developerskiego.
To czy masz cos do powiedzenia zalezy od seniority i
@Piks0n: jestem w swoim zespole najdłużej z osób technicznych więc mam większą wiedzę nt rozwiązań czy biznesu to mam często dużo do powiedzenia, mogę zadawać odpowiednie pytania czy to dla backendowcow, frontendowcow czy innych testerów/biznesu. Bywa że prowadzę refinementy czy planowania bo nie potrzebuje do tego SMa, planuje często pracę innym testerom czy wdrożenia które dotykają kilku zespołów które trzeba zaplanować. No ale to głównie kwestia ambicji i chęci robienia czegoś
  • 0
@bb89: No to ja nawet nie mam do czego się odnosić w moim przypadku, bo dostaję już gotowe taski z info co ma być przetestowane od devów, a na meetingach gadają o ficzerach, o których, jako testerzy, oprócz jakiegoś teoretycznego zarysu nie mamy pojęcia, bo dokumentacja praktycznie nie istnieje xD

Ok, czyli jest to ogólnie mocno zależne od firmy. To się rozjaśniło.
@Piks0n: powiem jako nie tester i nie dev, ale taki co też siedzi na refinementach: dobry tester dużo wnosi na refeiment, planowanie bo zna system i jest w stanie wskazac potencjalne fakapy które Devi powinni przewidzieć i ogarnąć.
W poprzednim zakładzie tester nawet wnosił sporo do dyskusji o UI.

gotowe taski z info co ma być przetestowane od devów


@Piks0n: a to już brzmi jak gruba patologia.
@Piks0n: krótki mam staż, bo to dopiero mój drugi projekt (jestem jedynym testerem w obecnym projekcie i jednym z dwóch w poprzendnim), ale:
- <pytanie> oosobna wycena w story pointsach dla testów? Chyba powinno być tak, że taska wycenia cały zespół (programiści + testerzy) jako całość, a nie rozbijając,
- generalnie dużo w zrozumieniu do czego/jak itp będzie wykorzystywana aplikacja pomagają rozmowy z PO/PM (doświadczenie z obu projektów) - jak ktoś
  • 0
@kraggthegrimm:

a to już brzmi jak gruba patologia.

Januszerka totalna, zbieram info żeby ewentualnie coś próbować zmienić(i tak się od ściany odbije), albo przynajmniej zebrać jakikolwiek exp do przyszłej roboty, albo poćwiczyć soft skille

@imo0mfg:

oosobna wycena w story pointsach dla testów? Chyba powinno być tak, że taska wycenia cały zespół (programiści + testerzy) jako całość, a nie rozbijając,


W poprzedniej firmie ("Poważne" korpo) story było wyceniane osobno przez devów
  • 0
- ja na refinementach przeważnie zabieram często głos: a to dopytam programistów jak planują daną funkcjonalność zaimplementwać


@imo0mfg: Ale to od strony technicznej, pisanego kodu? Chodzi mi, czy znasz język, w którym piszą i możesz się odnieść do tego co oni mówią, czy po prostu chodzi o ogólny zarys działania i integracji z innymi modułami itd?
@Piks0n znam język w którym piszemy front, bo piszę automaty w cypress, dodatkowo z uwagi na to, że piszę testy komponentów umiem też co nieco z frameworka na froncie. No i czasem faktycznie podyskutuję o komponentach itp, ale przeważnie pytam o ogólny zarys działania i integracji
No to ja nawet nie mam do czego się odnosić w moim przypadku, bo dostaję już gotowe taski z info co ma być przetestowane od devów


@Piks0n: to co ty robisz cały dzień w pracy xD
czemu?


@bomba4: bo to są mało wiarygodne testy, jeżeli wykonawca mówi co ma być przetestowane w jego dziele. Testy powinny sprawdzać czy to zostało zrobione spełnia warunki: jest zgodne z wymaganiami funkcjonalnymi, oczekiwana wydajnością, warunkami brzegowymi itd.
Developerzy, nawet nieświadomie mogą zaburzyć takie testy, wskazując te kawałki które są ważne dla nich a niekoniecznie z perspektywy oczekiwań.
Tester powinien działać niezależnie od dewów, oczywiście współpracując z nimi. Ja by nawet oczekiwał
@bomba4: oczywiście dane do tego sami robimy, ale czegoś takiego jak dane brzegowe u nas nie ma. Performance też nie jest sprawdzany, na co klient się godzi. Nasz soft jest na tyle duży, że są robione testy funkcjonalności E2E, a ich całkowity koszt jest ogromny, zbyt duży aby biznes to pokrył, reszta jest robiona unit testami. Sporo też jest sprawdzane poza scenariuszem testowym, przy sprawdzaniu, czy dev zrobił wszystko ok. Czasem