[Merceress]

#testowanieoprogramowania ale też #programowanie

Dobra, rozprawmy się z tym tematem raz na zawsze: czy tester manualny POWINIEN do zgłoszenia dołączać logi (systemowe, nie przeglądarkowe), do których w równym stopniu ma dostęp także dev i może je sobie sam odnaleźć (po choćby odpowiednich namiarach godzinowych ze zgłoszenia).

Proszę o uzasadnienie zarówno jeśli się zgadzasz jak i gdy się nie zgadzasz z powyższym.

[groman43]

@psposki: Obecnie w niczym, bo zdecydowałem się wrócić na studia. Ale przez ostatnie 7 lat zajmowałem się bezprzewodowym telco (embedded).

[diarrhoea]

@Merceress:

pomiędzy zgłaszaniem błędu, a proponowaniem już jego rozwiązania

1. Załączenie logu, nie jest propozycją rozwiązania. Jeżeli np. na ekranie coś się wyświetla źle, to nie zajrzysz do bazy, czy w niej jest dobrze zapisane? W końcu dev też może sobie do bazy zajrzeć.
Czemu tak usilnie sugerujesz, że zaglądanie do logów = naprawa czegoś. Sprawdzasz co się sypie i zgłaszanie błędów tylko UI'owych to rzecz którą może robić junior na

[Merceress]

przez ponad 10 lat kariery straciłem wiele czasu / nerwów / włosów na głowie przez takie sytuacje.

@groman43: no widać. Może więc u Ciebie czas na zastanowienie się nad swoją rolą i miejscem w tym zawodowym wszechświecie, skoro aż tyle Cię to kosztuje? ;)

[psposki]

@groman43: Myślę, że to wiele wyjaśnia w twoim podejściu i może być inne od programisty ios/android :)

[Merceress]

@diarrhoea: Ok, dzięki za Twoje argumenty i perspektywę/rozgraniczenia. Moje pytania są prowokacyjne celowo. Chcę "zdenerwować" bo widzę, że to skłania do pogrzebania głębiej i uzasadnienia. Właśnie w tych uzasadnieniach widzę najwięcej wartości.

[groman43]

@Merceress: Wolę jednak zostać przy swoim podejściu i nadal wymagać od moich kolegów z pracy podstawowych kwalifikacji do wykonywania zawodu.
Muszę również zwrócić uwagę, że Twój komentarz ostatni komentarz nie jest super merytoryczny.

@psposki: Tak jak napisałem wcześniej - tester ułatwie życie developerowi, developer testerowi. Bardzo dużo rzeczy "zależy" w programowaniu, ale akurat nie to. Ważne również, żeby spróbować poznać perspektywę "drugiej strony". Mam wrażenie, @Mercerress za bardzo skupia się

[Merceress]

@groman43: Jak developer ułatwia życie testerowi? Co masz na myśli?

[supersucker]

@Merceress: @groman43: w sumie rozumiem punkt widzenia każdego z was. Odpowiedzi oczywiście jednoznacznej udzielić się nie da. Jeśli by sięgnąć to istqb to ono raczej wskazuje ze trzeba w zgłoszeniu podać jak najdokładniejsza ścieżkę dojścia do problemu od strony biznesowej czyli UI aplikacji. Drugi argument jest taki, ze grzebanie w logach potrafi być bardzo uciążliwe i jeśli tester ich szukać nie potrafi to może narobić programiście tylko dodatkowej roboty. I

[Adriano]

Zastanawiam się czy to nie jest jednak trochę nadmierne ułatwianie roboty DEVowi, który ma taki sam, równy dostęp do logów, sam może do nich w równym stopniu zajrzeć.

@Merceress:

dev równie dobrze mógłby sobie sam tego buga poszukać na podstawie zgłoszenia od klienta, czy lakonicznego opisu tak prawdę mówiąc ;)
Jenak jeśli istnieje tester, to jego zadaniem jest dokładne zebranie informacji o bugu, w tym logów i innych danych jeśli tylko

[sgt_colbert]

@Merceress: moim zdaniem jak tester nie potrafi pracować z logami (zwłaszcza manualny) albo nie ma na to czasu to nie musi. Zastanowiłbym się bardziej nad poprawą stacku - w projektach często spotkałem się z tym, że np Sentry automatycznie raportuje błędy z potrzebnymi informacjami (jak np podczas testowania wywali się aplikacja), a logi są agregowane w ELK i w takiej kibanie wyszukanie logu mając timestamp lub treść błędu to chwila

[venomik]

@Merceress: @groman43:

Uroczo się czyta Waszą dyskusję :D
Jedna osoba z załączania logów próbuje zrobić 'proponowanie rozwiązania', druga natomiast komentuje:

'Postaw się proszę w roli deva który dostaje ticketa pod tytułem "nie działa", bez dokładnych logów. Nie wiem jak inni developerzy, ale ja uważam zgadywanie co tester miał na myśli tylko za stratę czasu.'

