Hejo,
Z racji, iż za niecały tydzień podchodzę do egzaminu na certyfikat ISTQB (International Software Testing Qualifications Board) FL chciałbym podzielić się odrobiną wiedzy. Nie będzie to wiedza podparta przykładamy czy też ćwiczeniami. Wynika to z faktu, iż FL opiera się przede wszystkim na przyswojeniu sylabusa oraz jego zrozumieniu.
Zacznę trochę nietypowo, ponieważ od rozdziału drugiego sylabusa. Uznałem, że rozdział pierwszy to podstawy podstaw i będzie mi szkoda czasu i miejsca, by się nad nim rozwodzić : )
Będę opisywać tutaj swoje przemyślenia oraz wiedzę, jaką przyswoiłem odpowiadając na to, co wg. sylabusa powinienem potrafić po zakończeniu danego modułu. Czyli taka wiedza w pigułce z każdego działu. Easy!
Zaczynajmy!
===============
Modele wytwarzania oprogramowania:
Kandydat potrafi wyjaśnić powiązania pomiędzy rozwojem oprogramowania, czynnościami testowymi oraz produktami w cyklu życia oprogramowania i podać przykłady na podstawie cech projektu i produktu oraz kontekstu.
Okay, kandydat potrafi. Kandydat przekaże.
Wyróżniamy wiele modeli powstawania oprogramowania, jednak ja skupię się na tych, które są w sylabusie:
- model V (inaczej model sekwencyjny) - jest najczęściej spotykany, co najważniejsze posiada cztery poziomy testowania odpowiadające czterem poziomom rozwoju software'u. Oczywiście istnieje wiele wariantów tego modelu, zapewne co projekt to każdy będzie się różnić szczegółami, niemniej założenie jest już nam znane.
Obraz pobrany z testerzy.pl
W sylabusie użyli przykładu z czterema poziomami testowania, a są to po kolei:
a) testy modułowe (jednostkowe),
b) testy integracyjne,
c) testy systemowe,
d) testy akceptacyjne.
Co ważne to to, że w porównaniu do innych modelu powstawania oprogramowania (np. waterfall'a), ten ma wyraźnie więcej plusów. Otóż testowanie oraz projektowanie/powstawanie software'u odbywa się w tym samym czasie, co pozwala szybciej zniwelować defekty, zaoszczędzić masę pieniędzy oraz co najważniejsze poprawiać jakość software'u na bieżąco.
Po więcej info zapraszam pod tym linkiem :)
- modele iteracyjno-przyrostowe - jest to proces zbierania wymagań, projektowania, budowania oraz testowania software'u w krótszych cyklach rozwojowych. System wyprodukowany wg. takiego modelu może być przetestowany na wielu poziomach w każdej iteracji. Przyrost, dodany do innych wytworzonych wcześniej staje się rosnącym systemem częściowym, który również powinien być przetestowany.
Schemat modelu przyrostowego w SLC (za http://www.fizyka.umk.pl/~grochu/wiki/doku.php?id=zajecia:ppz:cykl_zycia_oprogramowania)
===============
W każdym SLC 'dobre testowanie' charakteryzuje się kilkoma niezmiennymi cechami:
- dla każdej czynności związanej z powstawaniem software'u istnieją odpowiadające im czynności związane z testingiem,
- każdy z poziomów testowania ma zdefiniowane cele,
- analiza i projektowanie testów dla danego poziomu powinny rozpoczynać się już podczas odpowiadającej im fazie powstawania software'u,
- testerzy powinni uczestniczyć w przeglądach już od wczesnych wersji dokumentacji tworzonej podczas wytwarzania software'u,
Poziomy te mogą być oczywiście łączone lub organizowane na różne sposoby. Jest to zależne od projektu, architektury powstającego systemu etc.
Kandydat potrafi porównać różne poziomy testów: główne cele, typowe poziomy testów, typowe cele testowania (np. strukturalne bądź funkcjonalne) i związane z nimi produkty, testerów, typy usterek i awarii do znalezienia.
Okay, zacznijmy od tego, że dla każdego poziomu testowania można i trzeba zdefiniować ogólne cele, produkty, przypadki testowe, przedmiot testów, typowe defekty i awarie do wykrycia,, wymagania na jarzmo testowe oraz wsparcie narzędziowe, środowisko testowe.
Jeżeli chodzi o pojęcia, które mogę wyjaśnić i ciężko można się ich domyślić to:
* jarzmo testowe to nic innego jak zestaw zaślepek, sterowników, które będą potrzebne do wykonania określonych testów (np. kiedy jeden z modułów nie jest jeszcze gotowy).
* przypadek testowy to zbiór danych wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów i końcowych warunków wykonania opracowany w określonym celu lub dla warunku testowego, jak wykonanie pewnej ścieżki programu lub zweryfikowanie zgodności z konkretnym wymaganiem [IEEE 610] [Słownik wyrażeń związanych z testowaniem, wersja 2.0].
Tak, w tym przypadku posiłkowałem się słownikiem, dlatego, że uważam, iż najlepiej obejrzeć ten materiał (i w ogóle samo zobaczenie informacji zebranych w przypadek testowy wyjaśni nam więcej, niż jakakolwiek definicja):
* środowisko testowe to narzędzia dobrane w taki sposób podczas testowania, by jak najbardziej zbliżyć się do oprogramowania, na jakim będzie operować użytkownik końcowy.
O poziomach testów wspomnieliśmy wyżej, teraz pora je po kolei wyjaśnić:
TESTY MODUŁOWE (unit tests)
Stosujemy je wtedy, kiedy software jest podzielony na moduły, posiadamy projekt oraz jego specyfikację. Typowymi obiektami testów modułowych są moduły (tak, nie wpadłbyś na to, co nie?), programy, które służą do konwersji bądź migracji danych oraz moduły bazodanowe.
Testy modułowe polegają przede wszystkim na wyszukiwaniu błędów oraz weryfikacji funkcjonalności oprogramowania, które można testować oddzielnie. Takie testy mogą być wykonywane w izolacji od reszty systemu i w zależności od kontekstu SLC oraz samego systemu można tutaj stosować wspomniane wcześniej jarzmo testowe (np. sterownik, który będzie imitować brakujący moduł).
Testy modułowe mogą zawierać testy funkcjonalności software'u oraz niektórych atrybutów niefunkcjonalnych, takich jak stopień wykorzystania zasobów (np. wycieków pamięci), bądź też odporności danego software'u na obciążenie klientów docelowych.
Przypadki testowe projektowane są na podstawie specyfikacji danego podułu, projektu oprogramowania oraz modelu danych, z jakich software korzysta.
Charakterystyczne dla tych testów jest również to, że wykonuje się je posiadając dostęp do kodu źródłowego, przy wsparciu środowiska rozwojowego oraz często same testy angażują autora testowanego kodu, tak by same usterki mogły zostać usunięte zaraz po wykryciu.
Warto automatyzować testy modułowe. Podejście 'najpierw testuj' sprawdza się tutaj doskonale. Podejście to jest iteracyjne, opiera się na cyklach tworzenia przypadków testowych, a następnie na budowaniu i integracji niewielkich fragmentów kodu, i ponownego testowania.
Polecam poświęcić te 5 minut na obejrzenie materiału powyżej : ) Myślę, że jeszcze bardziej wyklaruje spojrzenie na ten poziom testów.
TESTY INTEGRACYJNE (integration tests)
Podstawy do wykonania testów pojawiają się wtedy, kiedy mamy zamiar przetestować implementację baz danych poszczególnych podsystemów, infrastrukturę software'u, interfejsy software'u, konfigurację systemu i dane konfiguracyjne. Testy te będą kłady mocny nacisk na projekt software'u, jego architekturę, przepływ procesów wykonywanych przez software.
Jednymi słowy testy integracyjne sprawdzają działanie interfejsów występujących pomiędzy modułami. Sprawdzają interakcje pomiędzy oraz z innymi częściami systemu (t.j. OS, system plików) oraz interfejsy pomiędzy systemami.
Co ważne to to, że testy integracyjne mogą być wykonywane na więcej niż jednym poziomie i dla przedmiotów testów o różnej wielkości. Np: testowanie integracji modułów sprawdza interakcje z innymi częściami systemu, testowanie integracji systemów sprawdza interakcje pomiędzy różnymi systemami lub pomiędzy sprzętem, a oprogramowaniem etc.
Im większy zakres integracji, tym trudniejsze może być określenie, jaki moduł lub system zawiera defekt. Systematyczne strategie integracji mogą bazować na architekturze systemu, zadaniach funkcjonalnych, sekwencjach przetwarzania transakcji albo na innym aspekcie systemu lub modułu.
Żeby ułatwić namierzenie usterek oraz ich wczesne wykrywanie w normalnych warunkach integracja powinna być raczej prowadzona metodą inkrementalną, niż metodą 'big bangu'.
Podczas testów integracyjnych można wykonać testy niektórych atrybutów niefunkcjonalnych (np. wydajności systemu) na równi z testami funkcjonalnymi.
W wypadku testów integracyjnych osoba testująca powinna rozumieć architekturę oprogramowania oraz mieć wpływ na planowanie integracji.
TESTY SYSTEMOWE (system tests)
Obiektami testów systemowych są.. uwaga.. podręczniki systemowe (nie zazdroszczę), użytkownika oraz operacyjne, jak i konfiguracje systemu oraz same dane konfiguracyjne. Podstawą to testowania systemowego są, jak możemy się domyślać wymagania software'u na OS oraz oprogramowanie, przypadki użycia software'u, jak i raport z analizy ryzyka.
Jednym słowem testy systemowe zajmują się zachowaniem systemu/produktu i czy jest ono zgodne ze specyfikacją końcową klienta. Same testy mogą być opare na ryzyku lub wymaganiach, procesie biznesowym, przypadkach użycia software'u etc. Testy te powinny sprawdzać funkcjonalne, jak i niefunkcjonalne wymagania na system oraz jakość danych. Tester w tym przypadku musi umieć poradzić sobie z wymaganiami niekompletnymi lub też nieudokumentowanymi. Testowanie systemu wymagań funkcjonalnych startuje poprzez użycie technik opartych na specyfikacji (czarnoskrzynkowe) dla testowanego aspektu systemu. Można również użyć technik opartych na strukturze (białoskrzynkowe) do oceny dokładniości testowania w odniesieniu do elementów struktury, takich jak menu, czy nawigacja po stronach www.
Takie testy wykonywane są przez niezależny zespół testowy.
TESTY AKCEPTACYJNE
Obiektami testów akceptacyjnych są proces biznesowy (już na w pełni zintegrowanym systemie), procesy utrzymania oraz obsługi systemu, formularze, raporty czy dane konfiguracyjne. Podstawą do testów będą przede wszystkim wymagania systemowe, wymagania użytkownika software'u, przypadki użycia software'u, raporty z analizy ryzka.
Odpowiedzialność za testy akceptacyjne leży często po stronie klientów lub użytkowników systemu.
Celem testów akceptacyjnych jest nabranie zaufania do systemu, jego części bądź pewnych atrybutów niefunkcjonalnych (np. szybkość przekazywania procesów etc). Testy akceptacyjne mają za zadanie ocenić gotowość systemu do wdrożenia oraz użycia, chociaż nie muszą być ostatnim etapem testowania - testy akceptacyjne mogą pojawić się w wielu momentach SLC.
Typowymi formami testów akceptacyjnych są: testy akceptacyjne przez użytkownika, testy produkcyjne, akceptacja systemów przez adminów (testowanie kopii zapasowych, uruchamiania systemu po awarii, ładowanie danych i zadania związane z migracją etc.).
Testy ALFA wykonywane są u producenta ale nie przez zespół projektowy. Mają za zadanie uzyskanie opinii potencjalnych lub obecnych klientów nt. systemu przed wypuszczeniem go do sprzedaży. Testy BETA (testy polowe) wykonywane są przez klientów.
================
Kandydat potrafi porównać podając przykłady cztery typy testów (funkcjonalne, niefunkcjonalne, strukturalne oraz związane ze zmianami).
Skoro mamy typy testów to logicznym jest, że każdy z nich skupia się na określonym celu. Takie cele to np. przetestowanie jakiegoś niefunkcjonalnego atrybutu jakościowego, przetestowanie struktury czy architektury systemu, przetestowanie zmian zachodzących w oprogramowaniu etc.
Oczywiście można opracować swój własny model oprogramowania i użyć go w testach różnego typu:) My skupimy się na podstawowych czterech typach testów :)
Testowanie funkcji (testowanie funkcjonalne)
Funkcje, jakie ma pełnić dany system, moduł, podsystem etc. opisane są w specyfikacji. Warto jednak zwrócić uwagę na to, że nie zawsze specyfikacja jest dostępna dla testerów. W skrócie testy funkcjonalne mają za zadanie sprawdzić 'co system właściwie robi'.
Testy funkcjonalne dotyczą funkcji lub innych cech systemu oraz ich współdziałania z innymi systemami. Można je wykonywać na wszelkich poziomach.
Do tworzenia warunków testowych oraz przypadków testowych dla funkcjonalności systemu mogą zostać użyte techniki oparte na specyfikacji (czarnoskrzynkowe) - testy funkcjonalne zajmują się zewnętrznym zachowaniem oprogramowania.
Testowanie zabezpieczeń np. sprawdza funkcje pozwalające na wykrycie zagrożeń (np. wirusy). Inne typy testów funkcjonalnych to: testowanie współdziałania, ocenia zdolność software'u do współpracy z jednym lub większą liczbą wskazanych modułów bądź systemów.
Myślę, że najlepszy sens testów odda definicja via wiki: "Testy funkcjonalne znane są także jako testy czarnej skrzynki, ponieważ osoba testująca nie ma dostępu do informacji na temat budowy programu, który testuje. Często testy takie są wykonywane przez osoby inne niż programiści tworzący program".
Testowanie atrybutów niefunkcjonalnych (testowanie niefunkcjonalne)
Obejmuje ono następujące typy testów: wydajnościowe, obciążeniowe, przeciążeniowe, użyteczności, pielęgnowalności, niezawodności, przenaszalności. Testowanie te w przeciwieństwie do funkcjonalnego polega na tym, aby sprawdzić jak właściwie dany system działa.
Testowanie niefunkcjonalne może być wykonywane na wszystkich poziomach testów. Termin tych testów oznacza testy wymagane do zmierzenia właściwości systemów i oprogramowania, które mogą zostać określone ilościowo na zmiennej skali, takich jak czasy odpowiedzi w testach wydajnościowych.
Testowanie struktury/architektury oprogramowania (testowanie strukturalne)
Moje ulubione. Testy strukturalne w przeciwieństwie do testów funkcjonalnych opierają się na wiedzy testera na temat testowanego systemu. Testy takie, oparte na strukturze systemu, oprogramowania nazywamy białoskrzynkowymi. Można je wykonywać na każdym poziomie testowania, najlepiej jednak użyć je po testach opartych na funkcji danego systemu (opartych na specyfikacji), po to, by zmierzyć dokładność testowania przez ocenę stopnia pokrycia wybranego typu struktury.
Pokrycie to nic innego, jak opis stopnia przetestowania odeska pokrytych elementów. Tj. jeżeli pokrycie struktury kodu źródłowego programu będzie niższe, niż sto%, można wtedy zaprojektować więcej testów, by przetestować elementy, które zostały pominięte.
Do pomiaru pokrycia (np. decyzji lub instrukcji) na wszystkich poziomach, a szczególnie na poziomie testów modułowych i testów integracji modułów mogą zostać użyte narzędzia. Testowanie strukturalne może zostać oparte na architekturze systemu :)
Testowanie związane ze zmianami: testowanie potwierdzające oraz regresywne
Po wykryciu i naprawieniu defektu przez programistę powinien zostać wykonany retest po to, by potwierdzi usunięcie usterki. To właśnie testy potwierdzające. Debagowanie (lokalizacja oraz poprawienie usterek) jest czynnością programistyczną, a nie testową.
Testowanie regresywne zaś to powtórzenie testów na już wcześniej przetestowanym systemie, oprogramowaniu wykonywane po modyfikacjach tylko po to, żeby stwierdzić, czy przy aktualizacji, usunięciu usterek nie powstały nowe defekty na skutek tych zmian. Testy regresywne wykonuje się po wszystkich zmianach w oprogramowaniu, a także po zmianach w jego środowisku.
Obydwa wyżej wymienione testy muszą być powtarzalne.
Testy regresywne można wykonać na wszystkich poziomach testów i dla wszystkich typów testów. :)
Kandydat potrafi porównać testy pielęgnacyjne (testowanie istniejącego systemu) do testowania nowej aplikacji uwzględniając typy testów, powody rozpoczęcia testowania oraz ilość testów. Potrafi również wymienić powody wykonywania testów pielęgnacyjnych (zmiany, migracja, cofnięcie systemu - odp. w pytaniu) oraz opisać rolę testów regresywnych i analizy wpływu w utrzymaniu.
Wiadomym jest, że wdrożony system musi działać przez lata. W tym czasie system, jego dane konfiguracyjne, czy środowisko są często poprawiane, zmieniane i rozszerzane (zmiana IDE, nowe dane w BZ etc.). Dla dobrego testowania pielęgnacyjnego krytyczne jest planowanie wydań z wyprzedzeniem. Konieczne jest również rozróżnianie pomiędzy planowanymi wydaniami oraz szybkimi poprawkami. Testowanie pielęgnacyjne wykonuje się na działającym systemie na skutek modyfikacji, migracji lub złomowania oprogramowania bądź systemu.
Takimi modyfikacjami mogą być planowane ulepszenia, poprawki, naprawy awaryjne, zmiany IDE etc.
Testy pielęgnacyjne migracji oprogramowania (np. pomiędzy platformami) powinny prócz testów zmian w oprogramowaniu uwzględniać również testy produkcyjne nowego IDE. Testy te są również potrzebne, gdy dane z innej aplikacji są migrowane do utrzymywanego systemu.
Testy pielęgnacyjne związane z wycofywaniem oprogramowania mogą zawierać testy migracji lub archiwizacji danych, jeżeli wymagany jest długi okres ich przetrzymywani :)
Testy pielęgnacyjne prócz przetestowania tego, co zostało zmienione zawierają również testy regresywne tych części systemu, które się nie zmieniły. Zakres testów pielęgnacyjnych zależy od ryzyka zmian, wielkości istniejącego systemu oraz zakresu tych zmian. W zależności od tych zmian testowanie pielęgnacyjne może być wykonywane na różnych poziomach testów lub na wszystkich oraz dla wybranych lub wszystkich typów testów.
Analiza wpływu to określenie, jaki wpływ na istniejący system mogą mieć zmiany. Stosuje się ją, aby ustalić zakres testów regresywnych :) (cięcie kosztów, ekonomia). Może i jest często używana do wybierania zestawu testów regresywnych.
Warto pamiętać, iż testowanie pielęgnacyjne jest trudne do wykonania, jeśli specyfikacja oprogramowania jest przestarzała lub jest jej brak.
=====================
Na tym zakończymy pierwszą część. Jest ona oparta w dużej mierze na sylabusie ISTQB rozdział 2 ale z moimi uwagami i trochę rozszerzonym materiałem. Nie rozwodziłem się nad pierwszym rozdziałem, bo wg. mnie nie ma w nim zbyt wielu konkretów, a sam jest przedstawiony w całości w serii kursów na YT, gdzie sam film znajdziecie poniżej tego zdania. Czekajcie na kolejne części pewnie już jutro.
Trzymajcie się,
F.
W każdym SLC 'dobre testowanie' charakteryzuje się kilkoma niezmiennymi cechami:
- dla każdej czynności związanej z powstawaniem software'u istnieją odpowiadające im czynności związane z testingiem,
- każdy z poziomów testowania ma zdefiniowane cele,
- analiza i projektowanie testów dla danego poziomu powinny rozpoczynać się już podczas odpowiadającej im fazie powstawania software'u,
- testerzy powinni uczestniczyć w przeglądach już od wczesnych wersji dokumentacji tworzonej podczas wytwarzania software'u,
Poziomy te mogą być oczywiście łączone lub organizowane na różne sposoby. Jest to zależne od projektu, architektury powstającego systemu etc.
Kandydat potrafi porównać różne poziomy testów: główne cele, typowe poziomy testów, typowe cele testowania (np. strukturalne bądź funkcjonalne) i związane z nimi produkty, testerów, typy usterek i awarii do znalezienia.
Okay, zacznijmy od tego, że dla każdego poziomu testowania można i trzeba zdefiniować ogólne cele, produkty, przypadki testowe, przedmiot testów, typowe defekty i awarie do wykrycia,, wymagania na jarzmo testowe oraz wsparcie narzędziowe, środowisko testowe.
Jeżeli chodzi o pojęcia, które mogę wyjaśnić i ciężko można się ich domyślić to:
* jarzmo testowe to nic innego jak zestaw zaślepek, sterowników, które będą potrzebne do wykonania określonych testów (np. kiedy jeden z modułów nie jest jeszcze gotowy).
* przypadek testowy to zbiór danych wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów i końcowych warunków wykonania opracowany w określonym celu lub dla warunku testowego, jak wykonanie pewnej ścieżki programu lub zweryfikowanie zgodności z konkretnym wymaganiem [IEEE 610] [Słownik wyrażeń związanych z testowaniem, wersja 2.0].
Tak, w tym przypadku posiłkowałem się słownikiem, dlatego, że uważam, iż najlepiej obejrzeć ten materiał (i w ogóle samo zobaczenie informacji zebranych w przypadek testowy wyjaśni nam więcej, niż jakakolwiek definicja):
* środowisko testowe to narzędzia dobrane w taki sposób podczas testowania, by jak najbardziej zbliżyć się do oprogramowania, na jakim będzie operować użytkownik końcowy.
O poziomach testów wspomnieliśmy wyżej, teraz pora je po kolei wyjaśnić:
TESTY MODUŁOWE (unit tests)
Stosujemy je wtedy, kiedy software jest podzielony na moduły, posiadamy projekt oraz jego specyfikację. Typowymi obiektami testów modułowych są moduły (tak, nie wpadłbyś na to, co nie?), programy, które służą do konwersji bądź migracji danych oraz moduły bazodanowe.
Testy modułowe polegają przede wszystkim na wyszukiwaniu błędów oraz weryfikacji funkcjonalności oprogramowania, które można testować oddzielnie. Takie testy mogą być wykonywane w izolacji od reszty systemu i w zależności od kontekstu SLC oraz samego systemu można tutaj stosować wspomniane wcześniej jarzmo testowe (np. sterownik, który będzie imitować brakujący moduł).
Testy modułowe mogą zawierać testy funkcjonalności software'u oraz niektórych atrybutów niefunkcjonalnych, takich jak stopień wykorzystania zasobów (np. wycieków pamięci), bądź też odporności danego software'u na obciążenie klientów docelowych.
Przypadki testowe projektowane są na podstawie specyfikacji danego podułu, projektu oprogramowania oraz modelu danych, z jakich software korzysta.
Charakterystyczne dla tych testów jest również to, że wykonuje się je posiadając dostęp do kodu źródłowego, przy wsparciu środowiska rozwojowego oraz często same testy angażują autora testowanego kodu, tak by same usterki mogły zostać usunięte zaraz po wykryciu.
Warto automatyzować testy modułowe. Podejście 'najpierw testuj' sprawdza się tutaj doskonale. Podejście to jest iteracyjne, opiera się na cyklach tworzenia przypadków testowych, a następnie na budowaniu i integracji niewielkich fragmentów kodu, i ponownego testowania.
Polecam poświęcić te 5 minut na obejrzenie materiału powyżej : ) Myślę, że jeszcze bardziej wyklaruje spojrzenie na ten poziom testów.
TESTY INTEGRACYJNE (integration tests)
Podstawy do wykonania testów pojawiają się wtedy, kiedy mamy zamiar przetestować implementację baz danych poszczególnych podsystemów, infrastrukturę software'u, interfejsy software'u, konfigurację systemu i dane konfiguracyjne. Testy te będą kłady mocny nacisk na projekt software'u, jego architekturę, przepływ procesów wykonywanych przez software.
Jednymi słowy testy integracyjne sprawdzają działanie interfejsów występujących pomiędzy modułami. Sprawdzają interakcje pomiędzy oraz z innymi częściami systemu (t.j. OS, system plików) oraz interfejsy pomiędzy systemami.
Co ważne to to, że testy integracyjne mogą być wykonywane na więcej niż jednym poziomie i dla przedmiotów testów o różnej wielkości. Np: testowanie integracji modułów sprawdza interakcje z innymi częściami systemu, testowanie integracji systemów sprawdza interakcje pomiędzy różnymi systemami lub pomiędzy sprzętem, a oprogramowaniem etc.
Im większy zakres integracji, tym trudniejsze może być określenie, jaki moduł lub system zawiera defekt. Systematyczne strategie integracji mogą bazować na architekturze systemu, zadaniach funkcjonalnych, sekwencjach przetwarzania transakcji albo na innym aspekcie systemu lub modułu.
Żeby ułatwić namierzenie usterek oraz ich wczesne wykrywanie w normalnych warunkach integracja powinna być raczej prowadzona metodą inkrementalną, niż metodą 'big bangu'.
Podczas testów integracyjnych można wykonać testy niektórych atrybutów niefunkcjonalnych (np. wydajności systemu) na równi z testami funkcjonalnymi.
W wypadku testów integracyjnych osoba testująca powinna rozumieć architekturę oprogramowania oraz mieć wpływ na planowanie integracji.
via. guru99
TESTY SYSTEMOWE (system tests)
Obiektami testów systemowych są.. uwaga.. podręczniki systemowe (nie zazdroszczę), użytkownika oraz operacyjne, jak i konfiguracje systemu oraz same dane konfiguracyjne. Podstawą to testowania systemowego są, jak możemy się domyślać wymagania software'u na OS oraz oprogramowanie, przypadki użycia software'u, jak i raport z analizy ryzyka.
Jednym słowem testy systemowe zajmują się zachowaniem systemu/produktu i czy jest ono zgodne ze specyfikacją końcową klienta. Same testy mogą być opare na ryzyku lub wymaganiach, procesie biznesowym, przypadkach użycia software'u etc. Testy te powinny sprawdzać funkcjonalne, jak i niefunkcjonalne wymagania na system oraz jakość danych. Tester w tym przypadku musi umieć poradzić sobie z wymaganiami niekompletnymi lub też nieudokumentowanymi. Testowanie systemu wymagań funkcjonalnych startuje poprzez użycie technik opartych na specyfikacji (czarnoskrzynkowe) dla testowanego aspektu systemu. Można również użyć technik opartych na strukturze (białoskrzynkowe) do oceny dokładniości testowania w odniesieniu do elementów struktury, takich jak menu, czy nawigacja po stronach www.
Takie testy wykonywane są przez niezależny zespół testowy.
TESTY AKCEPTACYJNE
Obiektami testów akceptacyjnych są proces biznesowy (już na w pełni zintegrowanym systemie), procesy utrzymania oraz obsługi systemu, formularze, raporty czy dane konfiguracyjne. Podstawą do testów będą przede wszystkim wymagania systemowe, wymagania użytkownika software'u, przypadki użycia software'u, raporty z analizy ryzka.
Odpowiedzialność za testy akceptacyjne leży często po stronie klientów lub użytkowników systemu.
Celem testów akceptacyjnych jest nabranie zaufania do systemu, jego części bądź pewnych atrybutów niefunkcjonalnych (np. szybkość przekazywania procesów etc). Testy akceptacyjne mają za zadanie ocenić gotowość systemu do wdrożenia oraz użycia, chociaż nie muszą być ostatnim etapem testowania - testy akceptacyjne mogą pojawić się w wielu momentach SLC.
Typowymi formami testów akceptacyjnych są: testy akceptacyjne przez użytkownika, testy produkcyjne, akceptacja systemów przez adminów (testowanie kopii zapasowych, uruchamiania systemu po awarii, ładowanie danych i zadania związane z migracją etc.).
Testy ALFA wykonywane są u producenta ale nie przez zespół projektowy. Mają za zadanie uzyskanie opinii potencjalnych lub obecnych klientów nt. systemu przed wypuszczeniem go do sprzedaży. Testy BETA (testy polowe) wykonywane są przez klientów.
================
Kandydat potrafi porównać podając przykłady cztery typy testów (funkcjonalne, niefunkcjonalne, strukturalne oraz związane ze zmianami).
Skoro mamy typy testów to logicznym jest, że każdy z nich skupia się na określonym celu. Takie cele to np. przetestowanie jakiegoś niefunkcjonalnego atrybutu jakościowego, przetestowanie struktury czy architektury systemu, przetestowanie zmian zachodzących w oprogramowaniu etc.
Oczywiście można opracować swój własny model oprogramowania i użyć go w testach różnego typu:) My skupimy się na podstawowych czterech typach testów :)
Testowanie funkcji (testowanie funkcjonalne)
Funkcje, jakie ma pełnić dany system, moduł, podsystem etc. opisane są w specyfikacji. Warto jednak zwrócić uwagę na to, że nie zawsze specyfikacja jest dostępna dla testerów. W skrócie testy funkcjonalne mają za zadanie sprawdzić 'co system właściwie robi'.
Testy funkcjonalne dotyczą funkcji lub innych cech systemu oraz ich współdziałania z innymi systemami. Można je wykonywać na wszelkich poziomach.
Do tworzenia warunków testowych oraz przypadków testowych dla funkcjonalności systemu mogą zostać użyte techniki oparte na specyfikacji (czarnoskrzynkowe) - testy funkcjonalne zajmują się zewnętrznym zachowaniem oprogramowania.
Testowanie zabezpieczeń np. sprawdza funkcje pozwalające na wykrycie zagrożeń (np. wirusy). Inne typy testów funkcjonalnych to: testowanie współdziałania, ocenia zdolność software'u do współpracy z jednym lub większą liczbą wskazanych modułów bądź systemów.
Myślę, że najlepszy sens testów odda definicja via wiki: "Testy funkcjonalne znane są także jako testy czarnej skrzynki, ponieważ osoba testująca nie ma dostępu do informacji na temat budowy programu, który testuje. Często testy takie są wykonywane przez osoby inne niż programiści tworzący program".
Testowanie atrybutów niefunkcjonalnych (testowanie niefunkcjonalne)
Obejmuje ono następujące typy testów: wydajnościowe, obciążeniowe, przeciążeniowe, użyteczności, pielęgnowalności, niezawodności, przenaszalności. Testowanie te w przeciwieństwie do funkcjonalnego polega na tym, aby sprawdzić jak właściwie dany system działa.
Testowanie niefunkcjonalne może być wykonywane na wszystkich poziomach testów. Termin tych testów oznacza testy wymagane do zmierzenia właściwości systemów i oprogramowania, które mogą zostać określone ilościowo na zmiennej skali, takich jak czasy odpowiedzi w testach wydajnościowych.
Testowanie struktury/architektury oprogramowania (testowanie strukturalne)
Moje ulubione. Testy strukturalne w przeciwieństwie do testów funkcjonalnych opierają się na wiedzy testera na temat testowanego systemu. Testy takie, oparte na strukturze systemu, oprogramowania nazywamy białoskrzynkowymi. Można je wykonywać na każdym poziomie testowania, najlepiej jednak użyć je po testach opartych na funkcji danego systemu (opartych na specyfikacji), po to, by zmierzyć dokładność testowania przez ocenę stopnia pokrycia wybranego typu struktury.
Pokrycie to nic innego, jak opis stopnia przetestowania odeska pokrytych elementów. Tj. jeżeli pokrycie struktury kodu źródłowego programu będzie niższe, niż sto%, można wtedy zaprojektować więcej testów, by przetestować elementy, które zostały pominięte.
Do pomiaru pokrycia (np. decyzji lub instrukcji) na wszystkich poziomach, a szczególnie na poziomie testów modułowych i testów integracji modułów mogą zostać użyte narzędzia. Testowanie strukturalne może zostać oparte na architekturze systemu :)
Testowanie związane ze zmianami: testowanie potwierdzające oraz regresywne
Po wykryciu i naprawieniu defektu przez programistę powinien zostać wykonany retest po to, by potwierdzi usunięcie usterki. To właśnie testy potwierdzające. Debagowanie (lokalizacja oraz poprawienie usterek) jest czynnością programistyczną, a nie testową.
Testowanie regresywne zaś to powtórzenie testów na już wcześniej przetestowanym systemie, oprogramowaniu wykonywane po modyfikacjach tylko po to, żeby stwierdzić, czy przy aktualizacji, usunięciu usterek nie powstały nowe defekty na skutek tych zmian. Testy regresywne wykonuje się po wszystkich zmianach w oprogramowaniu, a także po zmianach w jego środowisku.
Obydwa wyżej wymienione testy muszą być powtarzalne.
Testy regresywne można wykonać na wszystkich poziomach testów i dla wszystkich typów testów. :)
Kandydat potrafi porównać testy pielęgnacyjne (testowanie istniejącego systemu) do testowania nowej aplikacji uwzględniając typy testów, powody rozpoczęcia testowania oraz ilość testów. Potrafi również wymienić powody wykonywania testów pielęgnacyjnych (zmiany, migracja, cofnięcie systemu - odp. w pytaniu) oraz opisać rolę testów regresywnych i analizy wpływu w utrzymaniu.
Wiadomym jest, że wdrożony system musi działać przez lata. W tym czasie system, jego dane konfiguracyjne, czy środowisko są często poprawiane, zmieniane i rozszerzane (zmiana IDE, nowe dane w BZ etc.). Dla dobrego testowania pielęgnacyjnego krytyczne jest planowanie wydań z wyprzedzeniem. Konieczne jest również rozróżnianie pomiędzy planowanymi wydaniami oraz szybkimi poprawkami. Testowanie pielęgnacyjne wykonuje się na działającym systemie na skutek modyfikacji, migracji lub złomowania oprogramowania bądź systemu.
Takimi modyfikacjami mogą być planowane ulepszenia, poprawki, naprawy awaryjne, zmiany IDE etc.
Testy pielęgnacyjne migracji oprogramowania (np. pomiędzy platformami) powinny prócz testów zmian w oprogramowaniu uwzględniać również testy produkcyjne nowego IDE. Testy te są również potrzebne, gdy dane z innej aplikacji są migrowane do utrzymywanego systemu.
Testy pielęgnacyjne związane z wycofywaniem oprogramowania mogą zawierać testy migracji lub archiwizacji danych, jeżeli wymagany jest długi okres ich przetrzymywani :)
Testy pielęgnacyjne prócz przetestowania tego, co zostało zmienione zawierają również testy regresywne tych części systemu, które się nie zmieniły. Zakres testów pielęgnacyjnych zależy od ryzyka zmian, wielkości istniejącego systemu oraz zakresu tych zmian. W zależności od tych zmian testowanie pielęgnacyjne może być wykonywane na różnych poziomach testów lub na wszystkich oraz dla wybranych lub wszystkich typów testów.
Analiza wpływu to określenie, jaki wpływ na istniejący system mogą mieć zmiany. Stosuje się ją, aby ustalić zakres testów regresywnych :) (cięcie kosztów, ekonomia). Może i jest często używana do wybierania zestawu testów regresywnych.
Warto pamiętać, iż testowanie pielęgnacyjne jest trudne do wykonania, jeśli specyfikacja oprogramowania jest przestarzała lub jest jej brak.
=====================
Na tym zakończymy pierwszą część. Jest ona oparta w dużej mierze na sylabusie ISTQB rozdział 2 ale z moimi uwagami i trochę rozszerzonym materiałem. Nie rozwodziłem się nad pierwszym rozdziałem, bo wg. mnie nie ma w nim zbyt wielu konkretów, a sam jest przedstawiony w całości w serii kursów na YT, gdzie sam film znajdziecie poniżej tego zdania. Czekajcie na kolejne części pewnie już jutro.
Trzymajcie się,
F.
Co oznacza skrót SLC?
OdpowiedzUsuńzdaje się, że kolega ominął literę T i chodzi o STLC czyli z angielska Software Testing Life Cycle tu można o tym więcej poczytać : https://www.softwaretestingclass.com/software-testing-life-cycle-stlc/
Usuń