Po słowach krytyki i wsparcia dotyczących mojego poprzedniego postu postanowiłem opisać spojrzenie od strony klienta / stakeholderów dotyczących jakości oprogramowania.

Odpowiedź na pytanie postawione w tytule postu w przypadku zadania go osobie związanej z QA będzie jednoznaczna – należy konkurować jakością.

Odpowiedź zarządu firmy nie będzie już jednoznaczna. Zanim zaczniemy projekt firma musi go wygrać. Projekty w uproszczeniu wygrywa się według kryterium najlepszej oferty. Co składa się na ocenę najlepszej oferty?

  1. Cena
  2. Termin zakończenia projektu
  3. Doświadczenie zespołu/firmy w podobnych projektach
  4. Proponowany proces zapewnienia jakości
  5. Zaproponowany proces wytwarzania oprogramowania, a w szczególności:
    • Ilość zautomatyzowanych procesów wytwarzania oprogramowania (CI/CD/testy automatyczne)
    • Częstotliwość dostarczania nowych funkcjonalności dla użytkownika końcowego
    • Przejrzystość procesu tworzenia oprogramowania

Pomijam celowo w tym poście proces zbierania i analizy wymagań funkcjonalnych i niefunkcjonalnych dla produktu. To zasługuje na osobny post.

O ile jako QA nie mamy bezpośredniego wpływu na pierwsze trzy punkty, o tyle możemy zrobić sporo w punkcie 4 oraz 5.


Proces wytwarzania oprogramowania

Definicję Antifragile (antykruchości) opisał pan Nassim Nocholas Taleb w swojej książce pt. Antifragile. Opowiada przez porównanie i analogię do mięśni i pralki. Mięśnie pracują i stają się lepsze przez ćwiczenia (w myślach zapewne skrócił czas obserwacji do kilku-kilkunastu lat). Pralka natomiast zużywa się z każdym uruchomieniem. Jak wygląda oprogramowanie?

Według autora oprogramowanie staje się lepsze w trakcie jego używania (znów skrót myślowy, który zakłada że ktoś naprawia bugi i dodaje nowe funkcjonalności). Klient zgłasza usterkę – programiści ją naprawiają. Klient prosi o dodatkową funkcjonalność – developerzy ją dodają.

Jak polepszyć ten nieunikniony proces ciągłych zmian i wychodzących błędów? Można na przykład wytwarzać oprogramowanie bez bugów 🙂

A w realnym świecie widzę tutaj dwie ścieżki, które łącznie odnoszą niezłe rezultaty

  1. Agile development
  2. Przejrzystość i wgląd w aktualny stan postępów (nawet dla klienta)
  3. Częsty deployment
  4. Testowanie (w tym automatyczne) + testy eksploracyjne

Specjalistą od metodyk zwinnych nie jestem, więc napiszę krótko: Dopasowywanie się do zmieniających się potrzeb klientów uważam za dobre biznesowo rozwiązanie. I zaliczyłbym je do praktyk Antifragile.

Częsty deployment rozwiązuje dobry proces CI/CD (w tym testy jednostkowe). To kolejny filar podpierający oprogramowanie.

Przejrzystość (wgląd w to co zespół aktualnie robi, też daje klientowi poczucie bezpieczeństwa i monitorowania postępu) udało nam się ogarnąć namawiając klienta do używania Jiry, VSTS (lub innych) aplikacji do zarządzania procesem wytwarzania oprogramowania.

Procesowi zapewnienia jakości poświęcę pełny akapit…


Proces zapewnienia jakości

Jak być Antifragile w procesie zapewnienia jakości? Skoro technologia jest z natury delikatna?

Weźmy na przykład dwie firmy:

Firma #1: Posiada bardzo dobrych testerów manualnych i generuje 3 raporty tygodniowo z testów nowych funkcjonalności. Raporty te są bardzo dokładnym obrazem aktualnego stanu  aplikacji. Do tego raz w miesiącu (przez tydzień) wykonują testy regresyjne, z których raporty są przesyłane do klienta. Aplikacja jest wdrażana na produkcję po potwierdzeniu przez zespół testerski, że wszystkie znalezione defekty krytyczne zostały naprawione i przez ostatni cykl testowania nie znaleziono nowych.

Firma #2: Posiada wdrożony proces CI/CD, codzienne buildy, testy jednostkowe i testy automatyczne E2E. Raporty generowane są automatycznie, testerzy nie wykonują testów regresji a jedyne testy manualne to testy eksploracyjne.

Która z firm będzie lepiej postrzegana przez klienta (poprzez klienta rozumiem w tym przypadku stakeholderów w postaci biznesu i sponsorów projektu)? Która z firm będzie lepiej postrzegana przez menadżerów? Która firma będzie postrzegana lepiej przez testerów/developerów (i czy dobre postrzeganie przez dev/test team jest Antifragile?)

Która z firm znajdzie więcej błędów i szybciej opisze i przekaże zespołowi developerów do naprawy? Czy klient docenia „jakość” znalezionych bugów?

Jakimi umiejętnościami powinien charakteryzować się członek zespołu firmy #1 i firmy #2?

Nie ma jednego uniwersalnego przepisu, żeby odnieść sukces i zarobić $. Możemy tylko dobierać różne rozwiązania do konkretnego projektu.

W książce Antifragilie – Things that gain from disorder autor proponuje kilka rozwiązań aby zadowolić klienta i menadżerów:

  1. Test Driven Development – najpierw piszemy testy, później implementujemy funkcjonalności
  2. Bus Factor – jeżeli główny developer zostanie potrącony przez autobus – czy istnieje zagrożenie że cały projekt nie zostanie ukończony? Autor sugeruje częste zmiany stanowisk i zmiany w składzie zespołu, po to żeby wiedza nie koncentrowała się w głowach pojedyńczych osób.
  3. Conway’s Law – cytując prawo „Organizacje, które projektują system są ograniczone do tworzenia projektów będących kopiami struktur organizacyjnych tych organizacji”. W skrócie – tak samo jak komunikuje się developer A (tworzący moduł A) z developerem B (tworzącym moduł B) – tak samo będą komunikować się ich moduły. Czasem z premedytacją możemy złamać
  4. Zatrudniaj ludzi „T-shaped skilled„, którzy potrafią być elastyczni w swoich rolach. Takie funkcje jak testops, devops, programiści piszący testy (automatyzujący) i testerzy piszący unit testy lub testy integracyjne to rzadkość na polskim rynku, ale na pewno dobry nabytek dla projektu. Tester powinien być mistrzem w testowaniu, ale nie przeszkadza to w byciu juniorem w programowaniu (i odwrotnie).
  5. Stawianie celów, ale bycie elastycznym w drodze do niego. To że mamy 4 bugi P2, które znaleźliśmy w zakamarkach aplikacji, do której zagląda jeden użytkownik nie powinno blokować aplikacji do wdrożenia na produkcję.
  6. Szanujcie się (usuwajcie problemy które zgłaszacie wewnątrz zespołu) i znajdźcie balans pomiędzy oczekiwaniami klientów, a oczekiwaniami zespołu.