Praktyka jest nieodłącznym elementem naszej pracy. To dzięki niej stajemy się pewniejsi, szybsi, dokładniejsi i bardziej efektowni w zadaniach dnia codziennego. Z pisaniem Przypadków Testowych jest z jak pieczeniem ciasta, czym więcej razy je upieczesz, tym większe są szanse, że nie wyjdzie zakalec: ) I tutaj porównanie pisania TC (skrócimy sobie słowa Przypadki Testowe do „TC” z ang. Test Cases) do pieczenia ciast nie jest wcale głupie i bezinteresowne, mają one ze sobą dużo wspólnego 🙂 W dzisiejszym wpisie postanowiłam przygotować was do pisania właściwych i przede wszystkim takich TC, dzięki którym wasza praca będzie prostsza i przyjemniejsza.

Na samym starcie zapoznajcie się z charakterystyką pojęcia, które znajduje się w słowniku ISTQB:

Przypadek Testowy — 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 testowego jak wykonanie pewnej ścieżki programu, lub zweryfikowanie zgodności z pewnym wymaganiem.

Jeśli nigdy nie pisaliście TC, to najwyższy czas, aby poznać najważniejsze informacje na ich temat. Tak jak wszędzie ważny jest plan a później jego realizacja. W tym wpisie stworzymy plan, który w następnych wpisać będziemy mogli wykorzystać w napisaniu naszych TC. Poniżej zobaczycie listę elementów, które powinien zawierać każdy TC, a następnie scharakteryzujemy sobie każdy z nich. Oczywiście musicie mieć na uwadze to, że w zależności od projektu niektóre elementy mogą być mniej lub bardziej wymagane. My weźmiemy sobie pod uwagę listę tych standardowych i najczęściej używanych: ).

 

Na powyższym obrazku umieściłam najważniejsze elementy, które zawiera każdy TC. Zanim jednak przejdziemy do głębszej analizy każdego z nich, warto wymienić sobie pozostałe wartości, które w zależności od narzędzi, z jakich korzystamy w naszej pracy, są wprowadzane na różne sposoby.

Pierwsze co musimy zrobić to nadać nazwę naszemu TC — dla niektórych oczywista sprawa, ale dla pozostałych być może mniej dlatego też wymienimy sobie ten krok. Warto tutaj zaznaczyć, że powinna być ona unikalna. Ja najczęściej w swojej pracy mojemu TC daję przedrostek np. TC001_KrótkaNazwa.

W pracy używam konkretnego narzędzia do pisania TC, który wymaga ode mnie po nadaniu nazwy, również krótkiej charakterystyki tego konkretnego przypadku testowego. Nie jest to oczywiście wszystko, jest bardzo wiele innych możliwości. Można podać m.in. informację czy test jest testem manualnym. Oprócz tego można podać produkt, poziom testu, jego priorytet, trudność. Informacje takie jak twórca danego TC są już automatycznie wprowadzone. Te informacje oczywiście mogą się różnić, na wielu projektach piszę się testy w Excelu, gdzie nie występują takie wartości i wprowadzamy informację, których wymaga dany projekt.

Wróćmy do kroków, które znajdują się na rysunku.

  1. Dane wejściowe — ja dla ułatwienia wykonania testu, zawsze wprowadzam tutaj sobie link do aplikacji oraz użytkownika, na którego trzeba się zalogować. W zależności od wymagań funkcjonalnych, do których tworzę TC, można wprowadzić tu informację czy dany użytkownik ma jakieś prawa, czy może ma mieć je odebrane. Warto w tym kroku zawrzeć wszystkie istotne informacje, które mogą mieć wpływ na to, jak będzie przebiegał nasz test. Często zdarza się, że ktoś inny wykonuje za nas dany TC i być może nie zna dokładnie wszystkich informacji, dlatego dużo łatwiej będzie mu pracować, jeżeli wszystko będzie napisane jasno krok po kroku.
  2. Kroki — za ich pomocą po kolei wpisujemy czynności, które mają zostać wykonane. Powinny być one krótkie i konkretne. Wykonywane są w zakresie danego przypadku testowego.
  3. Oczekiwane rezultaty — każdy krok zawiera czynności, które wykonujemy. Wszystkie z czynności mają opisany również wynik oczekiwany, czyli to, w jaki sposób ma się zakończyć dana czynność. Jeżeli kończy się tak jak jest to opisane w naszym TC, oznacza to poprawne działanie, jeżeli zachowuje się inaczej zgłaszamy błąd oraz zaznaczamy, że dany krok nie przeszedł pomyślnie.

W tym wpisie udało nam się zapoznać z wszystkimi informacjami niezbędnymi do tworzenia Przypadków Testowych. Mam nadzieję, że wszystko jest dla was jasne i klarowne. W dalszych wpisach razem napiszemy przykładowy przypadek testowy. Omówimy sobie pojęcia takie jak: przypadek testowy niskiego, wysokiego poziomu oraz scenariuszu testowego. Udanego wieczoru i do następnego wpisu: )

Zostaw odpowiedź

Twój adres e-mail nie zostanie opublikowany.

  • 17 marca, 2017 o 10:37 pm

    Bardzo slusznie! Praktyka to najlepsza nauka !

  • 17 marca, 2017 o 10:58 pm

    Jestem pod wrażeniem jak profesjonalnie wszystko zostało opisane! 🙂
    No wooow… Podziwiam 🙂

  • 21 marca, 2017 o 1:29 pm

    Nie jestem najlepsza jeśli chodzi o pisanie takich rzeczy. Haha Ale ogólnie masz rację, i dodatkowo świetnie wszystko opisałaś 🙂

  • 21 marca, 2017 o 4:02 pm

    Świetny wygląd bloga, to po pierwsze. Post bardzo mądry i dokładnie opisany. Bede czesto wpadac. Wracając do tematu, to praktyka i doświadczenie może być najlepszym sposobem na naukę czegoś:) zgadzam sie w 100%
    clofl.blogspot.com

  • 21 marca, 2017 o 8:18 pm

    O ła! To jest naprawdę mega profesjonalny post. Zawsze jak do Ciebie wpadam czuję, że Tworzysz to miejsce z naprawdę dużą dokładnością. 🙂 Nawiązują do postu, praktyka czyni mistrza. To święta racja!

  • Artur
    25 sierpnia, 2021 o 7:36 pm

    A kiedy pisze się przypadki testowe? W trakcie powstawania oprogramowania czy po zakończeniu np. jakiejś części prac nad np. nową funkcjonalnością oprogramowania?

  • BL
    6 lutego, 2023 o 10:52 pm

    Jestem początkująca. Rozumiem, że przypadki testowe pisze się na podstawie specyfikacji. W której pisze co i jak ma działać. A dopiero po napisaniu tych przypadków sprawdza się je czy wykonały się zgodnie z oczekiwanym rezultatem. Czy robi się to równocześnie ?

Ten serwis wykorzystuje pliki cookies. Korzystanie z witryny oznacza zgodę na ich zapis lub odczyt wg ustawień przeglądarki. Więcej
Zgoda