Podziel się tym wpisem!

siedem zasad testowania istqb
Siedem zasad testowania.

Siedem zasad testowania stanowi jeden z rozdziałów Sylabusa, podręcznika przygotowującego do egzaminu ISTQB. Znajdziesz w nim definicje, które postaram się wyjaśnić, w mam nadzieję nieco prostszy do zrozumienia sposób.

Testowanie ujawnia usterki, ale nie może dowieść ich braku.

Zasada dosyć jasna, testujemy, więc możemy założyć z dużym prawdopodobieństwem, że znajdujemy defekty w aplikacji. Równocześnie znalezienie błędów nie dowodzi tego, że nie można ich znaleźć więcej w aplikacji. 

Tak więc nawet jeśli znajdziemy w aplikacji 1000 błędów, nie jesteśmy w stanie zapenić, że nie jest możliwe znalezienie 1001. I na odwrót, nawet jeśli nie znaleźliśmy żadnego błędu, to nie możemy zapewnić, że w aplikacji nie ma defektów.

Moim sposobem na zmniejszenie ilości defektów jest (o ile nie spełniliśmy warunków zakończenia testów w naszym projekcie) poproszenie innego testera o przetestowanie tego, co sami testowaliśmy. Będzie on miał inne spojrzenie na funkcjonalności i sposoby ich testów. Robiłem to dzieląc się swoim budżetem na testy z innym testerem.

Testowanie gruntowne jest niemożliwe.

Znaczy to, że nie można przetestować wszystkiego w aplikacji, wyjątkiem są aplikacje bardzo małe.

Przypomina mi się taka sytuacja z czasów jeszcze technikum. Moją przygodę z testowaniem rozpocząłem od praktyk wakacyjnych. Pamiętam, jak we wrześniu wróciłem do technikum i na zajęciach kolega pokazał mi i drugiemu koledze, z którym odbywałem praktyki swoją aplikację stworzoną w ramach praktyk. Pełni zapału zgłosiliśmy się do testowania, pewni, że przecież w każdej aplikacji błąd być musi. ALEEEE no właśnie ta aplikacja to był pseudo Mario na dosłownie 10 sekund grania z założeniem, że ma działać tylko na najnowszym Windowsie. Testowaliśmy ją wtedy ponad godzinę – mam nadzieję, że odczuliście to, co ja wtedy, czyli wkurzenie, że nie daję rady znaleźć błędów, a one muszą tam być!!!

Myślę, że w nierealnym świecie, gdybyśmy mieli odpowiednio dużo czasu na testowanie, moglibyśmy w efekcie przetestować każdą aplikację gruntownie (o ile nie byłyby w niej robione zmiany przez programistów). Tak jak mówiłem nierealny świat, w którym budżet na aplikację jest nieograniczony wręcz.

Wczesne testowanie oszczędza czas i pieniądze.

Celowo pogrubionym tekstem napisana zasada, ponieważ uważam ją za jedną z najważniejszych, a zarazem bardzo często pomijanych. Wczesne testowanie daje ogromne korzyści i bardzo duży komfort pracy. Po pierwsze błędy znalezione na wczesnym etapie dużo łatwiej i taniej poprawić.

Spójrzcie na to tak. Przypuśćmy, że znaleźliście błąd w specyfikacji, zanim dany komponent został zaprogramowany. Poprawa znalezionego błędu ograniczy się do czasu, jaki analityk poświęci na poprawę odpowiednich fragmentów dokumentacji.

Gdyby dana funkcjonalność była zaprogramowana, poprawa jej to czas programisty spędzony na poprawę kodu, czas programisty konsultującego błąd z analitykiem i wreszcie Twój czas spędzony na testach i retestach.

Wczesne testowanie daje duży komfort psychiczny i mniej stresu. W moim odczuciu aplikacje testowane na wcześniejszym etapie mają fajniejszą jakość. Łatwiej jest również zapanować nad zmianami w projekcie oraz ryzykami wcześniej zdefiniowanymi.

Warto tutaj dodać, że często mówimy o wczesnym testowaniu i na mówieniu kończy się ich wykonanie. Zazwyczaj startujemy późno a wręcz czasami ZBYT późno z naszymi testami – może to wynikać z wielu czynników, natomiast warto mimo wszystko optować za opcją jak najwcześniejszego startu.

