Konstruowanie przypadków testowych, które nie są do bani (i jak uniknąć najczęstszych błędów)

Testowanie oprogramowania jest kluczowym elementem cyklu życia oprogramowania. Bez niego, możesz przegapić problemy z funkcjonalnością lub poważne błędy użyteczności, które w efekcie końcowym będą frustrować Twoich użytkowników. Ale wszystkie przypadki testowe nie są sobie równe. Pisanie wysokiej jakości, efektywnych przypadków testowych jest tak samo ważne jak testowanie aplikacji. W rzeczywistości, słabe przypadki testowe mogą skutkować procesem testowania, który jest niewiele bardziej efektywny niż brak testowania w ogóle.

Więc, co mają wspólnego słabo napisane przypadki testowe? Jak profesjonaliści zajmujący się testowaniem oprogramowania mogą pisać przypadki testowe wysokiej jakości, unikając przy tym powszechnych błędów? Aby się tego dowiedzieć, przeszukaliśmy sieć w poszukiwaniu najlepszych porad dotyczących pisania efektywnych przypadków testowych i dotarliśmy do panelu profesjonalistów z dziedziny rozwoju i testowania oprogramowania, prosząc ich o udzielenie odpowiedzi na to pytanie:

„Co mają wspólnego źle skonstruowane przypadki testowe (i jak deweloperzy mogą uniknąć tych błędów)?”

Poznaj nasz panel ekspertów w dziedzinie testowania oprogramowania:

Dowiedz się, co nasi profesjonaliści mieli do powiedzenia, czytając ich odpowiedzi poniżej.

Avaneesh Dubey

@qsometests

Avaneesh Dubey jest dyrektorem generalnym Qsome Tech. Jego kariera jest usiana silnym zestawem innowacji w różnych aspektach biznesu: Ludzie, Procesy i Technologia. Teraz buduje Qsome Tech jako najnowocześniejszy innowator w dziedzinie jakości oprogramowania.

„Jest kilka rzeczy, które łączy wiele źle skonstruowanych przypadków testowych…”

1. Zbyt specyficzne – uruchamiają tylko określony warunek testowy.

Przypadki testowe muszą uwzględniać różnorodne warunki, w których oprogramowanie będzie musiało sobie poradzić. Przypadek testowy musi być w stanie kompleksowo przetestować moduł oprogramowania z prawie wszystkimi możliwymi kombinacjami głównych warunków. Aby móc kompleksowo przetestować wszystkie kombinacje warunków, autor musi znaleźć sposób na przedstawienie tych warunków w taki sposób, aby było to łatwe do przejrzenia przez innych.

2. Obejmują niewielką część funkcjonalności – muszą testować większą część systemu.

Przypadki testowe często skupiają się na konkretnej funkcji. Często ta funkcja jest określona przez wewnętrzny projekt techniczny oprogramowania. Zamiast tego, przypadki testowe muszą odzwierciedlać wzorce użycia i przepływy. Każdy przypadek testowy powinien obejmować jak największą część przepływu, jak to tylko możliwe – przekraczając granice techniczne aplikacji.

3. Testowanie według określonej roli użytkownika.

Często spotykamy się z przypadkami testowymi napisanymi dla określonej roli użytkownika. Ogranicza to ich zakres, a co za tym idzie, znacznie obniża ich skuteczność. Przypadki testowe, które są najbardziej efektywne, odzwierciedlają wzorce użycia. Na przykład, aplikacja biznesowa powinna być testowana za pomocą przypadków testowych, które są zaprojektowane do testowania całego procesu biznesowego – obejmując wszystkie role użytkowników i wszystkie systemy, które mogą być zaangażowane w proces biznesowy.

4. Napisany, aby udowodnić, że najbardziej powszechne przypadki użycia są dobrze pokryte w aplikacji.

To, moim zdaniem, jest jeden z najczęstszych problemów i jest wynikiem tego, co nazywam „leniwym” podejściem do projektowania testów. Projektant testów po prostu powtarza dokument wymagań w przypadkach testowych. Projektant testów powinien zamiast tego szukać „przypadków narożnych” lub „warunków brzegowych”. Większość programistów jest w stanie łatwo napisać kod dla najczęstszych przypadków użycia. Problemy wychodzą na powierzchnię w momencie, gdy pojawia się warunek najczęstszego przypadku użycia. Dobrze zaprojektowany przypadek testowy z łatwością je wychwyci.

