CTFL2011 Podstawy testowania

Z AmberPlace

Spis treści 1 1.1 Dlaczego testowanie jest niezbędne? 2 1.2 Co to jest testowanie? 3 1.3 Ogólne zasady testowania 4 1.4 Podstawowy proces testowy 5 1.5 Psychologia testowania 6 1.6 Kodeks etyczny 7 Literatura 8 Referencje

K2 155min

Cele nauczania dla podstaw testowania.

Te cele określają co będziesz potrafił po zakończeniu modułu.

1.1 Dlaczego testowanie jest niezbędne? (K2)

LO-1.1.1 Kandydat potrafi opisać podając przykłady sposób w jaki usterka w oprogramowaniu może wyrządzić szkodę osobie, środowisku lub firmie. (K2)

LO-1.1.2 Kandydat rozróżnia przyczynę usterki od jej skutków. (K2)

LO-1.1.3 Kandydat potrafi podać powody tego, że testowanie jest niezbędne posiłkując się przykładami. (K2)

LO-1.1.4 Kandydat potrafi opisać w jaki sposób testowanie stanowi część zapewnienia jakości i podać przykłady tego, w jaki sposób testowanie przyczynia się do zwiększenia jakości.

LO-1.1.5 Kandydat potrafi wyjaśnić i porównać pojęcia pomyłka, usterka, awaria oraz odpowiadające im pojęcia błąd i bug, podając przykłady. (K2)

1.2 Co to jest testowanie? (K2)

LO-1.2.1 Kandydat pamięta ogólne cele testowania. (K1)

LO-1.2.2 Kandydat potrafi podać przykłady celów testowania w różnych fazach cyklu życia oprogramowania. (K2)

LO-1.2.3 Kandydat rozróżnia testowanie od debagowania. (K2)

1.3 Siedem zasad testowania (K2)

LO-1.3.1 Kandydat potrafi wyjaśnić siedem zasad testowania.

1.4 Podstawowy proces testowy (K1)

LO-1.4.1 Kandydat pamięta pięć podstawowych czynności testowych i odpowiadające im zadania od planowania do zamknięcia testów. (K1)

1.5 Psychologia testowania (K2)

LO-1.5.1 Kandydat pamięta czynniki psychologiczne, od których zależy sukces testowania. (K1)

LO-1.5.2 Kandydat potrafi pokazać różnice w nastawieniu testera i programisty (K2)

1.1 Dlaczego testowanie jest niezbędne?

K2 20min

Pojęcia
pluskwa, defekt, błąd, awaria, usterka, pomyłka, jakość, ryzyko

1.1.1 Kontekst systemów softwarowych

K1

Systemy softwarowe są integralną częścią naszego życia, od aplikacji biznesowych (np. w bankowości) po produkty użytkowe (np. samochody). Większość ludzi spotkała się z oprogramowaniem, które nie działało tak jak powinno. Oprogramowanie, które działa niepoprawnie może spowodować wiele problemów, stratę pieniędzy, czasu lub utratę reputacji biznesowej. Może nawet spowodować utratę zdrowia lub życia.

1.1.2 Przyczyny usterek w oprogramowaniu

K2

Człowiek może popełnić błąd (pomyłkę), która powoduje powstanie defektu (usterki, pluskwy) w kodzie programu lub dokumencie. Jeżeli defekt w kodzie zostaje wykonany, system nie zrobi tego co powinien (lub wykona to czego nie powinien) powodując awarię. Usterki w oprogramowaniu, systemach lub dokumentach mogą prowadzić do wystąpienia awarii, ale nie wszystkie usterki powodują awarie.

Defekty istnieją ponieważ ludzie są omylni, działają pod presją, pracują ze złożonym kodem, w skomplikowanej infrastrukturze, ze zmieniającymi się technologiami oraz z dużą ilością interakcji pomiędzy systemami.

Awarie mogą zostać spowodowane też przez warunki środowiskowe. Na przykład promieniowanie, pole magnetyczne i elektryczne oraz zanieczyszczenia mogą spowodować awarie oprogramowania wbudowanego lub wpływać na oprogramowanie przez zmianę warunków działania sprzętu.

1.1.3 Rola testowania w rozwoju, utrzymaniu i użytkowaniu oprogramowania

K2

