Wstęp

Za każdym razem, gdy staramy się zgłębić proces tworzenia software najczęściej dochodzi się do konkluzji: “należy zaadoptować najlepsze praktyki wypracowane przez lata doświadczeń w tym temacie w najlepszych firmach”. Jakkolwiek ta konkluzja wydaje się oczywista, brak jej implementacji w wielu firmach wprawia w zdumienie. Czym wyraźniejsza jest obecność w firmie tej świadomości, tym bardziej rosną jej szanse na powodzenie na rynku.

Poszukiwanie najlepszych praktyk jest procesem ciągłym. Część z nich jest dobrze znana i uznana, niektóre są dyskusyjne a inne są głęboko ukryte. Często praktyki te są tak oczywiste dla obserwatora, że mogą nawet nie zostać dostrzeżone – “po prostu w ten sposób działamy”. W innych przypadkach co jest znane w jednej firmie jest zupełnie nieznane w innej.

Lista przedstawiona w tym artykule skupia się na testowaniu software. Skupiając się na testowaniu nie można jednakże zapominać, że testowanie jest tylko częścią procesu. Jest czynnością ściśle zależną od procesu dewelopingu i jako takie musi uwzględniać praktyki developerskie. W końcu testowanie jest czynnością wydzieloną – jest ostatecznym sprawdzianem zanim użytkownik będzie mógł ocenić przydatność produktu.

Kolekcja ta została stworzona w oparciu o wiele źródeł i posiada dość długą historię. Część z nich zostało opracowanych wyłącznie w oparciu o literaturę, inne wynikają z doświadczeń grup, które uważają że są one wartościowe.

Podstawowe praktyki są jak kółka używane przy nauce jazdy na rowerze. Trzeba wiedzieć, że jeśli już umiesz jeździć, zdjęcie tych kółek nie oznacza że nie będziesz w stanie jeździć. Jest to podstawowa różnica, która dość często jest zapominana w tworzeniu software. “Co prawda wcześniej tworzyliśmy specyfikacje funkcjonalności, ale już nie tworzymy jej od jakiegoś czasu” – oznacza to że tak na prawdę zapomniane zostało, jak się jeździ a nie że nie trzeba tego robić. Podstawowe praktyki znane są już od jakiegoś czasu. Ich przydatność jest szeroka, niezależna od produktu i używanych procesów.

Podstawowe praktyki są skałą na której chroni przed złośliwością natury. Praktyki dodatkowe służą pomocą w specyficznych okolicznościach.
Podstawowe praktyki

Specyfikacja funkcjonalna

Jest kluczowym elementem wielu procesów tworzenia software i stało się bardzo modne. Jakkolwiek należy to do procesu develpmentu jej istnienie jest krytyczne dla testów funkcjonalnych. Specyfikacja funkcjonalna często opisuje spojrzenie od zewnątrz obiekty lub/i procedury wskazujące okoliczności przy których usługa nie może zostać uruchomiona. Inżynierowie testów używają jej w celu napisania testów typu Black Box.

Zaletą posiadania specyfikacji funkcjonalnej jest takie, że pisanie testów może następować równolegle do pisania kodu. Jest to korzystne z wielu względów. Po pierwsze powoduje to narzut czasu wynikający z serializacji w procesie tworzenia i testowania. W momencie gdy kod jest gotowy istnieją już przypadki testowe które go sprawdzają. Po drugie, wymuszają pewien poziom określoności z punktu widzenia developmentu i architektury, co jest istotne dla ogólnej efektywności procesu developmentu. Po trzecie, specyfikacja funkcjonalna staje się dokumentem który może być zaprezentowany klientowi by dać mu pogląd na to co faktycznie zostanie zaimplementowane.

Przegląd i inspekcja kodu

Została wymyślona w IBM przez Mike’a Fagan’a w połowie lat 70. Jest znana i uznana za jedno z najbardziej efektywnych metod debugowania kodu. Dziś istnieje wiele książek na temat inspekcji kodu. Narzędzia do inspekcji są łatwo dostępne a firmy consultingowe dostarczają szkoleń na ten temat. Często mówi się, że inspekcja kodu przyspiesza 10x proces debugowania software. Nie trzeba wiele dodawać jako, że jest to dobrze znana i rozumiana praktyka.

Formalne kryteria wejścia-wyjścia