5. Każdy przypadek testowy może stać się całkowicie bezużyteczny, jeśli nie jest systematycznie katalogowany i udostępniany do użytku.

Wyobraź sobie bibliotekę, w której książki nie są skatalogowane i nie są systematycznie przechowywane na półkach. Niemożliwe byłoby korzystanie z książek, gdybyś nie mógł ich łatwo znaleźć, kiedy ich potrzebujesz.

Często setki przypadków testowych są pisane z dużym wysiłkiem, a następnie wrzucane do wspólnej struktury folderów. Chociaż może to działać, jeśli masz bardzo mało przypadków testowych, to po prostu zawala się to w momencie, gdy liczba przypadków testowych wzrasta. Dlatego też, potrzebujemy systematycznego tagowania i katalogowania przypadków testowych. Następnie system zarządzania testami powinien być w stanie „wyciągnąć” przypadki testowe, kiedy muszą zostać uruchomione. Tworzenie i utrzymywanie wielu wersji przypadków testowych jest kluczowe.

Wes Higbee

@g0t4

Wes Higbee jest prezesem Full City Tech Company.

„Kod testowy, który został wymuszony, jest zazwyczaj bezwartościowy…”

Prawdopodobnie istnieje reguła, że musi być 100% pokrycia kodu, albo że nie można dodać kodu bez przynajmniej jednego testu. Więc ludzie piszą tylko tyle kodu testowego, aby spełnić tę regułę. Jest to gloryfikowana papierkowa robota, raporty TPS (Office Space).

Ludzie uczą się przez naśladowanie tego, co obserwują. Więc jeśli wymagasz testowania bez pomagania ludziom w zrozumieniu wartości testowania, wtedy mają tendencję do postrzegania go jako ceremoniału i po prostu próbują skopiować istniejące testy i wepchnąć w nie swój przypadek użycia.

Testowanie nie jest celem samym w sobie. Testowanie, kiedy jest korzystne, daje pewność, może zaoszczędzić czas i może zabezpieczyć przyszłe zmiany. Jeśli więc ludzie, którzy doświadczyli tych korzyści, mogą przekazać je rówieśnikom, wtedy inni ludzie będą szukać tych korzyści, a to często prowadzi do produktywnego testowania.

Ludzie, którzy doświadczyli korzyści z testowania, powinni próbować wychwalać te korzyści, a nie samo testowanie. Na przykład, jeśli weźmiesz jakiś skomplikowany kod w prawdziwym systemie oprogramowania, który w przeszłości był najeżony błędami, i umieścisz wokół niego kilka prostych testów i nie będziesz już miał tych błędów – wtedy zaufanie wzrośnie, ludzie nie będą się tak bać, i będą o tym pamiętać i przyniosą testowanie do stołu, kiedy następnym razem poczują się niepewnie.

Nie musisz nakazywać testowania, jeśli ludzie doświadczyli korzyści z pierwszej ręki.

Bernard Perlas

@MyCorporation

Bernard Perlas jest Kierownikiem ds. Zapewnienia Jakości w MyCorporation, który ukończył Uniwersytet DeVry. Wykonuje testy dla istniejących produktów, jak również aktualizacje produktów i systemów wewnętrznych. Pracuje nad projektowaniem testów automatyzacji UI i testami grey-box strony, aby upewnić się, że informacje są poprawne.

„Słabo skonstruowane przypadki testowe mają niejasne kroki testowe…”

Aby uniknąć tych błędów, musisz być konkretny w odniesieniu do tego, co testujesz i mieć jasność co do swoich kroków po drodze. Im bardziej jesteś konkretny, tym bardziej będziesz w stanie odtworzyć problemy i zidentyfikować obszary do poprawy i działać na nich.

Benjamin Waldher

@wildebeest_dev

Benjamin Waldher jest Lead Dev Ops Engineer w Wildebeest.

„Słabe przypadki testowe są często bardzo zależne od…”