Rygorystyczne testy systemów i dokumentacji mogą pomóc w zmniejszeniu ryzyka wystąpienia problemów podczas użytkowania oprogramowania i przyczynić się do podniesienia jakości sytemu, jeżeli znalezione usterki zostaną poprawione przed wdrożeniem systemu do użytkowania.

Testowanie oprogramowania może być wymagane również przez kontrakt lub ze względu na uwarunkowania prawne lub standardy obowiązujące w danej gałęzi przemysłu.

1.1.4 Testowanie a jakość

K2

Za pomocą testów można zmierzyć jakość oprogramowania wyrażoną przez ilość znalezionych usterek zarówno dla funkcjonalnych jak i niefunkcjonalnych wymagań i atrybutów oprogramowania (np. niezawodności, użyteczności, efektywności, pielęgnowalności lub przenaszalności). Więcej informacji na temat testów niefunkcjonalnych znajduje się w rozdziale 2, a na temat atrybutów jakościowych oprogramowania w standardzie "Software Engineering – Software Product Quality" ISO 9126.

Testowanie może budować zaufanie do jakości oprogramowania jeżeli znajduje mało usterek lub nie znajduje ich wcale. Poprawnie zaprojektowany test, który jest zaliczony^[1] obniża ogólny poziom ryzyka w systemie. Kiedy testowanie wykrywa usterki, jakość systemu podnosi się wraz z ich naprawieniem.

Powinno się wyciągać wnioski z poprzednich projektów. Przez zrozumienie pierwotnych przyczyn usterek można doskonalić procesy, co z kolei powinno przeciwdziałać ponownemu pojawianiu się tych usterek i w konsekwencji podnosić jakość przyszłych systemów. Jest to jeden z aspektów zapewnienia jakości.

Testowanie powinno być zintegrowane z innymi działaniami w ramach zapewnienia jakości (np. standardami kodowania, szkoleniami i analizą defektów).

1.1.5 Jak dużo testowania jest potrzebne?

K2

Podczas podejmowania decyzji jak dużo testów potrzeba powinno się wziąć pod uwagę poziom ryzyka, włączając w to ryzyko techniczne, ryzyko związane z bezpieczeństwem, a także ryzyko biznesowe oraz ograniczenia projektowe takie jak czas i budżet. (Więcej na temat ryzyka jest w rozdziale 5.)

Testowanie powinno dostarczać interesariuszom wystarczającą ilość informacji do podjęcia świadomych decyzji o dopuszczeniu testowanego oprogramowania lub systemu do następnej fazy rozwoju lub przekazaniu go klientowi.

1.2 Co to jest testowanie?

K2 30min

Pojęcia
debagowanie, wymaganie, przegląd, przypadek testowy , testowanie, cel testu

Wprowadzenie

Za testowanie najczęściej uważa się tylko wykonywanie testów, to jest uruchamianie oprogramowania. Wykonywanie testów stanowi część testowania, ale istnieją jeszcze inne czynności związane z testowaniem.

Czynności testowania występują zarówno przed, jak i po wykonywaniu testów. Należą do nich: planowanie i nadzór, wybór warunków testowych, projektowanie i wykonywanie przypadków testowych, sprawdzanie wyników, ocena spełnienia kryteriów zakończenia, raportowanie procesu testowania i testowanego systemu oraz kończenie i zamykanie testów (po zakończeniu fazy testów). Do testowania zalicza się także przeglądy dokumentacji i kodu źródłowego oraz analizę statyczną.

Testy dynamiczne i statyczne mogą służyć jako środek do osiągnięcia podobnych celów i dostarczają informacji pozwalających na doskonalenie zarówno testowanego systemu jak i procesów rozwoju i testowania oprogramowania.

Istnieją różne cele testowania:

• znajdowanie usterek
• nabieranie zaufania do poziomu jakości
• dostarczanie informacji potrzebnych do podejmowania decyzji
• zapobieganie defektom

Proces myślowy oraz czynności związane z projektowaniem testów wcześnie w cyklu życia oprogramowania (weryfikacja podstawy testów przez projektowanie testów) mogą zapobiec wprowadzeniu usterek do kodu. Przeglądy dokumentów (np. wymagań) oraz identyfikacja i rozwiązywanie problemów również pomagają w przeciwdziałaniu pojawianiu się defektów w kodzie.