Kumulowanie się defektów.

Zasada kumulowania błędów mówi o tym, że jeśli jesteśmy świadomi tego, gdzie jest dużo błędów w aplikacji, to mamy możliwość przewidzenia tego, gdzie będą większe ryzyka testowe i jakie moduły będą wymagały większych nakładów na testy.

Ważna według mnie przy tej zasadzie jest pewność tego, że błędy skumulowane nie są duplikatami, dlatego ważne jest w projekcie by błędy zgłaszane były prawidłowo opisywane.
Zasada ta jest bardzo ważna. Pomaga nam przy planowaniu ryzyka w aplikacji oraz oszacowaniu czasu potrzebnego na testy.

Paradoks pestycydów.

Lubię tłumaczyć porównując go do robienia porządku w domu. Nazwijmy go po mojemu „paradoksem porządków”. Wydaje mi się, że nazewnictwo dotyczące sprzątania bardziej trafia do każdego.

Z czego się bierze ta zasada? Paradoks ten dotyczy sytuacji, gdy na aplikacji testujemy zawsze te same scenariusze. Prowadzi to do sytuacji, gdy w czasie testów przestajemy znajdować błędy. Możemy wówczas mylnie uznać, że aplikacja nie ma defektów.

Wracając do mojej nazwy i tłumacząc bardziej obrazowo, przyjmijmy, że na co dzień sprzątamy dom, odkurzamy, zamiatamy itp. itd. Uznajemy, że po wykonaniu tych czynności dom jest posprzątany. W okresie świątecznym sprzątamy dokładniej i wówczas okazuje się, że znajdujemy duże warstwy kurzu za kanapą, na szafach, lampach.

Moim zdaniem w celu uniknięcia tego problemu, możemy:

  • Pisać przypadki wysokopoziomowe i je egzekwować podczas testów.
  • Wplatać przy każdych testach oprócz standardowych testów na podstawie dokumentacji, testy eksploracyjne i może zgadywanie błędów. Ogólnie rzecz biorąc trzeba wprowadzić trochę szaleństwa/chaosu i nieprzewidywalności w nasze testy! 🙂

Testowanie zależne jest od kontekstu.

Kolejna bardzo istotna zasada, która ładnie łączy się, chociażby z zasadą 2. Każda aplikacja ma swoje własne warunki, które określają jak ma ona działać.

Przykładowo na tapetę wziąłbym jakąkolwiek grę, która powstała lub ma powstać. Planując testy bierzemy pod uwagę to co jest ważne dla użytkownika tej aplikacji. Testując rozważamy jak ma ona działać, czy gra nie zacina się na słabszym (zgodnym z wymogami sprzętowymi) sprzęcie. Dodatkowo testujemy tryb multi lub single player, lub nie testujemy muli playera, jeżeli np. tak jak seria Wiedźmin go nie posiadamy.

Przy okazji tej zasady możemy zauważyć, że decydującym czynnikiem podczas planowania testów jest wiedza o produkcie.

Przekonanie o braku błędów jest błędem.

Poprzednie zasady wspominały już o tym, że nie jest możliwe przetestowanie wszystkiego i znalezienie wszystkich błędów. Ta zasada utwierdza nas w tym przekonaniu. Trzeba przyjąć, że aplikacja ma błędy mimo testów. 

Rozumiem tą zasadę bardziej, jeśli nazwę ją po swojemu : 

“Przekonanie, że stworzyliśmy bardzo dobrą aplikację, ponieważ ma ona mało błędów jest błędem”

O tym, że nie jest możliwe zapewnienie bezbłędności aplikacji mówi zasada pierwsza. W tej dochodzi dodatkowo to, że należy pamiętać, że nawet jeśli będziemy pewni, że aplikacja działa zgodnie z wymaganiami opisanymi w dokumentacji, to nadal może ona nie spełnić wymagań użytkownika docelowego. Nie będzie wówczas używana.

Siedem zasad testowania - podsumowanie

Jak widzicie zasady to schematy, którymi jedni się posługują bardziej inni mniej. Ważne, aby zawsze patrzeć na zadania i schematy z pewnym dystansem i spróbować je zrozumieć oraz dostosować do swoich potrzeb. Mam nadzieję równocześnie, że przydało się wam moje spojrzenie na tak oklepany temat!

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.

Dodaj komentarz