Wewnętrznego działania testowanego kodu, co może oznaczać, że jeśli wewnętrzne szczegóły funkcji zostaną zmienione, to przypadek testowy się zepsuje – nawet jeśli funkcja już działa poprawnie. Jeśli masz wrażenie, że popełniasz ten błąd, może to być spowodowane tym, że testowane funkcje są zbyt długie, lub może być konieczne zastosowanie większej separacji obaw.

Matt MacPherson

@itsMattMac

Matt MacPherson jest założycielem Edabit.

„Jest kilka rzeczy, które źle skonstruowane przypadki testowe mają ze sobą wspólnego…”

1. Testowanie nieistotnych rzeczy

Testowanie bez żadnego prawdziwego celu jest bezcelowe. Jestem wielkim fanem zasady pojedynczej odpowiedzialności. Każdy test jednostkowy powinien testować jedną rzecz i tyle.

2. Testowanie od razu

Pewnie dostanę za to sporo batów, ale nigdy nie testuję jednostkowo, dopóki moje decyzje projektowe nie są ugruntowane. Dzieje się tak dlatego, że wiem, że jestem zobowiązany do wprowadzenia dość dużych zmian, a te zmiany prawdopodobnie zepsują wiele z moich testów. Oznacza to, że w praktyce albo skończę pisząc mniej testów, albo nie będę wprowadzał dużych zmian w projekcie. Obie te rzeczy są złe, a czekanie na jasność projektu rozwiązuje ten dylemat.

3. Testy integracyjne vs. testy jednostkowe

Widzę wielu programistów wykonujących testy integracyjne, kiedy tak naprawdę próbują testować jednostkowo (i vice versa). Kiedy testujesz aplikację jako całość pod kątem błędów, jest to uważane za test integracyjny. Test jednostkowy dotyczy zachowania jednej konkretnej jednostki kodu, podczas gdy test integracyjny dotyczy zachowania aplikacji jako całości.

Manu Singh

@ClrMobile

Manu Singh jest architektem mobilnym w Clearbridge Mobile z doświadczeniem w projektowaniu, rozwoju i testowaniu systemu Android. W Clearbridge, Manu zarządza zasobami projektu dla zespołu programistów budujących światowej klasy aplikacje dla klientów korporacyjnych.

„Istnieje kilka cech wspólnych źle skonstruowanych przypadków testowych…”

Po pierwsze, przypadki testowe mogą być zbyt proste, co oznacza, że testują tylko główną funkcję bez testowania zbyt wielu ekstremalnych przypadków. Aby tego uniknąć, programista powinien uwzględnić jak najwięcej przypadków narożnych. Jeśli interfejs jest tworzony i wymaga wejścia, które nie jest trywialne, to testowanie na złe lub puste wejścia jest ważne.

Po drugie, źle skonstruowane przypadki testowe nie odzwierciedlają tego, jak użytkownik będzie postrzegał i używał funkcjonalności. Tworzenie przypadków testowych w tym celu jest trudniejsze, ponieważ musisz wczuć się w sposób myślenia innego użytkownika. Rozważ segmentację użytkowników i zidentyfikowanie ich przypadków użycia. Następnie zidentyfikuj najszybsze ścieżki do ukończenia podróży użytkownika, ponieważ użytkownik będzie starał się ograniczyć liczbę kroków, które musi wprowadzić, aby ukończyć daną podróż. Ważne jest, aby zakwalifikować różne przypadki użycia, z projektantami i kierownikami projektu, aby dalej identyfikować tego typu przypadki testowe.

I wreszcie, źle skonstruowany przypadek testowy nie testuje przeciwko aspektom aplikacji, które mogą powodować, że jest ona uruchamiana równolegle lub po sobie. Często zdarza się, że przypadki testowe testują tylko konkretną cechę aplikacji, nie widząc konsekwencji włączenia wielu funkcji i ich wzajemnego powiązania. Rozważenie wielofunkcyjnych przypadków testowych jest ważne, szczególnie jeśli istnieją ograniczenia wydajności. Dwie pozornie odrębne funkcje mogą zużywać te same zasoby, powodując w ten sposób impas.

Rick Rampton

@QASource

