Archiwa tagu: testy

Jak zacząć z testowaniem – artykuł od Girls Who Test

Ilekroć zabieram się za wpis dla początkujących testerów opisujący jak zacząć z testowaniem, natrafiam w sieci na artykuł, który już temat opisuje! Jeszcze nie tak dawno w sieci mało można było znaleźć materiałów na ten temat, a teraz – proszę. Nic tylko czytać! 🙂

Tym razem w oko wpadła mi broszurka przygotowana przez Aleksandrę Kornecką z Girls Who Test.

Jak zacząć z testowaniem - artykuł od Girls who test

Dokument do przeczytania tutaj: https://docs.google.com/document/d/1e9IVt5x_W8FW24R-7BaQh3xf3jShHfJGzMEjm0E1sWg, a w nim:

  • co to jest oprogramowanie i co oznacza termin „testowanie oprogramowania”
  • kompetencje miękkie u testera
  • obowiązki testera
  • ścieżki rozwoju
  • skąd czerpać wiedzę
  • i inne.

Jeśli chodzi natomiast o same Girls Who Test, polecam śledzić ich stronę: http://www.girlswhotest.pl/events/, większość wydarzeń organizują w Warszawie lub Poznaniu. Dziewczyny, trzymam kciuki! 🙂

Kiedy skończyć testowanie

Testowanie oprogramowania to proces teoretycznie nieskończony. Zawsze można znaleźć warunki lub ścieżki, które nie zostały jeszcze sprawdzone.

W warunkach biznesowych proces testowania jest jednak ograniczony (czasem, budżetem, możliwościami). Często pojawia się pytanie: kiedy można zakończyć testowanie, uznając że produkt jest dostatecznie dobrze sprawdzony?

Odpowiedź nie jest jednoznaczna – zakończenie testów jest umowne i zależy od spełnienia jakiegoś warunku:

  • Budżet – kwestia dość prosta.
  • Czas – może produkt „pudełkowy” ze sztywną datą wydania, może wytwarzany w modelu kaskadowym (a może w Scrumie), może trzeba gonić konkurencję, a może po prostu osoba decyzyjna stwierdza, że czas na testy ubiegł – kończymy.
  • Metryki. Tu zaczyna się robić ciekawie, o czym w dalszej części wpisu.

Ciekawy materiał na ten temat od IBM:
[ftp://public.dhe.ibm.com] – kopia [IBM_Kiedy_mozna_zakonczyc_testowanie].

Metryki są pewnym założeniem i są to wartości dość względne. Mogą zostać ustalone na początku testowania. Niektóre z nich to np.:

  • Wykonanie założonego procentu przypadków testowych zakończyło się sukcesem (nie zostały wykryte błędy).
  • Ilość wykrytych błędów (lub krzywa wykrywanych błędów) spadła poniżej założonego progu.
  • Pokrycie funkcjonalności testami (manualnymi, automatycznymi) osiągnęło założony zakres, np.:
    • przetestowano ręcznie najważniejszą ścieżkę,
    • pokrycie testami jednostkowymi na poziomie 90%.

Asert w NUnit

Jednym z bardziej elementarnych składników testów są asercje, umożliwiające sprawdzenie, czy spełnione są warunki testu.

W NUnicie dostępnych jest wiele różnych asercji. Najprostsza to:

Assert.AreEqual

To jednak nie wszystko. NUnit oferuje cały wachlarz asercji – warto spojrzeć w dokumentację [equalConstraint][assertions].

Bardzo fajną opcją jest na przykład sprawdzenie, czy kolekcja jest posortowana:

var notSorted = new List<decimal>();

notSorted.Add(12.3);

notSorted.Add(5.5);

notSorted.Add(100);

Assert.That(notSorted, Is.Ordered);//Fail

Poza klasycznymi asercjami NUnit oferuje też np. StringAsert, CollectionAsert itd.

Testowanie – notatki

Pod rękę nawinęła mi się kartka z notatkami – bodajże do egzaminu ISTQB.

Negative testing scenarios – przykładowe:

  • testowanie błędnymi wartościami
  • niewypełnienie pól wymaganych
  • niepoprawny typ danych
  • więcej/mniej znaków niż wymagane
  • większy/mniejszy zakres danych, niż spodziewa się program
  • testy z manipulowaniem sesją w przeglądarce
  • zduplikowanie wartości, pól, brak pól (np. w webservisie)

Testowanie mutacyjne – sprawdzanie, na ile testy jednostkowe rzeczywiście sprawdzają kod. Automatyczne wprowadzanie losowych błędów w programie (posiewanie błędów) i uruchamianie testów jednostkowych, by sprawdzić, czy wykryły one wprowadzone błędy. Wymaga dużej mocy obliczeniowej.

Fuzz testing – wprowadzenie niepoprawnych, nieoczekiwanych, losowych danych, obserwacja i czekanie na awarię. Ma dwa rodzaje: fuzzing mutacyjny lub generacyjny. Tego typu testy mogą być wykonane na wielu poziomach, np. niskopoziomowe – na etapie np. mieszania w pamięci dzielonej lub nieco wyższe – na etapie danych wejściowych do komponentów programu.

Recenzja – Dane testowe. Teoria i praktyka

Tytuł książki „Dane testowe. Teoria i praktyka” autorstwa Radosława Smilgina i Anny Piaskowy (wydawnictwo Helion), bardzo dokładnie mówi, czego możemy się spodziewać po lekturze. Tak – w dużej mierze – danych testowych.

dane_testowe

W pierwszej części książki autorzy wprowadzają kilka znanych z egzaminu ISTQB technik testowania (klasy równoważności, wartości brzegowe itd.) oraz definiują, czym są dane testowe. Przydatna ściągawka dla osób początkujących. Czytaj dalej

Artykuł w PasjaOnline: Jak ugryźć testowanie oprogramowania

„Jak ugryźć testowanie oprogramowania” to jeden z moich artykułów w serwisie PasjaOnline. Stanowi wstęp do serii artykułów poświęconych testowaniu. Więcej na stronie:

http://pasjaonline.pl/jak-ugryzc-testowanie-oprogramowania/

PasjaOnline to dość młody serwis skupiający miłośników programowania (zwłaszcza aplikacji webowych).

 

RSpec – ciekawostki

RSpec: flaga fail_fast – uruchamia testy „do pierwszego faila”. Przerywa wykonywanie testów, jeżeli któryś test nie przejdzie (nawet jeśli mamy testy w wielu plikach, zachowują się jakby były scalone w jeden). https://www.relishapp.com/rspec/rspec-core/v/2-0/docs/configuration/fail-fast

Analogicznie do JUnitowego Ignore, w RSpec możemy pominąć niektóre testy. Zamiast it należy wstawić skip (w podsumowaniu test pojawi się jako pending).