7 zasad testowania
Bo w życiu trzeba mieć zasady - nawet w trakcie testowania oprogramowania.
Dbająca o szczegóły dziedzina utrzymania jakości oprogramowania musi mieć solidne fundamenty. Nic więc dziwnego, że ITSQB wyróżniło 7 siedem zasad, na których powinna opierać się praca testerów. Uniwersalne porady mogą być pomocne zarówno przy przeprowadzaniu testów manualnych, jak i tworzeniu testów automatycznych. I choć brzmią one mocno teoretycznie, to uwierzcie - w praktyce również się sprawdzają.
Testowanie ujawnia usterki, ale nie może dowieść ich braku
Oczywiste jest, że testowanie pomaga wyłapać niedoskonałości i błędy w oprogramowaniu, ale trzeba mieć na uwadze, że nawet po pełnym (a przynajmniej pełnym w naszym mniemaniu) przetestowaniu aplikacji nie można być pewnym, że wszystko działa bez zarzutu. Brak wykrycia błędów w trakcie testów nie oznacza, że one nie istnieją. Chociaż przeprowadzenie testów zmniejsza ryzyko pozostawienia w oprogramowaniu niedoskonałości, nie można jednoznacznie stwierdzić, że aplikacja działa bezbłędnie w 100%.
Testowanie gruntowne jest niemożliwe
Po przeczytaniu, że testowanie nie jest w stanie wykryć wszystkich błędów, część z Was zaczyna zastanawiać się nad sensownością tego procesu. W tym momencie do gry wchodzi kolejna zasada mówiąca, że testowanie gruntowne jest niemożliwe - to znaczy nierealne jest sprawdzenie wszystkich ścieżek w oprogramowaniu (chyba, że mówimy o nieskomplikowanych, małych aplikacjach). Analiza wszystkich możliwych przypadków testowych wymagałaby ogromnej (wręcz niemożliwej) ilości czasu Dodatkowo zawsze może pojawić się nowy przypadek czy inne dane testowe, które wypadałoby uwzględnić.
Dlatego kluczowe jest określenie priorytetów, skupienie się na kluczowych obszarach aplikacji, opracowanie planów testowych, przeprowadzenie analizy ryzyka (aby zidentyfikować najbardziej krytyczne obszary pod względem błędów) oraz stworzenie spójnej strategii testowania. Wszystko to zmniejsza ryzyko pominięcia istotnych błędów i zwiększa skuteczność procesu testowania.
Wczesne testowanie oszczędza czas i pieniądze
Kolejna zasada dotyczy wczesnego przeprowadzania testów (tzw. shift left testing). Im wcześniej je wykonamy, tym więcej oszczędzimy czasu i pieniędzy. Dlaczego? Otóż dlatego, że błędy wykryte na wczesnym etapie są łatwiejsze do naprawienia i wymagają mniejszych zmian w kodzie oprogramowania. Swoją drogą, nie musi to wcale dotyczyć testów wykonywanych bezpośrednio na aplikacji. Świetnym sposobem jest analiza dokumentacji i wymagań - to pozwala na wykrywanie problemów jeszcze na etapie projektowania.
Kumulowanie się defektów
Kolejna zasada wskazuje, że większość błędów znajduje się tylko w kilku konkretnych obszarach aplikacji, a nie jest rozproszona na całą jej przestrzeń. Dlatego ważne jest, aby właśnie te obszary traktować priorytetowo. To łączy się z drugą zasadą, która mówi, że kompleksowe przetestowanie jest niemożliwe, dlatego konieczna jest analiza ryzyka.
Paradoks pestycydów
Przechodzimy do paradoksu pestycydów, któremu poświęciłem osobny wpis. Przypomnę więc tylko, że jest to zjawisko, podczas którego testy przestają wykrywać nowe błędy. Ciągłe wykonywanie tych samych zestawów testów może doprowadzić do pominięcia niewykrytych dotąd defektów. Jedną z metod na walkę z tą sytuacją jest stała aktualizacja przypadków testowych i dostosowywanie ich do zmian w oprogramowaniu.
Testowanie zależy od kontekstu
A teraz czas na często poruszaną przeze mnie wiedzę domenową. Warto zdać sobie sprawę, że mimo istnienia różnych metod i zasad testowania, każde oprogramowanie wymaga innego podejścia do testów. Nasza strategia testowania powinna być dostosowana do specyfiki danej aplikacji. Dla przykładu - w sklepie internetowym kluczowe będzie zapewnienie łatwości nawigacji po aplikacji oraz sprawdzenie jej wydajności pod kątem obsługi wielu użytkowników jednocześnie. Natomiast w module związanym z bankowością priorytetem będzie zapewnienie bezpieczeństwa danych.
Mylne przekonanie o braku błędów
Na końcu wpisu (ale zaskoczenie 😄) przechodzimy do ostatniej zasady, a konkretnie do mylnego przekonania o braku błędów. Założenie, że oprogramowanie jest pozbawione defektów może być kosztowne w skutkach. Choć problem ten często dotyczy strony biznesowej organizacji, sami testerzy także nie powinni zakładać, że aplikacja jest całkowicie wolna od błędów. Nawet niewielkie zmiany w funkcjonalnościach mogą prowadzić do powstawania nowych defektów, o których wcześniej nie mieliśmy pojęcia.
Chcesz być na bieżąco? Zapisz się do newslettera!
W każdy czwartek o 10:00 wyślę Ci wiadomość o moich nowych wpisach. Oprócz tego, dorzucę ciekawe artykuły, filmy czy inne materiały ze świata IT - oczywiście, związane głównie z testowaniem oprogramowania. To świetny sposób na naukę i ciągłe zdobywanie wiedzy.
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)