Rick Rampton jest szefem działu Client Success w QASource, nadzorując marketing, sprzedaż i zarządzanie klientami. Odegrał kluczową rolę w budowaniu QASource, z udokumentowanym doświadczeniem w budowaniu, zarządzaniu i utrzymywaniu wysokowydajnych zespołów inżynierskich poza granicami kraju. Siedziba główna znajduje się w Pleasanton, Calif.., QASource jest jednym z wiodących na świecie dostawców usług w zakresie zapewnienia jakości oprogramowania.

„Istnieje wiele identyfikatorów, za pomocą których możemy rozpoznać źle skonstruowany przypadek testowy…”

1. Wiele razy, podsumowanie słabych przypadków testowych nie podkreśla celu przypadku testowego, lub tego, co musi zostać osiągnięte.
2. Warunek wstępny do wykonania przypadku testowego nie jest jasno określony lub go brakuje, co może powodować zamieszanie dla dewelopera/testera, co do tego, jakie dane testowe lub warunki są wymagane przed wykonaniem przypadku testowego.
3. Jeśli w przypadkach testowych brakuje kroków, to pozostawia to luki dla dewelopera/testera, powodując, że przyjmują oni założenia podczas wykonywania przypadków testowych. Może to spowodować niedokładne wykonanie przypadków testowych i pominięcie ważnych scenariuszy.
4. Brak odpowiedniego środowiska do wykonania przypadków testowych jest kolejnym wskaźnikiem źle skonstruowanych przypadków testowych.
5. Jeśli oczekiwany rezultat nie jest jasno opisany w przypadku testowym, wtedy tester nie będzie pewny co do wyników, które musi zweryfikować za pomocą tego przypadku testowego.

Rachel Honoway

@rachelhonoway

Rachel jest doświadczonym menedżerem specjalizującym się w startupach internetowych i firmach działających w trybie wzrostu. W swojej karierze współpracowała z przedsiębiorcami przy tworzeniu i rozwijaniu produktów SaaS oraz powiązanych usług.

„Sekwencja zdarzeń jest często zbyt uproszczona, co prowadzi do źle skonstruowanego przypadku testowego…”

Deweloperzy mają tendencję do zakładania prostej, logicznej ścieżki od początku do końca. W rzeczywistości jednak, użytkownicy końcowi podążą wykładniczą liczbą ścieżek, z których wiele jest nielogicznych. Kiedy programiści nie poświęcają czasu na rozważenie wszystkich zmiennych, które mogą mieć wpływ na użytkownika w momencie, kiedy ma on do czynienia z daną cechą/stroną/funkcją, pozostawiają wiele miejsca na fałszywe pozytywne testy.

Dodatkowo, programiści powinni obserwować kilku użytkowników w trakcie ich interakcji z platformą, a następnie spędzić trochę czasu pytając wewnętrznych rzeczników klienta (wsparcie klienta, menedżerów produktu, agentów sprzedaży), aby lepiej zrozumieć użytkownika. Przedstawiciele handlowi mogą pomóc zdefiniować, kim jest użytkownik i opisać potrzebę, którą aplikacja zaspokaja. Przedstawiciele działu wsparcia klienta mogą zidentyfikować wspólne punkty sporne dla bazy użytkowników, takie jak zgubione hasła lub wspólne czynniki rozpraszające uwagę, takie jak reklamy na stronie. Menedżerowie produktu mogą zapewnić wgląd w to, w jaki sposób użytkownik wchodzi w interakcję z aplikacją i jak ta interakcja wpisuje się w większy przepływ pracy użytkownika lub codzienną rutynę, opisując czynniki rozpraszające występujące poza samą aplikacją (zarządzanie wieloma ekranami jednocześnie, użytkownicy telefonów komórkowych otrzymujący powiadomienia podczas jazdy samochodem, itp.)

Zrozumienie tego, co może prowadzić użytkownika końcowego z dala od logicznej, prostej ścieżki pomoże programistom przetestować te zmienne i zapewnić udane doświadczenie pomimo rozproszenia uwagi, nielogicznych ścieżek i utraty koncentracji.

Anthony Breen

@BreenAnthony77

Anthony Breen jest współzałożycielem i dyrektorem generalnym aplikacji Feasty Eats. Feasty Eats to zintegrowana platforma SaaS, która pomaga restauracjom w napędzaniu ruchu w czasie, gdy ich sprzedaż jest niewielka.

