Testowanie oprogramowania
Testy manualne, automatyczne
Testy automatyczne i manualne
Testowanie jest skoncentrowane na konkretnych celach testowych, które można podzielić na testowanie funkcjonalne, testowanie parametrów niefunkcjonalnych jakości, takich jak: wiarygodność lub używalność, struktura lub architektura oprogramowania/systemu albo powiązane ze zmianami, np. testy potwierdzające oraz testy regresji.
Zapewnienie sprawnie działającego oprogramowania jest dla nas najwyższym priorytetem - dlatego też nasi testerzy dbają o to, aby oddana dla klienta aplikacja miała najwyższą jakość i odpowiadała jego wymaganiom.
Jakość oprogramowania dla naszych testerów to:
- funkcjonalność (zaspokajanie potrzeb klienta),
- niezawodność systemu/aplikacji,
- wydajność,
- ergonomia i łatwość obsługi systemu/aplikacji (tzw. usability),
- podatność na rozwój.
Nasze testy są przeprowadzane według upublicznionych standardów:
- IEEE 829-1998 (IEEE Standard for Software Test Documentation),
- IEEE 1012-2012 (IEEE Standard for System and Software Verification and Validation).
Typy testów
Testy funkcjonalne (czarnej skrzynki, ang. black box) - testy te skupiają się przede wszystkim na weryfikacji założeń funkcjonalnych (wymagań zamieszczonych w dokumentacji) bez odniesienia się do kodu aplikacji. Techniki czarnej skrzynki pozwalają na wykrycie błędów związanych np. z brakiem implementacji funkcjonalności, jednakże nie pozwala precyzyjnie określić miejsca, w którym dany błąd występuje. Testy funkcjonalne odpowiadają na pytania, jak system wykonuje dane funkcje, włączając w to komendy użytkownika, operacje na danych, ekrany użytkownika, jakie wpływ na system ma aktualizacja środowiska.
Testy strukturalne (białej skrzynki, ang. white box) - testy te mają na celu ustalenie charakterystyki oprogramowania, czyli zachowania systemu w określonych warunkach. W skład podstawowych testów strukturalnych wchodzą:
- testy wydajnościowe - badanie dające odpowiedź na to, czy system działa stabilnie przy założonej maksymalnej liczbie użytkowników, czy czasy odpowiedzi są
- akceptowalne dla normalnego trybu pracy i nie przekraczają limitu czasu pracy operacji,
- testy obciążeniowe - polegają na symulacji obciążenia systemu dużą - praktycznie maksymalną - liczbą użytkowników przez określony zakres czasu przy realizacji wybranego scenariusza testów np. realizowania w tym samym momencie transakcji płatniczej,
- testy bezpieczeństwa - mające na celu weryfikację i ustalenie odporności systemu na niepożądane, ale zamierzone działania np. ingerencja w dane (modyfikacja, usunięcie), destabilizacja lub unieruchomienie systemu, uzyskanie poufnych informacji itp.).
Testy potwierdzające - wykonywane są w momencie naprawienia wcześniej znalezionego defektu w systemie/aplikacji - ponowne przetestowanie pozwoli na potwierdzenie stabilności działania systemu/aplikacji.
Testy regresji - są powtarzalnymi testami na już przetestowanym programie, po modyfikacjach, w celu wykrycia innych błędów wprowadzonych lub nie odkrytych podczas naprawy poprzednich defektów przez programistów. Jednak głównym zadaniem tych testów jest ocena ryzyka a nie znalezienia defektów w oprogramowaniu, które poprzednio działało. Testy regresyjne mogą zostać wykonane na wszystkich poziomach testowych i zajmują się funkcjonalnością, zdolnościami niefunkcjonalnymi i testowaniem strukturalnym.
Projektowanie testów
Pierwszym etapem przy projektowaniu testów, jak już wcześniej wspomnieliśmy, jest zidentyfikowanie warunków testowanego systemu/aplikacji. Proces ten obejmuje przede wszystkim określenie tego, co testujemy i czego potrzebujemy do zrealizowania testów. Na podstawie odpowiedzi na wyżej wymienione pytania punktujemy istotne założenia wstępne, które pozwolą określić jakie problemy natury technicznej mogą nam sprawić kłopoty oraz jak otrzymane zasoby odpowiadają potrzebom projektu testowego.
Drugim etapem jest określenie specyfikacji przypadków testowych. Specyfikacja ta uwzględnia dane wejściowe, warunki początkowe, oczekiwany rezultat oraz technikę wraz z narzędziami, jakimi wykonujemy testy. Po zdefiniowaniu celu oraz opisujemy sekwencję zdarzeń w scenariuszu testowym dotyczącym danego przypadku.
Trzecim i ostatnim etapem jest ustalenie kolejności wykonywania przypadków testowych. Jest to najważniejszy aspekt wykonywania testów. Nasi testerzy grupują przypadki testowe w taki sposób, aby obejmowały te same obszary systemu/aplikacji i były konsekwentnie ułożone w logiczną całość. Realizowanie testów w sposób przypadkowy może przedłużyć wykonywanie testów lub rezultat tych testów nie będzie odpowiadał stanowi faktycznemu.
Scenariusze testowe
Scenariusze testowe swoją formą przypominają rozpisane do postaci scenariuszy przypadki użycia aplikacji. Zazwyczaj nasi testerzy rozpisują scenariusze przed wdrożeniem - co stanowi element dokumentacji. Czasami zdarza się, że scenariusze pisane są przy samym końcu wdrożenia, wtedy są one opisywane na bazie powstałego już systemu.
Scenariusze zwykle są bardziej szczegółowe od przypadków użycia systemu/aplikacji, ponieważ ich zadaniem jest przygotowanie do weryfikacji wszystkich dostępnych funkcji. Dodatkowo scenariusze powinny zawierać różne przypadki dostępu do funkcji i nawigacji.
Nasze scenariusze testowe składają się z następujących elementów:
- scenariusz dotyczy - odniesienie do przypadku użycia zaprojektowanego w czasie analizy. Dzięki temu wiemy dokładniej, czego dotyczy dany scenariusz testowy i zawsze jest możliwość odniesienia się do dokumentacji analitycznej,
- scenariusz (kroki testowe) - jest to najważniejszy element scenariusza. Opisuje dokładne kroki, jakie powinien wykonać użytkownik, aby uzyskać odpowiednią odpowiedź systemu.
- ocena testu - pole do wypełnienia przez testera po wykonaniu danego testu. Opisuje, czy dana funkcjonalność działa poprawnie, czy też nie.
