Dlaczego programiści potrzebują testów?
Kilka następnych poziomów będzie poświęconych testowaniu w sposób potrzebny programistom . Ale najpierw dowiedzmy się, czym jest testowanie i dlaczego jest potrzebne.
W odniesieniu do oprogramowania możemy powiedzieć, że zadaniem testowania jest sprawdzenie, czy program:
- robi to, co musi
- nie robi tego, czego nie powinna
Nawiasem mówiąc, drugi punkt jest nie mniej ważny niż pierwszy, ale o tym później.
Zacznijmy od punktu pierwszego. Co oznacza „program robi to, co powinien”?
Najpierw ktoś musi sporządzić listę wszystkich przypadków użycia programu. Po drugie, muszą opisać, jak program ma działać, jak powinien zachowywać się użytkownik i jakich efektów oczekuje. Nie możesz kontynuować dalej.
Gdy tylko napisaliśmy „jak powinien zachowywać się użytkownik”, cała idea pisania dobrej dokumentacji legła w gruzach. Ludzie to nie maszyny, co więcej, ludzie bardzo często zachowują się z oprogramowaniem tak, jak im się podoba . Nikt nie zaczyna poznawania technologii od studiowania instrukcji. To jest fakt.
Otrzymujemy zatem nowy fakt: osobliwością oprogramowania jest to, że ma wiele różnych scenariuszy pracy. Niektóre z nich są oczywiste, inne można udokumentować, inne można założyć, innych można się domyślić, a pozostałe 50% nawet nie przyjdzie Ci do głowy.
Z punktu widzenia programisty większość błędów wcale nie jest błędami. Błąd występuje wtedy, gdy program nie działa tak, jak powinien lub zgodnie z oczekiwaniami. A sytuacji, w których nie jest do końca jasne, jak program ma działać, jest mnóstwo, albo scenariuszy, które sobie przeczą…
Scenariuszy jest nieskończona ilość i zawsze znajdą się w produkcie przypadki, gdy program nie zachowa się zgodnie z oczekiwaniami (programista napisał kod tylko dla kilkudziesięciu scenariuszy). Dlatego można argumentować, że w każdym programie zawsze są błędy i każdy produkt można ulepszać w nieskończoność .
Potem wszystko sprowadza się do wygody. Najpierw programista naprawia największe błędy, potem mniejsze i tak dalej. I wreszcie przychodzi etap, w którym właściciel produktu uważa, że dalsza praca nad nim jest nieopłacalna ekonomicznie.
Ale wracając do błędów, które wszyscy uznają za błędy: program najwyraźniej robi coś źle, padł, coś zepsuł itp. Takie błędy można warunkowo podzielić na 3 kategorie: duże, średnie i małe.
I bardzo często zdarza się, że programista pracuje nad naprawą średnich lub nawet małych błędów, chociaż w projekcie jest jeszcze dużo poważniejszych problemów. Po prostu ich nie znalazł , więc pracuje nad największymi, o których wie.
Dlatego w każdym projekcie powinni być testerzy. Ci ludzie w szczególności uczą się patrzeć na produkt pod różnymi kątami. Możesz więc zobaczyć więcej scenariuszy programu. Ich zadaniem jest znalezienie błędów i spisanie ich (aby nie znaleźć tego samego błędu kilka razy).
Testowanie to proces mający na celu znalezienie błędów. Te błędy powinny zostać znalezione, opisane i uszeregowane pod względem ważności. Dopiero po ustaleniu priorytetów błędów możemy mówić o efektywnym procesie doskonalenia oprogramowania.
Pamiętaj, że pierwszym krokiem do rozwiązania problemu jest przyznanie, że problem istnieje . Nie możesz naprawić błędu, o którym nie wiesz.
Automatyzacja testów
Myślę, że wszyscy zgodziliśmy się, że testowanie jest ważne, więc spójrzmy na testowanie jak programiści. Jak programiści postrzegają testowanie? Programiści automatyzują pracę innych osób. Ostatnim zawodem, który zniknie, będzie zawód programisty.
Automatyzujemy wszelkie napotkane procesy. Dlatego testy muszą być zautomatyzowane. A jak zautomatyzować wyszukiwanie błędów? Krótka odpowiedź: nie. Ale tutaj znowu przychodzi nam z pomocą fakt, że jesteśmy programistami.
Proces tworzenia oprogramowania polega na ciągłych jego zmianach. właśnie w trakcie ciągłego wprowadzania zmian programiści bardzo często psują coś, co do niedawna działało dobrze.
A testerzy, zamiast szukać nowych błędów, są zmuszeni do ciągłego sprawdzania, czy nie popsuliśmy czegoś, co od dawna dobrze działa. Tak zwane testy regresyjne. To właśnie tego typu testy mogą i powinny być zautomatyzowane.
Tutaj całe oprogramowanie można podzielić na dwie części:
- program wchodzi w interakcję z osobą
- program wchodzi w interakcję z innym programem
Pierwsza opcja jest trudniejsza do zautomatyzowania, wymaga specjalnych automatorów testujących, nazywanych też QA Automation lub Software Test Engineer.
Ale druga opcja może i powinna być zautomatyzowana niezależnie. Jeśli masz oprogramowanie, które:
- działa dobrze
- już przetestowane
- realizowane jako osobny moduł lub blok logiczny
- nie planuje zmian
- od niego zależą inne moduły lub programy
- awaria funkcjonalna jest kosztowna
Polecam poświęcić czas na napisanie dla niego testów, które uchwycą kluczowe aspekty jego obecnej funkcjonalności. Rozsądnie byłoby przeznaczyć na to 5% swojego czasu pracy , czyli 1 dzień w miesiącu.
Nie ma potrzeby pisania testów dla samych testów.
Nikt nie będzie wspierał twoich testów. Ani inni programiści, ani ty. Nikt tego nie robi. 99% wszystkich testów pisemnych jest porzucanych i/lub wyłączanych. Jeśli nie umiesz pisać testów - nie pisz. Pisz tylko wtedy, gdy absolutnie nie możesz się bez nich obejść.
Rodzaje testów
Każdy programista, jeśli nie przeszedł specjalnego szkolenia, będzie mógł własnymi słowami powiedzieć, czym jest testowanie: sprawdzanie, czy program robi to, co powinien. Jednak profesjonaliści w tej dziedzinie wyróżniają całe obszary (rodzaje) testowania.
Wszystkie testy tak naprawdę obracają się wokół niezawodności i dostępności oprogramowania, ale aby lepiej zrozumieć kierunek testowania, spójrzmy na kilka przykładów.
Załóżmy, że testujesz typowy sklep internetowy. Następnie obszary testowania można podzielić na następujące typy: testy wydajnościowe, testy funkcjonalne, testy integracyjne i testy jednostkowe.
Jeśli właściciel witryny zdecyduje się rozpocząć poważną kampanię reklamową, to w tym samym czasie odwiedzi ją wielu użytkowników. Może się okazać, że strona nie upadnie, ale niektóre jej sekcje mogą działać wolno lub nawet przestać działać.
Aby temu zapobiec, musisz wcześniej zidentyfikować takie problemy i podjąć kroki w celu ich wyeliminowania. Odbywa się to za pomocą testowania obciążenia lub jest również nazywane testowaniem wydajności.
Możesz także chcieć przetestować, jak działa backend API i przetestować każdą jego funkcję: rejestrację, logowanie, dodawanie do koszyka, przetwarzanie płatności, zapisy do bazy danych itp. Wszystko powinno działać zgodnie z TOR. W takim przypadku należy przeprowadzić testy funkcjonalne .
Twój sklep internetowy jest najprawdopodobniej zintegrowany z usługami firm trzecich: wysyłaniem listów i SMS-ów, systemami płatności, czatami wsparcia online, zbieraniem opinii od użytkowników, systemami reklamowymi itp. Aby upewnić się, że wszystko działa zgodnie z założeniami, musisz przeprowadzić testy integracyjne .
Wreszcie złożone produkty są często dzielone na niezależne moduły. Z takich modułów można złożyć produkt końcowy, jak od konstruktora. Jeśli tworzysz taki moduł lub wchodzisz w interakcje z takimi modułami, będziesz musiał przeprowadzić testy jednostkowe .
Podsumowując, można powiedzieć, że testy funkcjonalne są potrzebne do przetestowania każdej pojedynczej funkcji serwisu. Integracja - do testowania interakcji dużych modułów i systemów Twojego produktu. Modułowy - do testowania osobnego modułu, cóż, testowania wydajności - do sprawdzania działania Twojej witryny pod obciążeniem.
Rodzajów testów może być nawet więcej: im bardziej złożony produkt, tym więcej aspektów jego rozwoju wymaga kontroli.