„Rozważając przypadki testowe…”

Dla deweloperów ważne jest, aby powrócić do niektórych z najprostszych, a zarazem najważniejszych aspektów procesu wnioskowania. Podobnie jak w eksperymencie naukowym, istnieją dwa czynniki, które muszą być na pierwszym planie w umyśle każdego programisty, aby ułatwić efektywny i znaczący test: jasność i kontrola. Mówiąc dokładniej, jasno nakreślone hipotezy i staranna uwaga poświęcona kluczowym wskaźnikom wydajności muszą być zakomunikowane przed rozpoczęciem testu. W ten sposób tworzy się solidne ramy dla dalszych badań.

Dodatkowo, istotne jest, aby wszystkie zmienne były nie tylko zidentyfikowane, ale również starannie kontrolowane. Należy wyeliminować uprzedzenia z populacji testowych i zidentyfikować potencjalne zmienne zakłócające, aby twórcy mogli uzyskać wnikliwe, dokładne dane. Dobrze zdefiniowany i jasno wyartykułowany cel, w połączeniu ze skrupulatnie kontrolowanym środowiskiem testowym, nie tylko przyniesie wartościowe wyniki, ale co ważniejsze, wywoła nowe pytania i hipotezy, które doprowadzą do poszerzenia zakresu badań.

Devlin Fenton

@devfen

Devlin Fenton jest dyrektorem generalnym Go99. Devlin kieruje małym, wyspecjalizowanym zespołem inżynierów i programistów, którzy zajmują się rozwiązywaniem problemów przez przemysł, dla przemysłu. Zespół ten ostatnio uruchomił cyfrową platformę dopasowywania ofert transportowych, która ma zmienić branżę truckingową w Ameryce Północnej, wartą 700 miliardów dolarów. Devlin uważa, że zbuduj zespół ekspertów i pozwól im się rozwijać.

„Najgorsze przypadki testowe to te, które nie istnieją…”

Największym problemem jest to, że jest ich za mało i nie można wiarygodnie przetestować systemu w sposób zautomatyzowany. Brakuje w nich uwzględnienia priorytetu. Kiedy już programiści zabierają się za pisanie przypadków testowych, często tworzą wiele łatwych, które testują trywialny, statyczny i mało ryzykowny kod. Wysiłek powinien być skierowany na skomplikowany i ryzykowny kod, a do tego, czasami przypadek użycia jest również bardziej skomplikowany i trudniejszy do opracowania.

Przekonanie jest takie, że jeśli nie jest to test jednostkowy, nie powinien być wykonywany. Testy integracyjne, testy danych, testy wydajnościowe, testy warunków skrajnych i tak dalej powinny być częścią zestawu testów.

Brak koncentracji na celu jest kolejnym problemem. Na przykład, czy jest to test jednostkowy, test integracyjny, test wydajnościowy, czy jeszcze inny? Mieszanie tych priorytetów sprawia, że przypadki użycia są bardziej kruche i trudniejsze do naprawienia. Muszą one być skoncentrowane i odpowiednio adnotowane, aby zestaw testów mógł być wykonany w sposób ukierunkowany.

Dodatkowo, niektórym przypadkom testowym brakuje dokładności poprzez pokrycie tylko szczęśliwej ścieżki, a nie wystarczająco dużo przepływów alternatywnych i wyjątków. W efekcie, przypadek użycia podąża za standardem dewelopera make-it-work, zamiast standardem testowania make-it-fail.

Kolejnym problemem są przypadki testowe, które nie są utrzymywane, co sprawiłoby, że nie powiodłyby się, gdyby zostały uruchomione, lub są całkowicie wykomentowane. W pośpiechu, programiści często zmieniają kod i omijają naprawianie przypadków testowych.

Słabo skonstruowane przypadki testowe mogą również nie mieć jasności co do tego, co jest testowane, włączając w to obiekt, metodę lub scenariusz. Przypadki testowe powinny stosować konwencję (nazewnictwo, komentarze, itp.), która ułatwia identyfikację zakresu testu.

