Wokół Quality Assurance (QA) narosło tyle nieporozumień i mitów, że można by tylko o tym napisać cały artykuł. W tym tekście wspomnę też o genezie tych problemów. Przede wszystkim pokażę Ci na konkretach, na czym polega zapewnienie jakości oprogramowania.
Zaraz zaczniemy, ale najpierw…
To nie jest śmieszne. Faktycznie spotykałem się z wyrażeniami:
- poQAuj te nowe funkcjonalności,
- zrób QA na tym,
- czy po angielsku: can you do some QAing on this?
Te wyrażenia nie tylko brzmią dziwnie, ale też są całkowicie błędne. QA to proces. To nie jest coś, co można wykonać na kawałku oprogramowania.
Skąd to się bierze?
Zainteresowanie testowaniem oprogramowania na dużą skalę rozpoczęło się kilkanaście lat temu. Wtedy to pojawiły się pierwsze kursy dla testerów. Można też było zdawać egzamin ISTQB w j. polskim. Firmy zaczęły zatrudniać specjalistów na stanowiska testerskie.
I tu pojawił się problem. Bo wyrażenie „Tester” brzmi mało profesjonalnie na tle innych stanowisk w IT. Więc świat informatyczny chętnie przyjął termin: zapewnienie jakości oprogramowania (QA), bo wygląda to dużo lepiej. Zaczęli pojawiać się QA Inżynierowie, QA testerzy automatyzujący i inne kombinacje. Często jednak chodzi o zwykłe testowanie.
Jaki jest więc związek między zapewnieniem jakości a testowaniem oprogramowania?
Czy jakość bierze się z testowania?
Wybierzmy się na jazdę próbną. Możesz wybrać model samochodu.
Wsiadasz, jedziesz, testujesz. Na koniec masz sporo informacji:
- czy taka wersja silnikowa wystarczy,
- czy taki rozmiar jest ok, a może potrzebujesz czegoś innego,
- czy wykończenie odpowiada Twoim standardom,
- itd.
Masz informacje.
Ale czy to cokolwiek zmienia w samochodzie? Nie!
Jakość samochodu się nie zmienia. Być może w kolejnym modelu zostaną wprowadzone poprawki i udoskonalenia, kto wie.
Tak samo jest z oprogramowaniem.
Jeżeli zatrudnisz zespół najlepszych testerów, którzy wykryją 1000 błędów, to wiesz, że oprogramowanie ma 1000 błędów (minimum). Nie zmienia to jakości oprogramowania. Nie zapewnia te jakości.
Taki proces dostarcza jedynie informacji, które pomagają podejmować decyzje.
QC to testowanie – to nie jest zapewnienie jakości oprogramowania
Testowanie, czyli Quality Control (QC) jest więc częścią procesu zapewnienia jakości. Dzięki testom wiadomo na ile proces QA jest skuteczny i gdzie są słabe punkty.
Zasadnicza różnica polega też na tym, że:
- testowanie jest procesem reaktywnym, czyli ocenia stan po wytworzeniu oprogramowania,
- zapewnienie jakości to przede wszystkim procesy proaktywne, czyli próba poprawy jakości w trakcie wytwarzania.
Czym zajmuje się Quality Assurance w IT?
Niektóre źródła podają, że zapewnienie jakości oprogramowania to przede wszystkim automatyzacja (np. ten artykuł). Testowanie, nawet zautomatyzowane, pozostaje testowaniem.
Temat jest dużo bardziej złożony.
Czym jest jakość?
Jakość to stopień spełnienia oczekiwań klienta. Oprogramowanie, które ma sporo błędów technicznych (w kodzie) może być wysokiej jakości. O ile te błędy nie wpływają na podstawowe procesy realizowane przez klienta.
Błędne zachowanie jest więc wtedy, gdy:
- nie działa coś, co według ustaleń/specyfikacji powinno działać,
- oprogramowanie posiada funkcjonalności, których nie powinno być (nawet, jak technicznie są ok),
- oprogramowanie nie posiada funkcjonalności, których nie było w specyfikacji, ale powinny być, aby wspierać procesy klienta (!),
- oprogramowanie jest funkcjonalnie ok, ale jest trudne w użyciu, wolne itd.
Jak i gdzie powstają błędy oprogramowania?
Przyczyną powstawania błędów najczęściej jest człowiek. Poprzez nieuwagę, brak umiejętności, pośpiech itp. popełniamy pomyłki, które potem przekładają się na awarie systemów.
Wbrew pozorom błędy nie są jedynie wynikiem pomyłek w trakcie kodowania. Według publikacji Quantifying Software (2018 CRC Press) autorstwa Capers Jones’a, błędy najczęściej mają źródło w:
- błędnym kodzie (27%),
- błędach w architekturze i projektowaniu (25%),
- wymaganiach (16,5%),
- nieprawidłowym naprawianiu zgłoszonych błędów (15%),
- dokumentacji (10,5%)
Te wyniki potwierdzają codzienne realia. Nawet najlepszy zespół programistów nie uniknie błędów, jeżeli dokumentacja czy design będą zawierały błędy.
Zapewnienie jakości oprogramowania zanim jeszcze wystartuje projekt
Skoro to człowiek jest często źródłem błędów, to zapewnienie jakości oprogramowania może zacząć się jeszcze zanim powstanie pierwsza linijka kodu.
I zanim w ogóle zacznie się projekt.
Działania, które pomogą podnieść jakość przyszłych projektów to na przykład:
- udział w szkoleniach i konferencjach,
- analizowanie wniosków z zakończonych projektów (a wcześniej spisywanie tych wniosków!),
- testowanie różnych narzędzi, które usprawnią proces i zmniejszą liczbę pomyłek,
- wprowadzenie standardów i sposobów pracy, które podnoszą jakość (na przykład przeglądy, statyczna analiza kodu itp.),
- szukanie możliwości automatyzacji tam gdzie to możliwe.
Między jednym a drugim projektem warto więc podsumować efekty i poszukać możliwych usprawnień w przyszłości.
Quality Assurance na etapie analizy i projektowania
Pierwsze tygodnie po starcie projektu są decydujące jeżeli chodzi o zapewnienie jakości oprogramowania. Efekty analizy i projektowania przekładają się na późniejsze błędy w trakcie wytwarzania.
Na tym etapie możesz zapewnić wysoką jakość oprogramowania przykładowo poprzez:
- potwierdzenie z interesariuszami projektu, że wymagania są tak samo rozumiane przez wszystkich zaangażowanych w projekt (na przykład techniką User Story Mapping),
- zaplanowanie i wykonywanie przeglądów dokumentacji, architektury i innych składowych projektu (tu więcej na temat przeglądów),
- jak najwcześniejsze sprawdzenie parametrów technicznych, np. czy w ogóle będzie możliwe osiągnięcie określonej szybkości odpowiedzi systemu,
- zweryfikowanie czy i jak będzie możliwe zintegrowanie się z wszystkimi wymaganymi systemami, tak aby wykryć ewentualne problemy jak najwcześniej,
- przygotowanie niezbędnych narzędzi, takich jak:
- narzędzia wspierające przeglądy, czy statyczną analizę kodu,
- narzędzia do zarządzania i wykonywania testów,
- narzędzia do monitorowania systemów itp.
- ustalenie procesu wytwarzania oprogramowania tak, aby zwiększał szanse na osiągnięcie wysokiej jakości (np. częste przeglądy z klientem),
- dobranie zespołu według kompetencji technicznych oraz umiejętności miękkich, które w połączeniu dadzą najlepsze efekty.
Zapewnianie jakości w trakcie procesu wytwarzania
W trakcie budowania systemu wykonywane są oczywiście różnego rodzaju przeglądy i testy. Ważne jest, aby poza testowaniem i naprawianiem błędów szukać cały czas proaktywnych możliwości poprawy jakości. Na przykład poprzez zmianę procesu, podnoszenie kompetencji itp.
Na tym etapie wysoką jakość zapewnią na przykład:
- częste przeglądy kodu i dokumentacji,
- zbieranie i wdrażanie dobrych praktyk, standardów programistycznych,
- udział w szkoleniach, wymiana wiedzy w zespole,
- testowanie automatyczne w procesie CI/CD,
- statyczna analiza jakości kodu,
- dokumentowanie systemu, dzięki czemu wprowadzanie kolejnych zmian będzie dużo łatwiejsze i bezpieczniejsze,
- testowanie manualne, eksploracyjne, akceptacyjne itp.
- weryfikowanie parametrów poza-funkcjonalnych, np. czasów odpowiedzi, intuicyjności, bezpieczeństwa,
- monitorowanie parametrów systemu (tu przeczytasz jak ustawić monitoring w 5 minut),
- monitorowanie całego procesu – wdrożenie systemu metryk projektowych i jakościowych i reagowanie na negatywne odchylenia.
Zapewnienie jakości oprogramowania – podsumowanie
Zapewnienie jakości oprogramowania to złożony i czasochłonny proces. A zakres tych działań zdecydowanie wykracza poza testowanie.
Jednak dobrze przeprowadzona inwestycja w Quality Assurance z czasem się zwraca i zwiększa szanse na końcowy sukces projektu.
Epilog: poprawa jakości zgłaszanych błędów
Błędy oprogramowania często wynikają z nieprawidłowej naprawy wcześniej wykrytych błędów (15%). Dlatego też prawidłowe raportowanie błędów jest niezwykle ważne. Dzięki temu ich naprawa będzie prostsza, szybsza i bardziej skuteczna.
O tym jak prawidłowo zgłaszać błędy oprogramowania, aby zwiększyć szansę na ich naprawę już za pierwszym razem przeczytasz w handbooku „Bug reporting: Submig issues like a pro”