Różne punkty widzenia pozwalają na wzięcie pod uwagę w testach różnych celów. Na przykład w testowaniu wytwórczym (np. testowaniu modułowym, integracyjnym lub systemowym) głównym celem może być wywołanie tylu awarii ile się uda, żeby zidentyfikować i poprawić usterki występujące w oprogramowaniu. W testach akceptacyjnych głównym celem może być potwierdzenie, że system działa tak jak powinien oraz nabranie pewności że spełnia wymagania. W niektórych przypadkach celem testowania może być ocena jakości oprogramowania (bez intencji naprawiania defektów), by dostarczyć interesariuszom informacji o ryzyku związanym z wydaniem systemu w danej chwili. Testowanie pielęgnacyjne często zawiera testy sprawdzające, czy nie wprowadzono nowych usterek podczas wykonywania zmian. Głównym celem testowania produkcyjnego może być ocena atrybutów systemu takich jak niezawodność lub dostępność.

Debagowanie różni się od testowania. Testowanie dynamiczne może pokazać awarie, których źródłem są usterki. Debagowanie jest czynnością programistyczną, która znajduje, analizuje i usuwa przyczynę awarii. Późniejsze retesty wykonywane przez testera gwarantują, że poprawka rzeczywiście usunęła usterkę. Odpowiedzialność za każdą z tych czynności jest zwykle inna t.j. testerzy testują, a programiści debagują.

Proces testowania i czynności z nim związane omówione są w podrozdziale 1.4.

1.3 Ogólne zasady testowania

K2 35min

Pojęcia
testowanie gruntowne

Zasady

W ciągu ostatnich czterdziestu lat powstała pewna ilość zasad testowania, które zawierają ogólne wskazówki przydatne przy każdych testach.

Zasada 1 - Testowania ujawnia usterki

Testowanie może pokazać, że istnieją usterki, ale nie może dowieść że oprogramowanie nie posiada defektów. Testowanie zmniejsza prawdopodobieństwo występowania w oprogramowaniu niewykrytych defektów, ale nawet jeżeli nie zostały znalezione żadne usterki, nie stanowi to dowodu poprawności oprogramowania.

Zasada 2 - Testowanie gruntowne jest niewykonalne

Przetestowanie wszystkiego (wszystkich kombinacji wejść i warunków początkowych) jest wykonalne tylko w trywialnych przypadkach. Zamiast testowania gruntownego, do kierowania testami należy wykorzystać analizę ryzyka i priorytetyzację.

Zasada 3 - Wczesne testowanie

Po to żeby wykryć usterki wcześnie, testowanie rozpoczyna się w cyklu rozwoju oprogramowania lub systemu tak wcześnie jak to tylko jest możliwe i jest nakierowane na spełnienie zdefiniowanych celów.

Zasada 4 - Kumulowanie się błędów

Pracochłonność testowania jest dzielona proporcjonalnie do spodziewanej oraz zaobserwowanej gęstości błędów w modułach. Niewielka liczba modułów zwykle zawiera większość usterek znalezionych przez wydaniem lub jest odpowiedzialna za większość awarii na produkcji.

Zasada 5 - Paradoks pestycydów

Jeżeli te same testy są powtarzane bez zmian, to w końcu przestaną znajdować nowe usterki. Żeby przezwyciężyć "paradoks pestycydów", testy muszą być regularnie przeglądane i uaktualniane. Nowe, odmienne przypadki testowe muszą być projektowane w celu przetestowania różnych części oprogramowania lub systemu, żeby umożliwić odszukanie nowych usterek.

Zasada 6 - Testowanie zależy od kontekstu

Testowanie wykonuje się w różny sposób w różnym kontekście. Na przykład oprogramowanie krytyczne ze względu na bezpieczeństwo testuje się inaczej niż sklep internetowy.

Zasada 7 - Mylne przekonanie o braku błędów

Znajdowanie i naprawa usterek nie pomoże jeżeli produkowany system jest nieużywalny lub nie spełnia wymagań i oczekiwań użytkownika.

1.4 Podstawowy proces testowy

K1 35min

Pojęcia
testowanie potwierdzające, retesty, kryteria zakończenia, incydent, testowanie regresywne, podstawa testów, warunek testowy, pokrycie testowe, dane testowe, wykonanie testów, log testowy, plan testów, procedura testowa, polityka testów, zestaw testów, raport podsumowujący testy, testalia

Wstęp

Najbardziej widocznym elementem testowania jest wykonywanie testów. Jednak, żeby testy były skuteczne i efektywne, plany testów powinny również uwzględniać czas potrzebny na zaplanowanie testów, zaprojektowanie przypadków testowych, przygotowanie do ich wykonania oraz ocenę wyników.

Podstawowy proces testowy składa się z następujących czynności:

• planowanie i nadzór nad testami
• analiza i projektowanie testów
• implementacja i wykonanie testów
• ocena kryteriów zakończenia i raportowanie
• czynności zamykające test

Chociaż wyżej wymienione czynności układają się w logiczny ciąg, to w praktyce mogą się zazębiać lub występować jednocześnie. Zwykle konieczne jest ich dostosowanie do kontekstu systemu i projektu.

1.4.1 Planowanie i nadzór

K1

Planowanie testów polega na zdefiniowaniu celów testowania i określeniu czynności testowych potrzebnych do wypełnienia misji i celów testowania.

Nadzór nad testami jest ciągłą aktywnością polegającą na porównywaniu postępów testów z planem oraz raportowaniu statusu (włącznie z odchyleniami od planu). Polega również na podejmowaniu działań koniecznych do wypełnienia misji i celów projektu. Żeby nadzorować testy, zadania testowe trzeba monitorować przez cały projekt. Podczas planowania testów bierze się pod uwagę informacje pochodzące z monitorowanie i nadzoru testów.

Zadania związane z planowaniem i nadzorem nad testami zdefiniowane są w rozdziale 5 tego sylabusa.

1.4.2 Analiza i projektowanie testów

K1

Podczas analizy i projektowania testów ogólne cele testowania przekuwane są w konkretne warunki testowe i przypadki testowe.

Głównymi zadaniami analizy i projektowania testów są:

• przeglądanie podstawy testów (wymagań, poziomu integralności oprogramowania^[2] (poziomu ryzyka), raportów analizy ryzyka, architektury, projektu, specyfikacji interfejsów)
• ocena testowalności podstawy testowania i przedmiotu testów
• identyfikacja i priorytetyzacja warunków testowych na podstawie analizy elementów testowych, specyfikacji, zachowania i struktury oprogramowania
• projektowanie i priorytetyzacja przypadków testowych wysokiego poziomu
• ustalenie jakie dane testowe są potrzebne dla warunków testowych oraz przypadków testowych
• projektowanie środowiska testowego oraz identyfikacja potrzebnej infrastruktury i narzędzi
• tworzenie dwukierunkowego śledzenia pomiędzy podstawą testów oraz przypadkami testowymi

1.4.3 Implementacja i wykonanie testów

K1

Implementacja i wykonanie testów, to czynność, podczas której specyfikowane są procedury i skrypty testowe przez ustawienie przypadków testowych w konkretnej kolejności oraz dołączenie innych informacji potrzebnych do wykonania testów, konfigurowane jest środowisko testowe oraz wykonywane są testy.

Głównymi zadaniami implementacji i wykonania testów są:

• wykańczanie, implementacja i priorytetyzacja przypadków testowych (włącznie z identyfikacją danych testowych)
• przygotowanie^[3] i priorytetyzacja procedur testowych, tworzenie danych testowych oraz (opcjonalnie) przygotowywanie jarzm testowych i pisanie automatycznych skryptów testowych
• tworzenie zestawów testów z procedur testowych w celu efektywniejszego wykonania testów
• sprawdzenie, czy środowisko testowe zostało poprawnie skonfigurowane
• weryfikacja oraz uaktualnienie dwukierunkowego śledzenia pomiędzy podstawą testów oraz przypadkami testowymi
• wykonanie procedur testowych w zaplanowanej kolejności, ręcznie lub przy pomocy narzędzi do wykonywania testów
• zapisywanie wyników wykonania testów oraz zapisywanie identyfikatorów i wersji testowanego oprogramowania, narzędzi testowych oraz testaliów
• porównywanie wyników rzeczywistych z wynikami oczekiwanymi
• raportowanie rozbieżności jako incydentów oraz ich analiza w celu ustalenia ich przyczyny (usterki w kodzie, w danych testowych, w dokumencie testowym, albo pomyłka w trakcie wykonywania testów)
• powtarzanie czynności testowych jako rezultat akcji podjętych po stwierdzeniu rozbieżności

Na przykład powtórne wykonanie testów niezaliczonych, aby potwierdzić naprawę defektu (testowanie potwierdzające), wykonanie poprawionych testów lub wykonanie testów w celu sprawdzenia czy w nie zmienianych częściach oprogramowania nie pojawiły się usterki lub czy naprawa usterek nie ujawniła innych defektów (testowanie regresywne).

1.4.4 Ocena spełnienia kryteriów zakończenia i raportowanie

K1

Ocena spełnienia kryteriów zakończenia polega na ocenie wykonania testów zgodnie z przyjętymi celami testowania. Powinna ona być wykonywana dla każdego poziomu testowania (patrz podrozdział 2.2).

Głównymi zadaniami oceny spełnienia kryteriów zakończenia są:

• sprawdzanie w logach testowych, czy zostały spełnione kryteria zakończenia testów określone podczas planowania
• ocenienie, czy potrzeba więcej testów lub czy nie powinny zostać zmienione kryteria zakończenia
• napisanie raportu podsumowującego testy dla interesariuszy

1.4.5 Czynności zamykające testy

K1

W ramach czynności zamykających testy zbierane są dane z zakończonych czynności testowych, żeby utrwalić doświadczenie, testalia, fakty i liczby. Czynności zamykające test wykonywane są przy kamieniach milowych projektu takich jak, wydanie systemu, zakończenie (lub anulowanie) projektu testowego, osiągnięcie kamienia milowego, lub zakończenie wydania serwisowego.

Głównymi zadaniami wykonywanymi w ramach czynności zamykających testy są:

• sprawdzenie, które planowane produkty zostały dostarczone
• zamknięcie raportów incydentów lub utworzenie zgłoszeń zmian^[4] dla tych, które pozostały otwarte
• udokumentowanie akceptacji systemu
• dokończenie i zarchiwizowanie testaliów, środowiska testowego i infrastruktury testowej do ponownego użycia w późniejszym terminie
• przekazanie testaliów do zespołu serwisowego
• przeanalizowanie doświadczeń do ustalenia, jakie zmiany są potrzebne w przyszłych wydaniach i projektach
• wykorzystanie zebranych informacji do podniesienia dojrzałości testowania

1.5 Psychologia testowania

K2 35min

Pojęcia
zgadywanie błędów, niezależność testowania

Wstęp

Sposób myślenia stosowany podczas testowania i przeglądania różni się od stosowanego podczas rozwoju oprogramowania. Programiści posiadający odpowiednie nastawienie są w stanie testować swój kod, ale zwykle odpowiedzialność za testowanie przekazuje się testerom żeby wzmocnić koncentrację wysiłków oraz uzyskać dodatkowe korzyści, takie jak niezależne spojrzenie wyszkolonych, zawodowych testerów. Testowanie niezależne może być wykorzystane na dowolnym poziomie testów.

Niezależność do pewnego stopnia jest często bardziej skuteczna w znajdowaniu defektów i awarii (unika się stronniczości autora). Nie może ona jednak zastąpić znajomości rzeczy i z tego względu programiści są w stanie efektywnie znajdować usterki w swoim własnym kodzie. Można zdefiniować kilka poziomów niezależności (od najniższego do najwyższego):

• testy zaprojektowane przez osobę, która napisała testowane oprogramowanie (niski poziom niezależności)
• testy zaprojektowane przez inną osobę (np. z zespołu programistów)
• testy zaprojektowane przez osobę z innego zespołu w organizacji (np. niezależnego zespołu testerów) lub przez specjalistów od testów (np. testów wydajnościowych lub użyteczności)
• testy zaprojektowane przez osobę z innej organizacji lub firmy (np. testy zlecone lub certyfikacja przez niezależny organ certyfikujący)

Ludzie i projekty kierują się celami. Ludzie mają skłonność do dopasowywania planów do celów określonych przez kierownictwo lub innych interesariuszy. Na przykład, żeby znajdować błędy albo żeby potwierdzić że oprogramowania spełnia zadane cele. Dlatego bardzo ważne jest jasne wyrażenie celów testowania.

Znajdowanie błędów podczas testów może być odbierane jako krytykowanie produktu lub jego autora. Z tego powodu testowanie często jest postrzegane jako działanie destrukcyjne, nawet jeżeli jest bardzo konstruktywne z punktu widzenia zarządzania ryzykiem produktowym. Wyszukiwanie awarii w systemie wymaga ciekawości, profesjonalnego pesymizmu, krytycznego spojrzenia, przywiązywania wagi do szczegółów, dobrej komunikacji z programistami oraz doświadczenia na którym można oprzeć zgadywanie błędów.

Można uniknąć spięć pomiędzy testerami, a analitykami, projektantami i programistami przez komunikowanie błędów, usterek i awarii w sposób konstruktywny. Ta zasada ma zastosowanie zarówno do defektów znalezionych podczas przeglądów jaki w testowaniu.

Tester i lider testów potrzebują dużych umiejętności interpersonalnych żeby przekazywać fakty dotyczące usterek, postępów i ryzyka w sposób konstruktywny. Informacje na temat usterek w oprogramowaniu lub dokumencie mogą pomóc ich autorom w podnoszeniu kwalifikacji. Usterki znalezione i naprawione podczas testowania oszczędzają czas i pieniądze później i ograniczają ryzyko.

Problemy z komunikacją mogą wystąpić jeżeli testerzy są postrzegani jedynie jako posłańcy przynoszący niechciane informacje o usterkach. Istnieje kilka sposobów na poprawienie komunikacji i relacji pomiędzy testerami i resztą zespołu:

• zacznij od współpracy, a nie od wojny - przypomnij wszystkim, że celem jest wyprodukowanie systemów o lepszej jakości
• komunikuj informacje na temat produktu w sposób neutralny, skoncentrowany na faktach bez krytykowania autora produktu, na przykład pisz obiektywne i konkretne raporty incydentów oraz uwagi z przeglądów
• spróbuj zrozumieć co druga osoba czuje i dlaczego reaguje tak jak reaguje
• upewnij się, że druga strona zrozumiała co powiedziałeś i vice versa

1.6 Kodeks etyczny

K2 10min

Zaangażowanie w testy pozwala poszczególnym testerom na poznanie poufnych oraz niejawnych informacji. Konieczny jest kodeks etyczny, który zapewni między innymi, że informacje te nie zostaną niewłaściwie użyte. Pamiętając o kodeksach etycznych dla inżynierów opublikowanych przez ACM i IEEE, ISTQB ogłasza następujący kodeks

• interes publiczny - certyfikowani testerzy oprogramowania postępują zgodnie z interesem publicznym
• klient i pracodawca - certyfikowani testerzy oprogramowania postępują zgodnie z najlepiej pojmowanym interesem swoich klientów i pracodawców, zgodnym z interesem publicznym
• produkt - certyfikowani testerzy oprogramowania dokładają wszelkich starań żeby dostarczane przez nich produkty (związane z testowanymi przez nich produktami i systemami) spełniają najwyższe standardy zawodowe
• osąd - certyfikowani testerzy oprogramowania są w swoich osądach uczciwi i niezależni
• kierownictwo - certyfikowani kierownicy testów postępują etycznie i promują etyczne podejście do kierowania testami
• zawód - certyfikowani testerzy oprogramowania promują uczciwość oraz reputację zawodu testera w zgodzie z interesem publicznym
• współpracownicy - certyfikowani testerzy oprogramowania są uczciwi wobec swoich współpracowników i wspierają ich oraz promują współpracę z deweloperami
• ja - certyfikowani testerzy oprogramowania uczą się przez całe życie swojego zawodu oraz promują etyczne podejście do praktyki zawodowej

Literatura

1.1.5	Black, 2001, Kaner, 2002
1.2	Beizer, 1990, Black, 2001, Myers, 1979
1.3	Beizer, 1990, Hetzel, 1998, Myers, 1979
1.4	Hetzel, 1998
1.4.5	Black, 2001, Craig, 2002
1.5	Black, 2001, Hetzel, 1998

Referencje

1. ↑ pass - tak jest przetłumaczone w słowniku SJSI
2. ↑ Stopień w którym oprogramowanie spełnia lub musi spełniać zbiór określonych przez interesariuszy atrybutów programowych lub sprzętowych (np. złożoność oprogramowania, ocena ryzyka, poziom bezpieczeństwa, poziom zabezpieczeń, pożądana wydajność, niezawodność lub koszt), które zostały zdefiniowane żeby odzwierciedlać wagę oprogramowania dla interesariuszy.
3. ↑ development
4. ↑ change records