Podziel się tym wpisem!

jak przetestować formularz logowania odpowiedź na pytanie rekrutacyjne
Jak przetestować formularz logowania?

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

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 konsultacji z 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.

Ok, to jak przetestować formularz logowania? Przykładowe przypadki testowe.

  1. Pozytywna ścieżka (mamy konto, login hasło – ma się udać).
  2. Logowanie za pomocą social media (o ile jest taka opcja, np. do banku się nie zalogujesz za pomocą konta na FB).
  3. 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).
  4. 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).
  5. Czy aplikacja ma reCAPTCHA (skoro nie mamy specyfikacji, to warto sprawdzić, czy jesteśmy zabezpieczeni pod względem ataku brute-force)?
  6. Jeżeli jest reCAPTCHA to czy możemy się zalogować z uzupełnieniem obrazka + dobrym hasłem.
  7. Sprawdzenie, czy działa link „Nie pamiętam hasła” wraz ze zmianą hasła, a następnie logowaniem.
  8. Logowanie z użyciem Upper i Lower case.
  9. Próba logowania na konto usunięte z aplikacji.
  10. 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! Pojawienie się tego cyklu nie oznacza, że zawieszam cykl, o którym pisałem na swoim Fanpage (Hall of fame/hall of shame) dalej będę przeplatał hejtowanie bylejakości oraz chwalenie dobrej jakości w aplikacjach, natomiast będę wpisy przeplatał, żeby nie zwariować przy jednym temacie

😉
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 9 komentarzy

  1. Sławek

    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;

    1. Waldemar Szafraniec

      Dzięki za super komentarz! Bardzo fajne spojrzenie na sprawę i nie aż tak często spotykane 🙂

  2. Łukasz

    Przydałoby się jeszcze poruszyć temat testowania formularza w różnych środowiskach (system, przeglądarka)

    1. Waldemar Szafraniec

      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”

  3. Klakier

    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?

    1. Waldemar Szafraniec

      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.

  4. Klakier

    Czy testowanie logowania przez polecenia SQL Injection też miały by tutaj zastosowanie?

  5. Kasia

    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ę!

    1. Waldemar Szafraniec

      Nie ma sprawy! Cieszę się, że blog spełnia swoją funkcję – czyli pomaga 🙂

Dodaj komentarz