Pomysł na formalne kryteria wejścia-wyjścia wywodzi się z ewolucji procesu wodospadowego ETVX (wymyślony przez IBM). Sama idea opiera się na tym, by każdy krok procesu jak inspekcje, testy funkcjonalne i pisanie kodu mial ściśle określone kryteria wejścia i wyjścia. Powinny być one określone w procesie developmentu i nadzorowane przez managerów, którzy dają zielone światło na przejście z jednej fazy do następnej. Można się spierać jak dokładne mają być to kryteria, a wraz z zacieraniem się granic w poszczególnych fazach kryteria wejścia-wyjścia wydają się wychodzić z użycia. Jak by nie patrzeć, praktyka ta pozwala na bardziej ścisłe zarządzanie procesem tworzenia software.

Testy funkcjonalne

Większość testów funkcjonalnych powstaje na podstawie specyfikacji funkcjonalnej jako testy Black Box. Liczność testów określa się zwykle jako wariacje przestrzeni danych wejściowych i możliwych stanów wyjściowych. Wariacje definiuje się jako określoną kombinację danych wejściowych które wyprodukują określony stan wyjściowy. Testy te powinny pokrywać na tyle przestrzeń stanów programu na ile uważa się to konieczne dla danego programu. Najlepsza praktyka w tym przypadku oznacza zrozumienie jak należy pisać wariacje które są adekwatne na tyle, by pokryć funkcjonalność. Nie ma dokładnych miar na pokrycie dla testów funkcjonalnych, praktyka pisania tych wariacji zakłada pewien element sztuki.

Testowanie na wielu platformach

Wiele produktów tworzonych obecnie oferowanych jest na wiele platformy jednocześnie. Daje to dodatkowe obciążenie zarówno przy tworzeniu jak i testowaniu produktu. Przy porotwaniu kodu z jednej platformy na inną, modyfikuje się kod często w celu polepszenia wydajności. Powoduje to konieczność testowania większości produktów na wielu platformach. Niezbędne są techniki umożliwiające usprawnienie tego zarówno w developmencie i testowaniu. Praktyka ta powinna być nakierowana na wszelkie aspekty wieloplatformowego testowania i developingu.

Bety wewnętrzne

Idea tworzenia software w wersjach beta opiera się na udostępnieniu produktu ograniczonej liczbie użytkowników w celu późniejszego zebraniu od nich opinii i uwag w celu usunięciu problemów przed właściwym wydaniem. W dużych firmach jak IBM, MS i Oracle wiele produktów używanych jest wewnątrz firmy. Daje to możliwość stworzenia właściwego środowiska dla beta testów. Istotne są techniki używane w celu właściwego wykorzystania dobrego pokrycia jak i efektywności przy wykorzystaniu zasobów wewnętrznych. Najlepsze praktyki zakładają żeby zrobić wszystko co możliwe w beta testach przeprowadzanych na małą skalę. Redukuje to kosztowne zewnętrzne Beta testy.

Testy automatyczne

Głównym celem automatyzacji testów jest ograniczanie ilości pracy wykonywanej manualnie przy wykonywaniu testów oraz uzyskanie lepszego pokrycia poprzez zwiększenie ilości przypadków testowych. Automatyzacja wpływa zarówno na używane narzędzia jak i na sam wygląd testów. Integralną właściwością środowiska testowego musi być możliwość przewidzenia właściwej odpowiedzi i porównania jej z odpowiedzią systemu na aktualne operacje na podstawie logów i innych informacji diagnostycznych. Praktyka wykorzystywania automatyzacji w testowaniu jest dobrze znana i rozumiana w pewnych obszarach testowania software a w innych nie. Najlepsza praktyka zakłada, że należy rozważyć co jest wiadome o systemie i opracować metody w obszarach gdzie automatyzacja nie została w pełni wykorzystana.

Buildy nocne

Koncepcja buildów nocnych znana jest już od bardzo długiego czasu. W przypadku gdy planowe biuldy nie są dokonywane codziennie, koncepcja ta zakłada tworzenie dodatkowych buildów ze zmian które zostały umieszczone w systemie utrzymania wersji. Korzyścią jest szybkie wyłapywanie błędów, dla błedów które zostały wprowadzone niedawno. Druga korzyść wynika z tego, że testy regresyjne mogą być wykonywane w tle. Trzecia korzyścią jest wcześniejsze dostarczenie software programistom i testerom.

Część dalsza nastąpi…

Autor: Radosław Mielczarek