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.

Kowal bezskrzydły. Foto: moje, 2016

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

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 – rodzaje testów

Jakie są rodzaje testów? Czym się różnią testy dymne od testów jednostkowych? Myślę, że jest to wiedza, którą obowiązkowo trzeba mieć, jeśli myśli się o przystąpieniu do egzaminu ISTQB i pracy jako tester.

rodzaje testów w pajęczej sieci

Krzyżak ogrodowy. Foto: moje, 2017

Różne rodzaje testów

  • Testy funkcjonalne – black-box, bez spoglądania w kod, testowanie pod kątem wymagań funkcjonalnych.
    • Testy dymne (smoke test) – najbardziej podstawowe, ogólne testy – czy program się w ogóle instaluje, uruchamia, pokrywają sprawdzenie podstawowych funkcjonalności.
    • Testy regresji – sprawdzają, czy nowo dodane funkcjonalności lub poprawki błędów nie wprowadzają nowych defektów. Idealne pole do automatyzacji.
    • Testy jednostkowe (modułowe, unit tests) – testowanie najniższych jednostek (funkcji) w izolacji od reszty systemu.
    • Testy integracyjne – po złożeniu systemu w całość. Szukanie błędów głównie w interfejsach i interakcjach pomiędzy modułami.
    • Testy systemowe – black-box, testowanie pod kątem spełniania wymagań ze specyfikacji, testowanie systemu złożonego w całość.
    • Testy akceptacyjne – wykonuje klient (lub beta tester po stronie klienta), testowanie pod kątem z wymaganiami klienta.
  • Testy strukturalne – white-box, przejście przez każdą ścieżkę.
  • Testy niefunkcjonalne
    • Testy obciążeniowe (load tests)
    • Testy ergonomii
    • Testy bezpieczeństwa

Podział ze względu na sposób wykonywania testów:

Czytaj dalej

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).