Wpis z mikrobloga

#testowanieoprogramowania #pracait #pracbaza

Spotkaliście się ze szczegółową estymacją czasu na testy? Macie oddaną jakąś funkcjonalność i np. 2h na testy a jak przekroczycie czas, to musicie się tłumaczyć dlaczego albo mieć z tyłu głowy, że ktoś zapyta.

Czy spotkaliście się z estymacjami testów?

  • Tak 33.0% (31)
  • Nie 67.0% (63)

Oddanych głosów: 94

  • 12
@zogard: Hehe jeden z Twoich czterech etatów nagle jest zagrożony bo musisz estymować zadania? Ja estymuje testy razem z estymatą developmentu, bo zamykamy dopiero po testach automatycznych. Jak przekraczam czas na testy to zwyczajnie informuje zespół o tym, żadne to tłumaczenie
@Tang0: Takie warunki, co poradzę. Albo przywyknę, albo nie. Dla mnie to nowość, bo muszę liczyć czas zamiast zająć się zadaniem.
Niby prosta sprawa, ale się komplikuje gdy są blokery. ¯\_(ツ)_/¯
I też miałeś założenie, że testy nie mogą przekroczyć czasu pracy developera?


@zogard: xD
Byłem kiedys w projekcie w którym użytkownicy aplikacji mogli dodawać filmy reklamowe. Ale mieli ograniczenie ile megabajtów filmu mogą dodać w ciągu 6 godzin, później opcja była zablokowana.
Ale pojawiła się kwestia, że dla klienta jest istotne w jakiej kategorii ten film zostal dodany, bo są różne priorytety, czasy reakcji, itp. I na przykład nie chciał aby
@zogard: Tak. W 99% przypadków estymacje byłby przekroczone przez bugi i ciągłe retesty. Np - estymacja na 2h (zakładająca przetestowanie, napisanie tc, przegląd tc). Po godzinie mamy Buga. Przez to, tc nie może być formalnie skończony i dowieziony do review. Retest całości poszedł nieco szybciej, ale pojawił się kolejny babol, kilka kroków dalej. Ostatecznie temat jest dowożony w czasie 5h. Nie wiem w jaki sposób, można estymować testy. Można założyć bezpiecznie