Wyobraź sobie. Idziesz na rozmowę rekrutacyjną lub w obecnych czasach łączysz się z rekruterem przy pomocy Zoom czy Skype :). Przeczytałeś znalezioną w internetach listę pytań, jakie zadawane są na rozmowie rekrutacyjnej. Więc luz. Wiesz wszystko, jesteś przygotowany. Pada pytanie, swoją drogą znane Tobie „Jak przetestowałby pan formularz logowania?”. Odpowiadasz zatem tak, jak większość testerów, którzy zaczynają przygodę z testowaniem.
- Logowanie się przy pomocy poprawnych danych.
- Logowanie się z użyciem nieprawidłowych danych.
- I może niewpisanie niczego?
To są odpowiedzi, które padają najczęściej na to pytanie w trakcie rozmowy rekrutacyjnej.
Dzisiejszy wpis jest pierwszym z cyklu „Pytania na rekrutacji”. Czyli o tym, jak to jest na rekrutacji? Jakie pytania na niej padają? Jak na nie odpowiadać?
Chcę rozpocząć ten cykl od fajnego wpisu rozkładającego na części pierwsze pytanie „Jak przetestować formularz logowania?”. Pytanie to jest dosyć popularne na rozmowach kwalifikacyjnych. Jednym z powodów jest to, że dodatkowo pozwala nam na zobaczenie czy ktoś jest świeżutki jak groszek Grześ ;).
Problemy z odpowiedzią na pytanie „Jak przetestować formularz logowania?”
Dlaczego pytanie dotyczące dwóch pól oraz jednego linku może sprawiać takie wielkie problemy?
Po pierwsze dlatego, że jako nowi adepci sztuk nie aż tak tajemnych patrzymy na aplikację z perspektywy TU I TERAZ. Daje nam to bardzo złudne wrażenie dogłębnego sprawdzenia tematu, mimo że tak naprawdę delikatnie go ruszamy.
Powyżej przytoczyłem najczęściej padające na nie odpowiedzi od wielu kandydatów.
Odpowiedzi te wykazują, że nasz kandydat jak już jadł chleb to raczej z jednego pieca pieczony. Czy należy taką odpowiedź wyśmiewać? Oczywiście, że NIE! Perspektywa ma tu duże znaczenie i jeżeli nie robiliśmy chociaż jednego praktycznego projektu z jakimś mechanizmem administracji (role admin, user), to zwyczajnie może być nam ciężko odpowiedzieć na to pytanie.
Ok w takim razie jak podejść do tego pytania prawidłowo?
Po pierwsze zapytaj o specyfikację! Przy czym podejdź do tego z zimną głową, bo raczej jej nie dostaniesz. Taki urok rekrutacji ;).
Teraz możesz zadać pytanie, po co prosić o specyfikację, jeśli wiadomo, że jej się nie dostanie? Odpowiedź jest prosta, pytaniem dajesz informację rekruterowi, że wiesz, iż jest ona potrzebna, by określić złożoność testów.
Jeśli nie dostaniesz specyfikacji.
Zanim zaczniesz odpowiadać, zadaj pytania. Zapytaj, czy aplikacja ma różne role użytkowników i czy jeśli tak, to czy logowanie następuje do konkretnego widoku aplikacji? Warto dopytać również o to, czy niepoprawne logowanie X razy powoduje blokadę konta? Jeśli tak, to na, jak długo, w jaki sposób odblokować konto, a może ono samo się odblokuje po 24 godzinach? Czy aplikacja przechowuje niepoprawne próby logowania i sumuje je? I tak można dalej drążyć. Wszystko po to, by możliwie najlepiej zbudować sobie listę przypadków testowych, jakie podasz rekruterowi w odpowiedzi na zadane pytanie o to, jak przetestować formularz logowania.
Dobra to jak już masz za sobą pierwszy krok, to co dalej?
Spójrz dalej, poza to, co widzisz tu i teraz. Zastanów się nad potencjalnymi powiązaniami. Konsekwencjami użycia aplikacji w ten, a nie inny sposób. Przede wszystkim pomyśl, czy nie musisz przygotować się do testów na przykład poprzez postawienie środowiska :). Tak na rozmowie nie zostaniesz poproszony o przygotowanie środowiska testowego. Możesz jednak o tym wspomnieć, znowu pokazując w ten sposób, że wiesz, że może to być konieczne.
Ostatnio podczas korepetycji tłumaczyłem ten konkretny przykład. Osoba, z którą rozmawiałem, była zaskoczona tym, że tak naprawdę to tester, czyli TY będziesz sobie przygotowywał/przygotowywała środowisko do stanu, w którym przetestujesz program.
Jak przetestować formularz logowania? Przykładowe przypadki testowe.
- Pozytywna ścieżka (mamy konto, login hasło – ma się udać).
- Logowanie za pomocą social media (o ile jest taka opcja, np. do banku się nie zalogujesz za pomocą konta na FB).
- Próba logowania do konta, które zostało zablokowane (możemy to wywołać często poprzez błędne logowanie x razy do aplikacji).
- Odnośnie do blokowania konta to właśnie weryfikacja czy ono nam się zablokuje (w tym miejscu możesz dopytać, po ilu próbach ma się logować, jak je odblokować – po jakim czasie, wówczas ten przypadek też będzie do przetestowania).
- Czy aplikacja ma reCAPTCHA (skoro nie mamy specyfikacji, to warto sprawdzić, czy jesteśmy zabezpieczeni pod względem ataku brute-force)?
- Jeżeli jest reCAPTCHA to czy możemy się zalogować z uzupełnieniem obrazka + dobrym hasłem.
- Sprawdzenie, czy działa link „Nie pamiętam hasła” wraz ze zmianą hasła, a następnie logowaniem.
- Logowanie z użyciem Upper i Lower case.
- Próba logowania na konto usunięte z aplikacji.
- Jeżeli mamy rozróżnienie kont w aplikacji na różne role, które jeszcze przekierowują na inne widoki, to również można sprawdzić, czy następuje przekierowanie na właściwą stronę.
To kilka przykładów, jakie Ci daję, jeżeli chodzi o tak prosty element, jak przetestowanie formularza logowania. Głównym celem tego wpisu jest uświadomienie, że nie możesz patrzeć powierzchownie na temat i go olewać, bo wydaje się trywialny. Musisz podejść do niego z odpowiednim szacunkiem i rozpracować go lepiej.
Żeby nie było – nie spędziłem bardzo dużo czasu nad tymi przypadkami testowymi. Wpis powstał pod wpływem chwili i przebytych konsultacji, dosłownie w kilkanaście minut.
Dlatego też moja lista przypadków do testów formularza logowania może nie być idealna. Myślę, że jak chwilę zastanowisz się, to sam wymyślisz kolejne przypadki, jak można przetestować formularz logowania. Jeśli jest tak, jak napisałem, dodaj je w formie komentarza. Pomoże to innym, którzy będą czytać po Tobie ten wpis :). Z mojej strony obiecuję feedback w postaci komentarza do Twojego komentarza :).
Na sam koniec ogłoszenia parafialne! W moim sklepie znaleźć możecie e-booka, w którym opisałem odpowiedzi na ponad 100 pytań rekrutacyjnych na testera oprogramowania. Jeśli jesteś na etapie wysyłania CV, szukania pracy i chcesz przygotować się lepiej do rozmowy, zachęcam do zapoznania się z ofertą :).
przerost tresci nad rozumem. formularz logowania a procesy (np. przypominanie hasla, czy samo logowanie) to zupelnie co innego.
logowanie odpowioada za weryfikacje uzytkownika, a autoryzacja to to, jakie masz uprawnienia w systemie po zalogowaniu.
to sa zupelnie rozne tematy.
Moim zdaniem to nie jest przerost treści nad rozumem – to są tematy na styku, o których lepiej pomyśleć na pewnym etapie niż nie pomyśleć. Tak równie dobrze moglibyśmy pomyśleć o nich w osobnym kontekście (Ale to z kolei moim zdaniem byłby przerost formy nad treścią)
Czy mamy czarną czy białą skrzynkę?
Jaki ma byc zakres scenariuszy i pokrycie? Scenariusze pozytywne, negatywne, wszystko? Ile przygotowac scenariuszy?
Jaki mamy model autoryzacji:
– bezposrednie logowanie do AUT;
– pojedyncza autoryzacja;
– jakis two factor authentication, z przekierowywaniem;
Czy apka korzysta z standardowych modeli autoryzacji, typu Oauth, OpenId, fedauth?
Czy jest jakis load balancing i mogą pojawić się różnice w aplikacji?
Czy robimy corner casy, typu wyłączony prąd w trakcie autoryzacji logowania?
Standardowo zapropowałbym 3 podstawowe scenariusze:
– pozytywny z poprawnym logowaniem;
– negatywny z błędnym hasłem;
– negatywny z błędnym loginem;
Dzięki za super komentarz! Bardzo fajne spojrzenie na sprawę i nie aż tak często spotykane 🙂
czym się różnią poniższe?
– bezposrednie logowanie do AUT;
– pojedyncza autoryzacja (autentykacja?)
chyba jedną z lepszych odpowiedzi odnośnie autentykacji jest ten artykuł: https://itfocus.pl/dzial-it/sieci/sso-single-sing-on-i-synchronizacja-hasel/
Przydałoby się jeszcze poruszyć temat testowania formularza w różnych środowiskach (system, przeglądarka)
Słuszne spostrzeżenie – w głównej mierze nie poruszałem tematu środowisk, ponieważ bardzo często na rozmowach pojawia się osobne dedykowane temu pytanie.
Natomiast jest to dobry test, który też może się przerodzić w duże „to zależy”
Bardzo pouczający i pomocny artykuł. Nie wiem dlaczego zniknął mój wcześniejszy post ale chciałem zapytać czy testowanie formularza za pomocą sql injection też należy do zadań testera? Czy to wogóle ma zastosowanie w sytuacji testowania formularza logowania?
Cieszę się, że artykuł się spodobał 🙂
Tak naprawdę różne rodzaje testów należą do zadań testera w tym również SQL Injection.
Przy czym moment wykonania oraz kto za nie będzie odpowiadał to już zupełnie inna bajka. Przykładowo możemy mieć wiedzę jak dany test wykonać ale jednocześnie nie mieć czasu na jego wykonanie, bo np nie dostaniemy budżetu na wykonanie takowych testów.
Jednym słowem owszem to tester może sprawdzić. Czy to sprawdzi zależy od budżetu i podejścia firmy. (6 zasada testowania „testowanie jest zależne od kontekstu”) + np tego typu testy firma może wrzucać na barki audytu zewnętrznego.
Czy testowanie logowania przez polecenia SQL Injection też miały by tutaj zastosowanie?
Super temat. Zaczynam naukę i brakuje mi takiego spojrzenia i podpowiedzi gdzie i jak szukać błędów. Po przeczytaniu wskazówek wszystko zaczyna się układać w głowie 🙂
Dziękuję!
Nie ma sprawy! Cieszę się, że blog spełnia swoją funkcję – czyli pomaga 🙂