Dobre przypadki testowe unikają sieci zależności. Zależności pomiędzy testami powinny być unikane; w przeciwnym razie, pojedyncze niepowodzenie może pokazać wiele testów, co utrudni identyfikację przyczyny. Jeśli istnieje wspólna logika dla ustanawiania warunków wstępnych lub oceny wyników, taka logika powinna być wyabstrahowana i współdzielona zamiast układania przypadków testowych w stos.

Rohit Keserwani

@EquifaxInsights

Rohit Keserwani jest konsultantem BI i starszym analitykiem biznesowym w Equifax.

„Zaobserwowałem następujące cechy powszechnie występujące w złych przypadkach testowych…”

1. Nieudokumentowana analiza wpływu. Kiedy analityk testowy nie dokumentuje wpływu, zakłada, że nie zna tego wpływu. Wynik? POOF…!

2. Warunek wstępny testu nie jest zdefiniowany lub jest luźno wyrażony.

3. Przeoczenie tła użytkownika i zakładanie rzeczy. Jeśli nie rozumiesz poziomu wiedzy osoby, która będzie testować, nie zakładaj niczego. Po prostu dokumentuj wszystko do najdrobniejszego szczegółu. Jeśli nie, możesz w końcu założyć, że brakuje jej jakiejś wiedzy, co może spowodować, że użytkownik będzie testował inaczej niż się spodziewał.

4. Kryteria zaliczenia i tolerancja nie są jasno określone. Jeśli z jakiegoś powodu kryteria zaliczenia nie są jasno określone, osoba testująca jest zdana na swoją fantazję, aby zdecydować czy dany test przeszedł czy nie. Jeśli nie masz jasno zdefiniowanego scenariusza zaliczenia, tester nie będzie miał punktu odniesienia, z którym mógłby się porównać. To stworzy niejednoznaczność i ostatecznie postawi na szali cały wysiłek testowania.

Pete Van Horn

@PraxentSoftware

Pete Van Horn jest analitykiem technologii biznesowych w Praxent.

„Mam wiele doświadczeń ze źle skonstruowanymi przypadkami testowymi i prawdopodobnie sam jestem winny ich pisania od czasu do czasu…”

Wiele razy przypadek testowy nie jest łatwy do wykonania. Jeśli jestem programistą, powinienem być w stanie mieć wystarczająco dużo informacji i być umiejscowiony w sposób, w którym mogę wykonać mój przypadek testowy, aby określić wynik. Myślę, że jedną z rzeczy dotyczących przypadków testowych jest to, że nie muszą one koniecznie prowadzić do zamierzonego rezultatu, ale zawsze muszą być wykonalne od końca do końca. Nawet jeśli uzyskasz negatywny wynik, to jest to lepsze niż utknięcie. Źle skonstruowany przypadek testowy nie pozwala temu, kto przeprowadza testy, na wykonanie go w całości.

W kwestii błędów programistów, może za dużo o tym myślę, ale zazwyczaj programiści nie piszą przypadków testowych. Mogą pisać testy jednostkowe, ale przypadek testowy jest zwykle pisany przez analityka biznesowego lub architekta rozwiązań. To oni są odpowiedzialni za tworzenie tego, co powinno być oczekiwanym rezultatem. Powiedziałbym, że posiadanie dobrze napisanych przypadków testowych tak naprawdę znajduje swoją genezę w posiadaniu naprawdę dobrze napisanych wymagań. Posiadanie dobrych wymagań pozwala na stworzenie dobrego przypadku testowego. A dobry przypadek testowy jest w stanie być wykonany od końca do końca, bez przerwy.

Hans Buwalda

@logigear

W Stackify rozumiemy, jak kluczowe jest testowanie oprogramowania w cyklu życia oprogramowania, więc jest to temat, który regularnie omawiamy. Czy wiesz, że możesz zintegrować APM z Twoją strategią testowania? Dowiedz się, jak to zrobić tutaj.

Aby uzyskać więcej porad ekspertów na temat pisania wysokiej jakości przypadków testowych (i dlaczego jest to metoda naukowa), sprawdź ten post, lub odwiedź ten artykuł, aby zapoznać się z listą 101 porad i wskazówek dotyczących testowania oprogramowania. Aby uzyskać bardziej dogłębne spojrzenie na rodzaje testów wydajności i testowania oprogramowania, etapy testowania wydajności i najlepsze praktyki, odwiedź ten przewodnik.