[AnonimoweMirkoWyznania]

#anonimowemirkowyznania
wiecie jak wyglada #testowanieoprogramowania u mnie w firmie? Dajmy taki przykład: jest sobie ticket na zrobienie pola do np. do wpisania ilości zamawianych sztuk (przykład z dupy, ale chodzi o to przebieg pracy). Ficzer wypuszczony - jest formularz, jest dodane pole. Testujemy i okazuje się, że możemy zamówić 1 sztukę, ale możemy zamówić 2,2372183671829736 sztuk, -2137 sztuk, aisuhiash sztuk lub ' ' sztuk. Piszemy do developerów - halo, halo, ale przecież user input powinien być od razu walidowany, bo co z tego skoro w pozytywnej ścieżce porządny klient wpisze właściwą liczbę sztuk, skoro można wpisać tam cokolwiek, nawet coś co nie ma sensu, a formularz to łyknie i zostanie to przesłane do realizacji? Co ma być potem robione z takim zamówieniem, dajecie innym teamom dodatkową pracę z wyjasnianiem o co chodzi z tym zamówieniem. A co z np. SQL injection? Też nie jest zabezpieczone? I tak dalej. A co na to developerzy? "No, masz rację ale to już jest inny ficzer, którego nie obejmuje ten ticket. Ticket miał tylko stworzyć pole do wpisania ilości sztuk".

Jak jest u was? Mnie to niesamowicie denerwuje i co gorsza mój szef nie wspiera mnie w tym, że takie pisanie jest bez sensu. Tak to możemy się kręcić w koło jednej prostej funkcjonalności przez wiele miesięcy. To jest to sławne dbanie o jakość? Teraz zakładam nowy ticket na walidowanie pól w formularzu, ale słyszę że to dostanie od razu niski priorytet i w najlepszym wypadku zostanie zaimplementowane za parę miesięcy. Nieprawdopodobne.
Jak to u was wygląda? Ogólnie jestem traktowany przez devów jak gówno, często ignorowany, na maile często nie odpowiadają, wiele rzeczy trzeba eskalować. Firma: gigantyczne korpo.

taguję również #programowanie, wybaczcie

Kliknij tutaj, aby odpowiedzieć w tym wątku anonimowo
Kliknij tutaj, aby wysłać OPowi anonimową wiadomość prywatną
Post dodany za pomocą skryptu AnonimoweMirkoWyznania ( https://mirkowyznania.eu ) Zaakceptował: sokytsinolop
Dodatek wspierany przez: Wyjazdy dla maturzystów

[AnonimoweMirkoWyznania]

Zaplusuj ten komentarz, aby otrzymywać powiadomienia o odpowiedziach w tym wątku. Kliknij tutaj, jeśli chcesz skopiować listę obserwujących

[laki1]

Firma: gigantyczne korpo.

@AnonimoweMirkoWyznania: no i masz rozwiazanie problemu, w korpo no one cares.
W każdej firmie w jakiej obecnie pracowalem to taki task by nie wszedl na produkcje

[animuss]

@AnonimoweMirkoWyznania: tam gdzie kiedyś robiłem to poprawna specyfikacja to był obowiązek architekta oprogramowania. To on pisał co klepacz ma zrobić i jakby puszczał takie babole to miałby problemy :) nie wiem co to jest 'dev' u was, ale programista ma zrobić to co ma napisane na specyfikacji i nic mniej, nic więcej (więc poniekąd mogliby mieć rację). Z testów taka rzecz wróciłaby do architekta, który stworzyłby dodatek do poprzedniej instrukcji, poprawiający

[tell_me_more]

@AnonimoweMirkoWyznania:

Programiści dali dupy, ale swoją drogą to powinno być opisane w tasku. Tzn. SQL injection niekoniecznie(bo to ich zasrany obowiązek, żeby do tego nie dopuszczać), ale już co ma się konkretnie dziać, jak ktoś wpisze 232131231231 i od jakiej granicy to ma się dziać - to już owszem. Skąd koder ma wiedzieć, że w tej firmie 1000 sztuk jest OK a 10 000 już nie?

