Jesteś na rozmowie rekrutacyjnej, wszystko idzie dobrze, czas na kolejne pytanie: Załóżmy, że znalazł pan błąd, opisał i zgłosił. Po jakimś czasie przychodzi do pana programista i mówi, że błąd nie występuje u niego na środowisku. Co Pan zrobi?
Cześć, to kolejny już wpis, w którym opiszę, jak podejść do odpowiedzi na jedno z pytań często pojawiających się na rozmowach rekrutacyjnych. Dzisiaj zajmiemy się pytaniem „Co pan zrobi, gdy programista powie, że u niego błąd nie występuje?”. Temat tego konkretnego pytania podjąłem jakiś czas temu, tym razem spróbuję omówić go w nieco inny sposób.
Zanim zaczniemy, mała dygresja
Mam pomysł by e-booka „Jakość to będzie” nagrać w formie audiobooka. Nie byłoby to jednak czytanie, a bardziej opowiadanie tego, co jest w formie tekstowej. Dlatego niektóre tematy byłyby szerzej niż w książce opisane a niektóre mniej. Powodem tego jest to, że niektóre tematy ciężko się omawia bez obrazka do niego załączonego. Dlatego prośba do Ciebie o komentarz, feedback, w którym możesz napisać, co o moim pomyśle myślisz. Twoje zdanie ma znaczenie :). Przykładowy rozdział możesz pobrać, klikając w link.
Wracając do tematu wpisu
Błąd, którego nie może powtórzyć programista
Warto zacząć od tego, by zbadać możliwą przyczynę tego, że błąd u programisty nie występuje.
Słabo zgłoszony defekt
To jest pierwsza rzecz, jaką bym sprawdził. Umiejętność jasnego opisania kroków testowych i tego, na czym polega błąd, jest bardzo ważna w pracy testera. Czasami przez pośpiech, czasami przez stosowanie skrótów myślowych sprawiamy, że jedyną osobą, która będzie w stanie odtworzyć zgłoszenie, jesteśmy my sami.
Leniwy programista
Drugą opcją jest to, że programiście nie chce się wczytywać i odtwarzać błędu. By ułatwić sobie życie, woła do siebie testera by wyklikał mu błąd. W ciągu kilku lat pracy współpracowałem z trzema programistami, którzy prosili mnie, żebym u nich „wyklikiwał” błąd, który znalazłem. Sam nie czytał kroków reprodukcji.
Jeśli chcesz przeczytać więcej na temat tego, co zrobić jak błąd nie występuje u programisty, odsyłam Cię do wspomnianego wcześniej wpisu.
Różne dane, na jakich aplikacja pracuje
Dane testowe to dane, jakie istnieją w bazie danych i które dodajemy do niej, żeby z aplikacji korzystać. Danymi tymi mogą być przykładowo imię, nazwisko, login i hasło. Za każdym razem, gdy rejestrujesz się w jakimś serwisie i podajesz dane do logowania, powstaje nowy wiersz w bazie danych. Tester i programista, pracując na aplikacji, dodają do swoich baz danych informacje im potrzebne, by z aplikacją pracować.
Dodatkowo warto byś pamiętał, że programista i tester pracują na różnych środowiskach. Znaczy to tyle, że mają inne bazy danych i często inne wersje aplikacji zainstalowane do pracy.
Czemu o tym mówię teraz?
Chcę, byś wyobraził sobie warunki pracy, jakie mają tester i programista. Pomoże Ci to w zrozumieniu, dlaczego z powodu różnicy danych, na których aplikacja pracuje, błąd może występować na Twoim środowisku testowym, a nie na środowisku deweloperskim.
Bardzo często zdarza się, że programista zaczyna pracę na czystej bazie danych. Czystej, to znaczy, że ma przygotowany skrypt, którym do pustej bazy danych dodaje te dane, które umożliwiają korzystanie z aplikacji np. założeni użytkownicy, użytkownicy, którzy nie dostaną kredytu, użytkownicy, którym kredyt zostanie przyznany itp. itd.
Programista czyści swoją bazę danych często.
Skrypty zwykle dodają do pustej bazy danych te same dane. Przykładowo programista zwykle ma dodanych do bazy kilku klientów w różnych wariantach danych (Jan Kowalski ma dostać kredyt a Maria Kowalska już nie).
Tester, natomiast trochę inaczej musi podchodzić do swojej pracy. Tester musi testować wszystkie sytuacje po drodze w aplikacji. Dlatego często zaczynając testy, przechodzi przez kolejne ekrany aplikacji i dodaje dane na każdym z nich. Dzięki temu przy okazji tester sprawdza kolejne ekrany aplikacji, czyli testuje ;).
Różnica w danych i środowiskach na przykładzie testów migracji danych
Taka hipotetyczna sytuacja. Istnieją dwa banki: bank X i bank Y. Bank Y kupił bank X, od teraz wszyscy klienci banku X będą klientami banku Y, co za tym idzie, ich dane muszą zostać przeniesione do banku Y. Główną trudnością tego typu sytuacji jest różnica danych, jakie są pomiędzy tymi dwoma aplikacjami np.
W banku X dane wymagane to:
Imię
Nazwisko
Pesel
Numer telefonu
Adres
W banku Y wymagane dane to:
Imię
Nazwisko
Pesel
Numer telefonu
Adres
Adres korespondencyjny
W takim wypadku podczas łączenia banków trzeba zmapować dane z banku X do banku Y. Dodatkowo jak się pewnie domyślasz, trzeba w jakiś sposób rozwiązać problem wymaganego „Adresu korespondencyjnego”, który dla klientów banku X nie był wymagany. O tym, jak powinny te dane być uzupełnione, decyduje tak zwana „góra”, do testerów należy, by sprawdzić, że dane są prawidłowo mapowane do banku Y.
Zanim dojdzie do fizycznego przeniesienia danych na środowiskach produkcyjnych, testerzy i programiści testują migrację. Różnica polega na tym, że najczęściej programiści zrobią migrację kilka razy, po czym stworzą sobie obraz bazy danych po migracji i na nim będą pracować.
Jako tester przeważnie przygotowujesz sobie środowisko zawierające dane z banku X, a następnie puszczasz skrypty migracyjne i w ten sposób sprawdzasz, czy dane poprawnie się zmieniły. Jako tester możesz wykonać różne testy z różnymi danymi i wykonać je x razy. Tak jak wspomniałem, programista często działa na dumpach bazy danych, co za tym idzie, nie przechodzi w ten naturalny sposób ścieżki. Dlatego błąd może nie występować na jego środowisku z tego powodu.
Co zatem można zrobić, gdy sprawdzono wszystkie możliwe ścieżki i programista nie może powtórzyć błędu?
Możesz zrobić obraz swojej bazy danych aplikacji i udostępnić ją programiście. Jeśli uda mu się błąd powtórzyć na środowisku produkcyjnym, to można powiedzieć, że udało się i błąd może być poprawiony. Jeśli nie uda się powtórzyć błędu, trzeba uznać, że błąd nie występuje i prawdopodobnie został poprawiony przy okazji prac developerskich.
Mam nadzieję, że spodobał Ci się ten wpis i ponownie prośba o komentarz, jeżeli uważasz, że mój pomysł na audiobook ma sens :).
