Podziel się tym wpisem!

Znalazłeś błąd w piątek na koniec pracy_Co robisz?
Znalazłeś błąd w piątek na koniec pracy. Co robisz?

„Znalazłeś błąd w piątek w momencie, gdy już nikogo nie ma w biurze. Co robisz?”

Nie jest, to może najpopularniejsze pytanie na rozmowie rekrutacyjnej. Mimo tego chcę je opisać, ponieważ jest bardzo złożone, odpowiedzi na nie zawierają wiele „to zależy”. Podobnie jak z pytaniem o przetestowanie formularza logowania, zaczynamy nie od odpowiedzi, a od pytań 🙂

Na którym środowisku znaleziono błąd?

Zatem zapytany „Co zrobisz?” możesz powiedzieć, po pierwsze to zależy od miejsca znalezienia błędu.

Jeżeli jest to nasze środowisko rozwojowe, na którym prowadzimy testy, to możemy wyluzować nawet przy apokalipsie. Błędy na tym środowisku mogą spokojnie poczekać do poniedziałku.

Gorzej, jeżeli błąd wyłapiemy na środowisku produkcyjnym, w takim wypadku pojawia się kolejne, to zależy :). Kto znalazł błąd?

  • Sami go znaleźliśmy.
  • Klient go znalazł

W przypadku, gdy sami znaleźliśmy błąd, to koniecznie musimy zidentyfikować prawidłowo priorytet zgłoszenia. Jeżeli jest poważny, a nawet bardzo poważny, to zdecydowanie trzeba dzwonić do Scurm mastera/PMa, z prośbą o wskazanie programisty, który ma dyżur w dany weekend. Oczywiście opisujemy problem, jaki wystąpił i dlaczego uważamy, że trzeba go poprawić natychmiast.

Jeżeli błąd znaleźliśmy sami i priorytet jest niski, to możemy się wstrzymać z rozpoczęciem standardowych procedur opisanych wyżej. Jako że błąd dotyczy produkcji, lepiej poinformować o nim naszego przełożonego (PM/Scrum master). Wystarczy napisać, że na środowisku produkcyjnym bug o priorytecie takim i, takim i Twoim zdaniem można się nim zająć na spokojnie w poniedziałek.

Jak wygląda poprawa błędu znalezionego na produkcji?

I tu znowu nam się temat rozdziela na dwa:

  • priorytet wysoki,
  • priorytet niski.

Przy priorytecie wysokim programista poprawia defekt, my czekamy na zrobienie retestu no i co dalej? Oczywiście w trakcie poprawiania błędu powinniśmy ustalać razem z klientem możliwość instalacji poprawki na środowisku produkcyjnym, następnie zretestować i zamknąć zgłoszenie. Jednocześnie wyczerpujemy w ten sposób nasz scenariusz.

Przy priorytecie niskim. Musimy poinformować o nim naszego przełożonego, a następnie ustalić harmonogram wdrożenia poprawki na środowisko produkcyjne. W przypadku niskich priorytetów zdarza się, że takie poprawki wchodzą wraz z jakimiś większymi zmianami.

Ok wróćmy teraz do sytuacji, w której to klient znalazł błąd.

Klient znalazł defekt, co teraz? Przeważnie w umowie mamy zapisy dotyczące suportu. Oprócz tego, że robimy fajny soft, fajnie by było, żeby on również działał dłuższą chwilę. Przeważnie w umowie znajduje się tabela z czasami przypisanymi do priorytetów naszych zgłoszeń. Jednym słowem wiemy, jak szybko musimy się podjąć zgłoszenia i jak szybko mamy je dostarczyć klientowi.

Znalazłeś błąd w piątek w momencie, gdy już nikogo nie ma w biurze. Co robisz?

Podsumowując, najpierw zapytałbym o to, na jakim środowisku znaleziono błąd. Następnie sprecyzowałbym priorytet defektu. Na podstawie tych dwóch danych oraz tego kto błąd znalazł, określiłbym, co trzeba w danym momencie zrobić.

Jest takie przysłowie „W piątek zły początek”, zatem dobrym zwyczajem jest na koniec dnia w piątek nie grzebać na wersji produkcyjnej :).

Znalazłeś błąd na tej stronie? Zgłoś mi go.
Formularz zgłoszenia błędu

Jeśli znalazłeś błąd w tekście lub na stronie to proszę, zgłoś mi go. Większość pól tego formularza nie jest wymagana. Jeśli chcesz zgłosić błąd tak, jak powinno się to zrobić, wypełnij je wszystkie.

W formularzu brakuje pola „dodaj załącznik”, ponieważ użycie tej formatki jest płatne. Jeśli jednak chcesz wysłać mi załącznik, prześlij go na e-mail waldemar.szafraniec.szkolenia@gmail.com, w tytule wiadomości napisz, że jest to załącznik do zgłoszenia błędu.

Podany e-mail będzie wykorzystany tylko w celu obsługi tego zgłoszenia - zostaniesz poinformowany, gdy błąd zostanie poprawiony. Podanie e-mail nie jest równoznaczne z zapisem na newsletter.
Tytuł powinien w sposób jasny i czytelny mówić co nie działa na stronie.
Ile prób odtworzenia błędu udaje się odtworzyć.
Dane opisowe błędu. Mogą to być informacje szczegółowe na temat tego, jaki komunikat się wyświetlił. Albo dodatkowe informacje początkowe, jakie muszą zaistnieć.

Podziel się tym wpisem!

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Ten post ma 2 komentarzy

  1. Klakier

    Kolejny ciekawy artykuł pod kątem rekrutacji. Odnosząc się do podsumowania chodzi o to by nikt z zespołu nie grzebał w srod. produkcyjnym czy tylko ja jako tester? No bo jak jest błąd, to jest, niezależnie od tego czy go sprawdzę czy nie.

    1. Waldemar Szafraniec

      Dziękuję Ci za dużą aktywność 🙂
      Odnośnie podsumowania to tyczy się całego zespołu.
      Począwszy od kierownictwa, które nie powinno planować wdrożeń w ostatni dzień tygodnia.
      Przez programistów, którzy mogą wdrażać jakieś zmiany.
      Po testerów, którym akurat może przyjść do głowy żeby sobie coś przetestować.

Dodaj komentarz