U mnie szef wprowadził regułę

[digupherbones]

@AnonimoweMirkoWyznania: Jak była w AC wpisana walidacja, to się robi. Jak nie było - to można dopytać PO, chyba, że efforty pozaniżane, to się robi tylko to co w AC, a jak później wychodzi, że miało być więcej to osobne taski na to prosimy. Doświadczenie i PM mnie nauczyli, że robić tylko tyle ile napisane w AC. Jak robilem więcej, bo coś wynikało moim zdaniem samo z siebie i wydawało się

[Theia]

@AnonimoweMirkoWyznania: odpowiedź brzmi: korpo. nie znajdziesz tam jednej osoby, którą to obejdzie, ważniejsze są procedury. programiści zrobią apkę tak, jak mówi biznes. to, że biznes powiedział tylko o stworzeniu pola i nie wyspecyfikował, czego dokładnie chce, nie jest winą devów ani ich sprawą.
praca w korpo przy takim podejściu obu stron jest najgorsza, współczuję ;/

[venomik]

@AnonimoweMirkoWyznania:

U Was nawala kilka rzeczy. Wytłuszczę Ci je. Ale trzymaj głowę wysoko - masz okazję nabrać doświadczenia już nie jako 'tylko tester', ale jako 'QA' i ogarnąć proces tak, aby ten doprowadzał do wytwarzania lepszego oprogramowania.

1. Coś jest nie tak z wiedzą i podejsciem programistów. W dobie frameworków to nie jest tak, że taka walidacja to dodatkowa praca dla programisty. Przykładowo w django w modelu programista musiałby napisać:
models.PositiveIntegerFields

[m.....a]

@Theia: Trochę jest. Bo zrobił na odpierdziel, coś czego robić defacto nie powinien.
Brak dobrej specyfikacji zadania, programista nie robi. A jak robi, bo ma to na papierze od zlecającego i ma to w dupie, to zawsze ktoś może podpierdzielić zlecającego.

[ddziaduch]

@AnonimoweMirkoWyznania: u nas w firmie najpierw wspólnie siadamy i rozmawiamy o nowych pomysłach. Wszyscy, PO, testerzy i deweloperzy. Wtedy unikamy takich kwiatków bo całość jest ustalone zanim zacznę pracować

[diarrhoea]

@ddziaduch
Ale pewnie nie omawiacie tego, czy w polu "rok urodzenia" będzie się dało wpisać cokolwiek ;) a tutaj tak problem wygląda

@AnonimoweMirkoWyznania
Jak u nas taki bubel powstanie (co może się zdarzyć i w korpo i nie w korpo) to dajemy elegancko w jirze taska na to, że ma być to usunięte. I tyle ;) jak są wątpliwości, to się o tym gada.

[e.....a]

Teraz zakładam nowy ticket na walidowanie pól w formularzu, ale słyszę że to dostanie od razu niski priorytet

@AnonimoweMirkoWyznania: a nie możesz założyć ticketa że podatność na taki i taki atak?

[M.....1]

@AnonimoweMirkoWyznania: ja bym to zgłosił jako bug i na każdym stand-upie przypominał o tym. A jakby była decyzja czy GO czy NO-GO, to mówiłbym, że nie, bo z takim babolem wstyd wychodzić na świat.

U mnie działa, aczkolwiek u mnie jest to trochę mniejsze korpo i mniejsze zespoły i QA rzeczywiście ma prawo głosu i jest traktowane porządnie ( ͡° ͜ʖ ͡°)

[supersucker]

@AnonimoweMirkoWyznania: w mojej poprzedniej firmie (wielkie korpo) tego typu rzeczy by nie przeszły, bo nawet jak dev odrzucał ze względu na brak wymagań (typowe podejście robienia tylko tego co jest w dokumentacji, nie mniej, nie więcej) to szedłem dalej (PM, PO czy biznes) i szybko mieliśmy zgłoszonego CRa do zrobienia na już.
W obecnej jak widzę takie bzdury to siadam z devem, wyjaśniam kontekst biznesowy i raczej poprawiamy od ręki. Dodajemy