Załączanie logów to NIE jest proponowanie rozwiązania (przy czym zgadzam się z @diarrhoea i nie rozumiem

[groman43]

@Merceress: Tak jak @diarrhoea napisał wcześniej - dostarczając jak najbardziej dokładną informację o błędzie. I teraz wchodzimy na grząski grunt jak napisał @venomik. Jeśli rozjeżdża się jakiś widok na frontendzie, to raczej dump z bazy danych jest niepotrzebny. W takiej sytuacji pewnie lepszy będzie screenshot. Ale jeśli już masz crasha i wiesz że aplikacja korzysta z bazy danych, to dump się przyda. Bo ja, jako developer, nie mam gwarancji, że

[HARDrychuCORE]

@venomik Ostatni akapit twojej wypowiedzi sugeruje, że jeżeli 90% bugów zgłoszonych w przeciągu ostatnich kilku lat nie wymagało logów do ich rozwiązania to nie warto ich dołączać.
Takie podejście sprawia, że czas jaki będzie musieli poświęcić na reprodukcje, analizę i naprawę tych 10% będzie pewnie znacznie większy niż czas który by zajelo dodanie logów do każdego zgłoszenia.
Chodzi mi o uniwersalną zasadę, nie konkretnie waszą sytuację

[venomik]

@HARDrychuCORE:
Moj ostatni akapit potwierdza to, co pisałem wcześniej: są technologie i projekty, w których logi systemowe bardzo rzadko będą potrzebne i dobry tester powinien potrafić wyłapywać większość takich okoliczności.
Ba, użyłem stwierdzenia, że powinien odrzucać przynajmniej te oczywiste.
Nigdzie nie napisałem, że nie powinien załączać nigdy. Jeśli nie wie czy mogą być potrzebne - niech pyta programistę albo załącza.

Inna sprawa, że mowa była o moze jednej sytuacji w trzech

[venomik]

Dlatego też najsensowniejszej odpowiedzi udzielił na początku @psposki: "to zależy". Ale stało się to przed nawałem odpowiedzi, że zawsze i wszędzie (poza literówkami), a jeśli ich nie ma to tester jest do dupy i niepowazny, niech już lepiej listonoszem będzie (przesadzam, ale niewiele).

[supersucker]

Jeśli mi się apka rozjezdza przy określonych rozdzielczościach to nie patrzę na logi systemowe.

Jeśli widzę błąd po stronie frontendowego walidatora z django to też nie będę patrzył na logi systemowe.

@venomik a ja myślałem ze ta dyskusja nie wymaga tłumaczenia ze sprawy frontowe nie powinny w niej uczestniczyć.
A to ze twój programista od trzech lat nie zaglądał w logi być może wynika jakoś ze specyfiki jego pracy lub architektury systemu.

[venomik]

A to ze twój programista od trzech lat nie zaglądał w logi być może wynika jakoś ze specyfiki jego pracy lub architektury systemu. W niektórych projektach backendowiec bez wglądu w logi jest zwyczajnie ślepy ;)

@supersucker: No i już mówisz o tym, co ja tutaj próbuję tłumaczyć. Dzięki ;)

[tellet]

@Merceress: Jasny #!$%@?, za brak logów w jakimkolwiek tasku/zgłoszeniu do jakiejś awarii czy innego "niedziałania" powinno się uwalać to zgłoszenie.
Potem ci pisze jakiś głupol "bo szczelaliśmy do semrwera i nie dziamłało"
-Kiedy
"Wczomraj popołudniu".
A serwer deweloperski/testowy załóżmy sra 50G logów dziennie i ty masz sobie najlepiej samemu wyszukać po jakimś nic nieznaczącym i powielonym 60000 razy (bo dane testowe) numerku, konkretny request i jeszcze najlepiej całą ścieżkę...

I tak

[Merceress]

@supersucker: Widzisz, w moim pytaniu chodzi o to, żeby stwierdzić czy jest sens, żeby tester grzebał w logach, przeklejał je do zgłoszenia. Bo może wystarczy, że poda godzinę/minutę/sekundę wystąpienia, a dev SAM zaloguje się i spojrzy w logi. Zakładając oczywiście, że błąd to nie jest timeout, albo inna wywrotka zewnętrznego systemu, tylko ewidentnie błąd w kodowaniu. Bo i jeden i drugi musi zrobić to samo: zalogować się i zacząć tam grzebać.

[Merceress]

@tellet: "nie działało" i "wczoraj popołudniu, pamiętasz, wtedy kiedy pisaliśmy na slacku" to faktycznie raczej nie jest dobry ticket. ;) Ale bądźmy poważni: rozmawiamy o tym kto powinien grzebać w logach i czy czasem nie jest to (teraz to się narażę, wrażliwi niech nie czytają, bo już w ogóle ciśnienie podskoczy) pielęgnowanie wygodnictwa deva? Jeśli w zgłoszeniu jest godzina wywołania, IDki procesów (inne potrzebne) to kurna, są to konkretne namiary. Co