Redakcja
To może być znak czasów, ale też konieczność projektowa, że testerzy nie zamykają się już w swoich rolach i coraz śmielej sięgają po coraz większą odpowiedzialność. Już nie tylko kontrolujemy jakość, ale również wpływamy na nią.
Zapewnienie jakości (Quality Assurance) jest pojęciem o wiele szerszym od testowania (Quality Control). Zapewnienie jakości ma "wyższe cele od testowania". Kiedy testowanie koncentruje się na pojedynczym produkcie, zapewnienie jakości dba o jakość wszystkich wytwarzanych produktów. - http://www.testerzy.pl/artykuly/zapewnienie-jakosci-testowanie
Jakie „nowe”czynności uczynią z Ciebie specjalistę zapewnienia jakości?
(Re)definiowanie procedur pracy
W naszej codziennej pracy jest wiele obszarów, które można poprawiać. Proces i procedury nigdy nie będą doskonałe, ale mogą mieć większą skuteczność w zapewnieniu jakości. Tester, dzięki swojej unikalnej perspektywie jakości, może szukać usprawnień, które doprowadzą do szybszego dostarczenia lepszego oprogramowania. Z jednej strony mamy modele bardziej kaskadowe, w których proces może być poprawiany, a z drugiej podejścia zwinne, w których przy pomocy np. spotkań retrospektywnych możemy wraz z zespołem szukać obszarów do optymalizacji.
Pilnowanie działań projektowych
Zarówno ciężkie jak i miękkie metodyki mają zbiór aktywności i ceremonii, które muszą być wykonywane. Zgodnie z metodami twórców podejść zarzucenie nawet pojedynczych działań wpłynie na jakość produktu. Role, które zostały zdefiniowane jak QA manager czy Scrum Master, mogą być obsadzone testerami, którzy ze swoim podejściem projakościowym przypilnują, by nie rezygnować z aktywności, które mają prowadzić projekt ku działającemu oprogramowaniu.
Definiowanie miar
Przy współczesnych podejściach do wytwarzania oprogramowania jedyną słuszną miarą staje się działające oprogramowanie. Istnieje jednak wiele nowych metryk, które pozwalają nam nie tylko pokazywać jakość oprogramowania, ale również skuteczność naszych działań. Często to testerzy zbierają miary lub je przetwarzają i to oni mogą pomagać w ich definicji. Odejście od klasycznych miar, które pokazują statusy wykonanej pracy na rzecz miar, które wskazują efektywność działań projektowych i jakości półproduktów może być kolejnym działaniem na korzyść jakości. Przeorientowanie swoich celów z chronienia jakości do koncentrowaniu się na dostawie (oczywiście bez pogorszenia jakości) jest znaczącym krokiem w rozwoju roli testera.
Wdrożenie piramidy testów
Powszechnie omawiana piramida testów mówi, że najwięcej testów powinno być wykonywanych na najniższych warstwach oprogramowania. Powinniśmy więc zacząć od testów jednostkowych i integracyjnych, a na samych interfejsach graficznych jedynie potwierdzać, że działa to, co wcześniej już zweryfikowaliśmy. Oznacza to wcześniejsze zaangażowanie testerów, ale też przesunięcie ich odpowiedzialności do obszarów tradycyjnie zarezerwowanymi dla programistów (shift left). Oczywiście wiąże się to z gruntownym redefiniowaniem kompetencji testerskich i chociażby nauką kodowania.
Analiza przyczyny podstawowej (root cause analysis)
Długo w testowaniu mówiło się, że testerzy nie są po to, aby określać skąd wzięła się dana awaria. Zaczęło się to zmieniać i dziś nie wystarczy powiedzieć, że „nie działa”, trzeba również określić „co nie działa”. Odpowiedzialnością współczesnego testera staje się więc nie tylko zaraportowanie defektu, ale również analiza, która pozwoli nam zrozumieć dlaczego powstała awaria (o tym w następnym punkcie).Ta zmiana w nastawieniu czyni naszą rolę skrajnie niezbędną, a rolę programisty korygującego oprogramowania redukuje do mechanicznego wykonania poprawki w miejscu jakie wskazaliśmy.
Wdrożenie czynności prewencyjnych
Skoro analiza przyczyny pozwala nam zrozumieć skąd wzięła się awaria, to głębsza analiza zbiorów danych może doprowadzić nas do pomysłu co zrobić, aby te awarie nie powstawały. Nie musimy więc już tylko dmuchać w gwizdek kiedy coś się wydarzy, ale możemy prewencyjnie zapobiegać zdarzeniom i incydentom. Nie jest to proste, ale wpisuje się w wiele przytoczonych wcześniej nowych odpowiedzialności testera jak redefiniowanie procedur pracy.
Zestaw nowych odpowiedzialności nie ogranicza się tylko do tych przytoczonych wcześniej. Mamy jeszcze wiele innych, jak próba zastąpienia lub uzupełnienia pracy analityka poprzez bezpośrednią rozmowę z osobą zlecającą wytworzenie softwareu. Współczesne projekty informatyczne nakazują nam redefinicję naszych odpowiedzialności. To czy odbije się to na zmniejszeniu zaangażowania w bardziej tradycyjne czynności (jak szukanie defektów) i w konsekwencji na pogorszenie jakości zależy już od zespołów i kierujących nimi ludźmi. Podążanie z duchem czasu pozwoli zagospodarować więcej nieużytków projektowych, czyli obszarów, które mają wpływ na jakość, ale ze względu na ograniczenia budżetowe i czasowe nie są realizowane (jak permanentnie ignorowany dług technologiczny).
Grzegorz Ler
