Przejdź do:
Przypadki testowe
Jedną z podstawowych czynności testerskich jest tworzenie przypadków testowych w oparciu o zdefiniowane wymagania, co do wytwarzanego oprogramowania. Według definicji ISTQB hasło przypadek testowy (ang. test case) to:
„Zbiór danych wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów i końcowych warunków wykonania, opracowany w określonym celu lub dla warunku zweryfikowania zgodności działania programu z oczekiwanym rezultatem lub sprawdzenia warunku testowego”.
Przypadki testowe mogą mieć charakter ogólny bądź bardziej szczegółowy.
Przypadki testowe wysokiego poziomu
Te pierwsze tworzone są bez konkretnych wartości wejściowych czy oczekiwanych rezultatów. Zazwyczaj są stosowane, gdy wartości oczekiwane nie są jeszcze dostępne dla testera na etapie tworzenia przypadków lub wymagania są niedodefiniowane czy też podane w sposób ogólny. Są także przydatne, gdy na przykład w zespole jest doświadczony tester i chce zachować swobodę wykonywania testów, ponieważ pozwalają one na większą kreatywność przy ich wykonywaniu, przy jednoczesnym zachowaniu zgodności z konkretnym wymaganiem.
Przypadki testowe niskiego poziomu
Definicja przypadku testowego niskiego poziomu zawiera konkretne wartości wejściowe i oczekiwane wyniki. Taki rodzaj przypadków testowych dobrze jest stosować w sytuacji, kiedy tester jest niedoświadczony. Inny przykład to gdy testy wykonuje ekspert w danej dziedzinie, który zna doskonale system, jednak nie posiada wiedzy z zakresu testowania oprogramowania i odpowiednich informacji. Dobry przypadek testowy niskiego poziomu służy również do zewnętrznej weryfikacji, takiej jak audyt procesu testowania.
Z czego składa się przypadek testowy?
Klasyczny przypadek testowy powinien zawierać poszczególne składowe, jakimi są:
- unikalny identyfikator – to nic innego, jak unikalne oznaczenie przypadku, aby móc do niego w razie potrzeby bez problemu powrócić,
- cel – opisuje przyczynę stworzenia i przeprowadzenia testu,
- warunki wstępne – opisują kryteria, jakie mają być spełnione przez środowiska i system, zanim test będzie mógł być wykonany,
- dane testowe (dotyczy przypadków testowych niskiego poziomu),
- oczekiwany wynik,
- warunki wyjściowe – czyli stan środowiska lub systemu po przeprowadzeniu testu.
Czasami dostarczenie tych wszystkich składowych i zawarcie ich w jednym przypadku testowym może być nie lada wyzwaniem dla testera. Zwłaszcza jeśli sam zajmuje się przygotowywaniem danych testowych do późniejszych przypadków testowych. Wszystkie te aktywności mogą zabierać sporo czasu. Wiadomo, że dziś czas to pieniądz, a więc w tym rozumieniu tworzenie przypadków testowych może być pojmowane jako waste. Jak więc zastosować ideę „zero waste” w testach? Jak tworzyć przypadki testowe, które będą zarówno dobrej jakości, jak i ich przygotowanie nie będzie zabierało wiele czasu?
Testy: mniej znaczy więcej?
Jak posiadać tylko to, co najbardziej potrzebne i odróżniać potrzebę od zachcianki? Z pomocą przychodzi koncepcja minimalizmu. Kierując się nią także w testach, spróbujmy ze składowych klasycznego przypadku testowego wyłuskać tylko te dane testowe, które są najbardziej potrzebne do przeprowadzenia testu. Moim zdaniem z wyżej wymienionych składników pozostałyby tylko takie części jak identyfikator oraz oczekiwany rezultat. Dlaczego właśnie te? Identyfikator to zazwyczaj numer – ale czasami może być to też tytuł – po którym możemy do danego przypadku wrócić w celu jego ponownego wykonania czy też utrzymania. Natomiast najbardziej potrzebną i istotną częścią przypadku testowego jest analiza oczekiwanych rezultatów i końcowych wyników konkretnego przypadku testowego (rezultat testu). Znając wynik, jaki miałby dać test, jesteśmy w stanie jasno stwierdzić, czy zastane zachowanie oprogramowania po poprawnie wykonanym teście zawiera błędy, czy nie – i zgłosić to do poprawy.
Czytaj również:
Jak szybko tworzyć przypadki wysokiego poziomu?
Wykorzystując jedynie identyfikator i oczekiwany rezultat, można szybko tworzyć przypadki testowe wysokiego poziomu, które nie zawierają zbędnych szczegółów. Ich przygotowanie zajmuje o wiele mniej czasu, ponieważ nie podajemy wszystkich szczegółowych danych. Taki typ przypadków testowych może być spisany w dowolnej formie, jeśli tylko wymagania projektowe na to pozwalają i dają oczekiwany rezultat.
Mapy myśli
Bardzo szybkim i efektywnym sposobem spisywania takich przypadków testowych jest tworzenie mapy myśli, która doskonale się w tych okolicznościach sprawdza. Dodatkowo metoda mapy myśli pobudza kreatywność, która jest bardzo ważna w pracy testera. Może więc przynieść dodatkową korzyść w postaci różnorodnych i lepszej jakości przypadków testowych niż te spisane tradycyjnymi sposobami.
Checklisty
Kolejnym sposobem na szybkie spisanie przypadków wysokiego poziomu mogą być wszelkiego rodzaju listy kontrolne (ang. checklist). Taka lista kontrolna to jedno z najważniejszych narzędzi w pracy testera. Siła listy tkwi w prostocie, ponieważ potrzeba tylko kartki i długopisu. Swoim zasięgiem może objąć każdy rodzaj testów, od testów wymagań po testy akceptacyjne. Należy tylko pamiętać, aby na liście kontrolnej umieszczać jedynie najważniejsze przypadki testowe. W myśl minimalizmu – lista kontrolna ma nas przecież chronić przed zrobieniem więcej, niż potrzeba. I tu pojawia się pokusa, jeśli chodzi o ograniczanie czasu spędzonego na przygotowywaniu przypadków testowych: dlaczego by nie pójść o krok dalej i nie przygotowywać ich wcale?
Metodyki zwinne
Projekty prowadzone wedle zwinnych metodyk są idealnym polem do wspomnianego wyżej eksperymentu. W momencie kiedy tester jest zaangażowany od samego początku w proces powstawania kryteriów akceptacji danego zadania, jest w stanie później na ich podstawie przeprowadzić testy. Co prawda testowanie w oparciu o warunki akceptacji charakteryzuje się tym, iż kryteria powinny być bezwarunkowo spełnione, a prawdziwe testy zaczynają się dopiero później, ale doświadczony tester bez większych problemów jest w stanie zapewnić pokrycie testowe dla alternatywnych ścieżek niż te opisane w kryteriach akceptacji. A tym samym sprawdzić różne scenariusze, nie tylko te opisane w wymaganiach. Jednak aby móc sobie pozwolić na taki minimalizm w testowaniu, osoba testująca powinna mieć już spore doświadczenia z przeróżnych projektów, a także dobrze wykształcony zmysł testerski. W innym wypadku istnieje spore ryzyko, że zadanie nie zostanie pokryte wystarczającą ilością testów, a tym samym jakość dostarczanego oprogramowania może być niższa.
Podsumowanie: czy minimalizm w testach jest dla każdego?
Czy minimalizm w testowaniu jest dla każdego? Ostatnie zdania poprzedniego akapitu zdają się być kluczowe w odpowiedzi na to pytanie. Testowanie bez przypadków testowych, a w oparciu o kryteria akceptacji lub z wykorzystaniem przypadków wysokiego poziomu, jest niebywale ryzykowne. Wymaga to dużego doświadczenia testera. Takie minimalistyczne praktyki testowe wymagają zarówno ugruntowanej wiedzy z zakresu testowania oprogramowania, dobrej znajomości testowanego produktu, jego charakterystyki, słabych punktów, jak i ścieżek krytycznych dla użytkowników. Niestety minimalizm często może przynieść więcej szkód niż pożytku. Nie znaczy to jednak, że nie zachęcam do eksperymentów z minimalizmem w pracy – wręcz przeciwnie! Warto od czasu do czasu wyjść ze swojej strefy komfortu i spróbować celowo ograniczyć swoje potrzeby. Choćby po to, żeby sprawdzić, czy rzeczywiście potrzeba aż tak wiele. Często okazuje się, że nie. Ale sprawdźcie sami!
Przeczytaj także:
Quality Assurance – jak zagwarantować jakość i bezpieczeństwo w projektach IT?
Testerka oprogramowania, której główną dewizą w pracy jest „Ufaj, ale sprawdzaj”. Testowanie to dla niej bycie rzetelnym na każdym etapie powstawania oprogramowania, natomiast najważniejszym czynnikiem w zespole jest komunikacja. Od początku swojej kariery związana z testami manualnymi aplikacji webowych, ale po 7 latach nadszedł czas na zmiany, bo pokochała testowanie mobilne i to z nim zamierza spędzić kilka najbliższych lat. Prywatnie pasjonatka motoryzacji i szczęśliwa posiadaczka Hondy CRX z '89 roku.