Nie będzie chyba zaskoczeniem, jeśli powiemy, że jakość rozwiązań IT w dużej mierze zależy od jakości testów, które te rozwiązania przeszły. Ponieważ testy odgrywają bardzo ważną rolę w naszym procesie wytwarzania i dostarczania oprogramowania, postanowiliśmy przekazać kilka dobrych praktyk testowania zaczerpniętych z naszej działalności związanej z rozwiązaniami opartymi na GE Smallworld GIS. Dodatkowo pokazujemy, jak proces testowania wygląda w Globemie.
Zacznijmy od porad związanych z testowaniem aplikacji GE Smallworld GIS:
- pamiętaj, aby skopiować środowisko produkcyjne razem z bazą danych i z niego utworzyć osobne środowisko testowe
- nie testuj na serwerze, gdzie jest zainstalowane środowisko, ale uruchamiaj aplikację na stacjach roboczych po zmapowanym udziale
- nie zapominaj o przebudowywaniu obrazów, aby być pewnym, że wszystkie poprawki są załadowane
- uruchamiaj aplikację z konsolą emacs. Z tej konsoli jesteś w stanie wyczytać podstawowe informacje na temat napotkanego błędu oraz skopiować jego treść
- przygotuj różne grupy z użytkownikami i odpowiednio skonfiguruj poziomy dostępu
- przygotuj odpowiedni pakiet testaliów, na których będziesz wykonywał niektóre testy, na przykład: pliki wektorowe i rastrowe w różnych formatach i w różnych układach współrzędnych, dokumenty dołączane do obiektów itp.
- testuj w odpowiednich alternatywach w bankach ACE, STYLE, GIS itp.
- patche z poprawkami wgrywaj do ustalonej lokalizacji, na przykład dla EC.GIS …\SW_APP\EC\…….\source\image_patches a numery patchy w sposób chronologiczny i bez przerw wpisuj do patchlisty
- wygląd edytorów w aplikacji może się różnić w zależności od tego, jak są skonfigurowane pliki xml odpowiadające za ich budowę. Należy pamiętać, że na poziomie struktury katalogów … \SW_APP są 2-3 różne konfiguracje, które hierarchicznie się nadpisują.
Dodatkowo warto napisać testy dla:
- różnych środowisk Smallworld – na przykład jednomonitorowe, dwumonitorowe itp.
- dla różnych użytkowników, z różnym poziomem dostępu do: tabel, parametrów i alternatyw
- testów regresji – błędy znalezione wcześniej i poprawione powinny być ponownie przetestowane wraz z obszarem funkcjonalnym wokół poprawionego błędu
- dla różnych typów testów: wydajności, skalowalności, bezpieczeństwa, użyteczności, procedur utrzymaniowych, funkcjonalnych.
A jak testowanie wygląda u nas?
Przede wszystkim bazujemy na podejściu iteracyjnym z zastosowaniem metodyk zwinnych, jak na przykład Scrum. Iteracyjny model tworzenia oprogramowania pozwala już na wczesnym etapie na współpracę programistów, testerów, analityka i klienta.
Podejście takie umożliwia:
- walidację sporządzonych wymagań z potrzebami klienta
- elastyczne reagowanie na ewentualne zmiany w wymaganiach. Wczesne wykrywanie niezgodności pomiędzy wymaganiami, wynikami projektowania i wynikami implementacji
- wykrywanie i neutralizowanie największych zagrożeń podczas początkowych operacji scalania – testowanie integracyjne małe
- minimalizację liczby poprawek – każda iteracja kończy się scalaniem
- obiektywną ocenę stanu projektu i jakości usługi
- sam proces wytwórczy jest ulepszany podczas trwania projektu – retrospekcja dokonywana na koniec każdej iteracji obejmuje również to, co można poprawić w następnej.
Defekty oprogramowania nie wynikają jedynie z błędów samego kodowania – duża ich część jest wynikiem błędów popełnionych podczas spisywania wymagań. Dlatego też testy zaczynamy już na etapie analizy:
- przeprowadzamy walidację wymagań (m.in. wymagania mają być: wykonalne, jednoznaczne, mierzalne, jednostkowe, zgodne ze sobą, zrozumiałe)
- nadajemy wymaganiom priorytety
- definiujemy ryzyka projektowe i produktowe
- znając cel projektu i wymagania układamy Strategię testową.
Warto także zaznaczyć, że aby zapewnić wysoką jakość oprogramowania, w procesie testowania biorą udział głównie osoby posiadające certyfikat ISTQB, ITIL oraz REQB.
Podkreślmy na koniec, iż testowanie jest absolutnie niezbędnym elementem wytwarzania i dostarczania oprogramowania. Powodów jest wiele, między innymi:
