Redakcja
To już kolejny sylabus wypracowany we współpracy z innymi organizacjami certyfikującymi. Tym razem jest to International Qualification Board for Business Analysis (IQBBA). Nic więc dziwnego, że odbiorcami tego sylabusa nie są testerzy, a bardziej osoby po stronie biznesu, które testy powinny wykonywać. Zauważyć można tendencję, że ISTQB swoje certyfikaty dzieli na "tester" oraz "testing". Pierwszy z typów to opisy odpowiedzialności dla roli jak zadania dla agile tester czy automotive software tester. „Testing” odnosi się bardziej do aktywności, którą mogą wykonywać inne role, a wiążą się one z kontrolą jakości.
W celach samego sylabusa możemy znaleźć definicję odbiorców i zakresu dokumentu:
„Ocena i walidacja rozwiązania biznesowego to ważne działania właścicieli produktów (PO), analityków biznesowych (BA) i testerów. Częścią ich obowiązków jest określenie kryteriów akceptacji wymagań, niezależnie od rodzaju cyklu rozwojowego (zwinny lub tradycyjny). Kryteria akceptacji są definiowane poprzez dekompozycję wymagań na bardziej atomowe i testowalne formy. Następnie przypadki testowe są projektowane w celu weryfikacji rozwiązania pod kątem tych kryteriów. Projektowanie testów akceptacyjnych na podstawie kryteriów akceptacji powinno być działaniem realizowanym we współpracy, angażującym analityków biznesowych i testerów. Wszystko to by osiągnąć cele zapewnienia dużej wartości biznesowej samej fazy testów akceptacyjnych i zmniejszenia ryzyka związanego z wydaniem produktu. Wspieranie tej współpracy, a tym samym unikanie efektu silosu między właścicielami produktów / analitykami biznesowymi a testerami, jest kluczowym celem tego sylabusa. Ten dokument opisujący testy akceptacyjne jest skierowany do wszystkich osób zaangażowanych w działania związane z testowaniem akceptacyjnym oprogramowania. Obejmuje to osoby pełniące role, takie jak właściciele produktów, analitycy biznesowi, testerzy, analitycy testów, inżynierowie testów, konsultanci testów, kierownicy testów, testerzy user acceptance i programiści.
[…] Program nauczania obejmuje UAT-y, testy akceptacji umów i regulacji, a także testy alfa i beta. Nie dotyczy natomiast testów akceptacji operacyjnej (OAT), ponieważ jest on zwykle wykonywany przez zespoły, które będą obsługiwać system, a nie przez testerów i analityków biznesowych.”
Ostatnie wyłączenie jest o tyle dziwne, że wycina ważną grupę użytkowników, którzy co prawda stanowią mniejszość (np. administratorzy system), ale są jego kluczowymi odbiorcami. Dodatkowo pomimo tego, że sylabus krytykuje silosy, to jednak dzieli zespoły na dwie grupy, którym osobno definiuje cele biznesowe. Mamy więc analityków biznesowych i właścicieli produktu, których celem jest:
- AcT-1 Wkład w organizację testów akceptacyjnych poprzez uczestnictwo w fazie projektowania testów akceptacyjnych i wspieranie dostosowania produktu do wymagań biznesowych.
- AcT-2 Przyczynianie się do organizacji działań związanych z testowaniem akceptacyjnym, w tym do procesu, artefaktów, komunikacji, raportowania, monitorowania i zarządzania takimi działaniami, a także współpracę z testerami i innymi zainteresowanymi stronami w tym procesie.
- AcT-3 Przyczynianie się do jakości procesu testowania akceptacyjnego, w tym walidacji i weryfikacji wyprodukowanych artefaktów.
Z drugiej strony mamy testerów nastawionych na:
- AcT-4 Przyczyniania się do definicji kryteriów akceptacji podczas fazy definiowania wymagań.
- AcT-5 Skuteczna współpraca z analitykami biznesowymi i innymi interesariuszami podczas wszystkich czynności związanych z testowaniem akceptacyjnym.
- AcT-6 Zrozumienie celów biznesowych, komunikowanie się z jednostkami biznesowymi i współdzielenie celów dotyczących testów akceptacyjnych.
Tym razem dostajemy 40 stronicowy podręcznik, z którego około 24 stron to wiedza. Układa się w następujący spis treści. Wersja oryginalna, ponieważ nie ma jeszcze tłumaczenia.
1 Introduction and Foundations – 80 min
1.1 Fundamental Relationships
1.1.1 Business Goals, Business Needs and Requirements
1.1.2 Requirements / User Stories, Acceptance Criteria and Acceptance Tests
1.1.3 The Importance of the Quality of the Requirements
1.2 Business Analysis and Acceptance Testing
1.2.1 Relationship between Business Analysis and Testing Activities
1.2.2 Collaboration between Business Analysts and Testers in Acceptance Testing
1.2.3 How Acceptance Testing Can Drive the Development Process: ATDD and BDD
2 Acceptance Criteria, Acceptance Tests and Experience- Based Practices – 165 min
2.1 Writing Acceptance Criteria
2.2 Designing Acceptance Tests
2.2.1 Test Techniques for Acceptance Testing
2.2.2 Using the Gherkin Language to Write Test Cases
2.3 Experience-based Approaches for Acceptance Testing
2.3.1 Exploratory Testing
2.3.2 Beta Testing
3 Business Process and Business Rules Modeling – 150 min
3.1 Modeling Business Processes and Rules
3.2 Deriving Acceptance Tests from Business Process/Rule Models
3.3 Business Process Modeling for Acceptance Testing
3.3.1 Good Practices for Business Process Modeling for Acceptance Testing
3.3.2 Using Business Process Models for ATDD
4 Acceptance Testing for Non-Functional Requirements – 95 min
4.1 Non-functional Characteristics and Quality in Use
4.1.1 Non-functional Quality Characteristics and Sub-characteristics
4.1.2 Quality in Use
Rozdział 1.
Podstawy. W rozdziale pierwszym nie ma zbyt dużo nowych rzeczy, których nie znaleźlibyśmy w innych sylabusach ISTQB, ale jest to mocno podlane analitycznym sosem. Pewną nowością jest nie pojawiająca się zbyt często w publikacjach ISTQB rola analityka biznesowego i jej relacja z odpowiedzialnościami testera.
Rozdział 2.
Kryteria, testy i techniki. Jest to dość wąski wybór praktyk z testów akceptacyjnych. Czymś nietypowym jest za to wskazanie jednego języka (Gherkin) do notacji przypadków testowych. ISTQB raczej uciekało od konkretnych rozwiązań technologicznych ze względu na możliwość szybkiego „zestarzenia” się wiedzy.
Dość dużą niespodzianką jest nieaktualizowanie wiedzy o testowaniu eksploracyjnym. ISTQB odwołuje się do starej publikacji Whittakera (który już nie zajmuje się testowaniem) z 2009 roku i ciągle nazywa eksplorację techniką, sprowadzając ją do roli jaką pełni chociażby technika klas równoważności.
Kolejnym potencjalnym błędem jest to, że sylabus we wprowadzeniu zapowiada opis testów alfa (ang. alpha). Niestety nic na ten temat tam nie znajdziemy. Zostały pominięte w całości.
Rozdział 3.
Procesy biznesowe i modelowanie reguł biznesowych. W tym rozdziale poznamy podstawy notacji BPMN i DMN jednak znów tylko na takim poziomie by zaciekawić się tematem i poszukać w innych źródłach.
Rozdział 4.
Kryteria akceptacji dla wymagań niefunkcjonalnych. W dużej części jest to wyciąg ze standardu ISO 25010:2011 bez czytelnego przełożenia tego na wykonywanie testów akceptacyjnych. Wyróżnione są tylko trzy atrybuty jakości: użyteczność, wydajność i bezpieczeństwo.
Rozdział 5.
Współpraca w testach akceptacyjnych. Dostajemy kilka haseł o współpracy, aktywnościach i podziale obowiązków oraz listę narzędzi.
W dodatku A znajdziemy jeszcze kilka (naprawdę kilka) informacji BPMN i DMN.
Komentarz
Jeśli spodziewaliście się, że kolejne rozdziały przyniosą więcej szczegółów to niestety tak nie jest. Większość tematów omówionych jest hasłowo, zachęcając tym samym do poszukiwania informacji w innych źródłach. Często o poszczególnych czynnościach dowiecie się czym są, kto je powinien wykonywać i kiedy, ale prawie nigdy nie dowiecie się „jak”.
Dla kogo jest ta publikacja? Dla każdego, kto pracuje w IT. Jednak nie jest to publikacja, z której da się czegoś nauczyć. Można to potraktować jako zestaw źródeł do poznania. Po lekturze nie będziecie wiedzieli jak przeprowadzić testy akceptacyjne, nie będziecie nawet mieli ułatwionej drogi, ponieważ polecane publikacje to szeroki opis wszystkich najważniejszych praktyk w odbiorach oprogramowania.
Co to jest za publikacja? Szczegółowość i zakres tematyczny pasuje bardziej na artykuł w piśmie branżowym niż na sylabus. Ciężko sobie wyobrazić certyfikowanie się z dwudziestoczterostronicowego artykułu. Pytania egzaminacyjne nie sięgają przecież poza sam sylabus. Na potrzeby zdania certyfikatu musimy więc nauczyć się przeglądu praktyk rynkowych, sugerowanych przez autorów sylabusa.
Jest to kolejny, bardzo słaby sylabus ze stajni ISTQB, którego istnienie trudno wytłumaczyć, a rolę trudno zdefiniować.
Dokument do pobrania.
