Wpis z mikrobloga

Zacząłem zastanawiać się nad sensem przypadków testowych. Piszecie je do wszystkich funkcjonalności produktu?
Czy pisanie przypadków typu 'Wpisz nazwę użytkownika, hasło, a następnie naciśnij przycisk Zaloguj' jest potrzebne? Oczekiwany rezultat takiego przypadku jest raczej oczywisty.

Jak to widzicie i jakie macie podejście w swojej pracy?

#testowanieoprogramowania
  • 11
@ThomasFokinShelby: zależy od złożoności projektu/aplikacji, presji czasu itp.
Czasami sam proces logowania możesz umieścić jako pierwszy krok w innym bardziej złożonym przypadku i dzięki temu potwierdzić jego działanie, a czasami masz oddzielny przypadek dla logowania (dzięki czemu widzisz na raporcie że wszystkie najważniejsze przypadki testowe przeszły dla zbliżającej się dostawy).
via Wykop Mobilny (Android)
  • 2
@ThomasFokinShelby: jak mam juniora do przyuczenia od prawie zera to tak musi pisać przez parę dni, żebyśmy mogli zobaczyć jego sposób myślenia. Z drugiej strony są testerzy którzy przez brak czasu w ogóle tworzą przypadki testowe w notepadzie i to potem ginie, jest adnotacja, że przetestowane, brak bugów i nic więcej.
Ja jestem zwolennikiem, żeby do każdego głos stworzyć przypadek, nie musi byc idealnie opisany ale żeby był ślad ścieżki która
@daloma: mózgu, wymagań i testów automatycznych

@ThomasFokinShelby: 7 lat w branży, napisałem może w sumie z 20-30 przypadków testowych. Uważam, że pisanie takich trywialnych przypadków jest całkowicie bezsensowne. Warto trzymać sobie wysokopoziomowe scenariusze testowe gdzie w podanym przypadku powinno być "Test logowania" i to już od kreatywności testera zależy co odwali z loginem. Przypadki testowe upośledzają ludzi i przede wszystkim są okropnie niebezpieczne - nie korzystasz z nowych skilli testera
@ThomasFokinShelby: Różne są strategie testowe.
Ale już konkretne przypadki do logowania (długość, znaki, wygasłe hasło, jakaś dodatkowa weryfikacja) nie są takie oczywiste. Ogólnie, jestem zdania, że przypadki testowe powinny być dla każdej funkcjonalności, nawet takiej jak logowanie.
@rskk niestety to prawda. Pod uwagę też należy wziąć jaki jest profil firmy, czy jest duży przemiał ludzi. Czasami sam przypadek 'Test login page' i konieczność testowania eksploracyjnego na podstawie doświadczenia i umiejętności testera może polec. Dużo firm wymaga wyszczególnienie scenariuszy, by mieć pewność, że przestestowane są nie tylko "happy path", ale też negatywne scenariusze. Osobiście jestem za tym, żeby chociaż gdzieś wspomnieć o tych przypadkach testowania, czasami potrafi to ratować dupę
@rskk: to tez w dużej mierze zależy od projektu, jak będziesz kiedyś w bardziej złożonym w którym trzeba przetestować coś więcej niż prostą aplikację webową to docenisz przypadki testowe niższego poziomu. Oczywiście nic nie zastąpi mózgu ale nie wiem czemu jedno ma wykluczać drugie ( ͡° ͜ʖ ͡°)
@ThomasFokinShelby sporo osób ostatnio porzuca test case'y na rzecz bardziej wysokopoziomowych test scenarios co uważam za zasadne. W zasadzie wg mnie atomowe test case'y mają sens głównie kiedy pracuje się z zewnętrznym teamem testerów, juniorami albo ma się dobrze ogarniętą automatyzację zintegrowaną z jirą
@ThomasFokinShelby: U mnie robi się przypadki testowe na podstawie ticketu i dokumentacji analitycznej. Tester je sam przygotowuje i analityk wtedy wie, że dobrze zrozumiał logikę biznesowa oraz przyjął dobra taktykę testów. Jakieś trywialne pierdy typu logowania itp. to mam zautomatyzowane i do tego nie pisze dodatkowych przypadków. Jak analitycy już testują to oni przypadków nie rozpisują. Ew. zaznaczają w komentarzach bugi.