Czym jest SDLC i jak wspiera QA w projekcie?

Gdy aplikacja rośnie, sama dobra praca programistów przestaje wystarczać. Potrzebny jest uporządkowany sposób planowania, budowania, testowania i utrzymywania produktu. SDLC, czyli cykl życia tworzenia oprogramowania, pomaga przeprowadzić projekt od pierwszego pomysłu do bezpiecznej eksploatacji, a procesy QA sprawiają, że jakość nie jest sprawdzana dopiero tuż przed premierą.

Czym jest SDLC i po co stosuje się ten proces

SDLC to skrót od Software Development Life Cycle, czyli cyklu życia oprogramowania. Najprościej mówiąc, opisuje on kolejne działania potrzebne do stworzenia, uruchomienia i rozwijania systemu. Nie jest pojedynczym narzędziem ani językiem programowania. To sposób organizacji pracy zespołu.

W praktyce SDLC odpowiada na kilka bardzo konkretnych pytań. Co właściwie budujemy? Dla kogo? Jak sprawdzimy, czy rozwiązanie działa? Kto podejmuje decyzję o wydaniu produktu? Co dzieje się po premierze? Bez takich ustaleń projekt szybko zamienia się w serię doraźnych decyzji, a błędy wychodzą na jaw dopiero wtedy, gdy ich usunięcie jest kosztowne.

W tym znaczeniu skrót SDLC dotyczy rozwoju oprogramowania. W innych obszarach może oznaczać także protokół komunikacyjny, dlatego kontekst ma znaczenie. W firmach tworzących aplikacje, systemy webowe czy rozwiązania mobilne niemal zawsze chodzi jednak o Software Development Life Cycle.

Moim zdaniem największą wartością SDLC nie jest sama lista faz. Istotniejsze jest to, że zespół wie, jakie decyzje powinny zapaść przed rozpoczęciem kolejnego etapu. Dzięki temu łatwiej kontrolować zakres, ryzyko, koszty i jakość.

Jak wyglądają najważniejsze etapy cyklu życia oprogramowania

Poszczególne organizacje mogą nazywać fazy nieco inaczej albo łączyć je w większe obszary. Najczęściej spotyka się jednak siedem etapów. Nie zawsze przebiegają one liniowo. W Agile wiele z nich powtarza się w krótkich iteracjach, czyli cyklach trwających na przykład od 1 do 4 tygodni.

Planowanie i wymagania

Dobry projekt zaczyna się od zrozumienia problemu, a nie od wyboru frameworka. Na tym etapie zespół ustala, jaki efekt biznesowy ma przynieść oprogramowanie, kto będzie z niego korzystał i po czym poznać, że zadanie zostało wykonane poprawnie.

Wymagania powinny być możliwie konkretne. Zamiast zapisu „system ma działać szybko” lepiej określić, że na przykład 95% odpowiedzi API ma pojawić się w czasie krótszym niż 500 milisekund przy ustalonym obciążeniu. Takie kryterium można później sprawdzić podczas testów.

Projektowanie i implementacja

Projektowanie obejmuje między innymi architekturę, model danych, interfejs użytkownika, integracje oraz zabezpieczenia. Na tym etapie opłaca się podjąć decyzje, które ograniczą późniejsze przeróbki. Błąd w wymaganiach lub architekturze zwykle kosztuje znacznie więcej niż błąd znaleziony podczas przeglądu makiety.

Implementacja nie powinna oznaczać pracy programistów w izolacji. Przeglądy kodu, kontrola wersji, analiza statyczna i automatyczne sprawdzanie zmian pozwalają wykrywać problemy jeszcze przed przekazaniem funkcji do testów.

Testowanie, wdrożenie i utrzymanie

Testowanie służy nie tylko wyszukiwaniu błędów. Sprawdza również, czy produkt realizuje potrzeby opisane w wymaganiach i czy nie pogorszył działania istniejących funkcji. Po wdrożeniu praca się nie kończy. Logi, monitoring, zgłoszenia użytkowników i analiza incydentów dostarczają informacji do kolejnych iteracji.

Właśnie dlatego określenie „koniec projektu” bywa mylące. W przypadku systemu rozwijanego przez lata SDLC jest raczej ciągłym cyklem uczenia się i poprawiania produktu niż jednorazową ścieżką od pomysłu do premiery.

Jaką rolę odgrywa QA w cyklu SDLC

QA, czyli Quality Assurance, oznacza zapewnianie jakości. To szersze pojęcie niż samo testowanie, ponieważ obejmuje również procesy, standardy, zapobieganie błędom i ocenę sposobu pracy zespołu. Tester manualny lub automatyzujący jest ważną częścią QA, ale nie wyczerpuje całego obszaru.

Najlepsze zespoły angażują QA już przy analizie wymagań. Osoba odpowiedzialna za jakość może wtedy wychwycić niejasne kryteria akceptacji, brakujące scenariusze brzegowe albo ryzyko związane z prywatnością i bezpieczeństwem. Im wcześniej znajdziemy problem, tym mniej kosztuje jego naprawa.

Testy na różnych poziomach

W SDLC stosuje się kilka poziomów testów, ponieważ każdy z nich odpowiada na inne pytanie:

• Testy jednostkowe sprawdzają małe fragmenty kodu, na przykład pojedynczą funkcję.
• Testy integracyjne weryfikują współpracę modułów, baz danych i zewnętrznych usług.
• Testy systemowe oceniają działanie całej aplikacji z perspektywy określonych scenariuszy.
• Testy akceptacyjne odpowiadają na pytanie, czy produkt spełnia potrzeby biznesowe.
• Testy regresji sprawdzają, czy nowa zmiana nie zepsuła wcześniej działających funkcji.
• Testy wydajnościowe i bezpieczeństwa oceniają zachowanie systemu pod obciążeniem oraz jego odporność na zagrożenia.

Automatyzacja jest szczególnie przydatna przy testach powtarzalnych, takich jak regresja czy walidacja API. Nie zastąpi jednak całkowicie testów eksploracyjnych, w których tester świadomie wychodzi poza przygotowany scenariusz i szuka nieoczywistych zachowań. Z mojego doświadczenia wynika, że najlepszy efekt daje połączenie automatyzacji z ludzką oceną użyteczności.

Shift-left i jakość współdzielona przez zespół

Określenie shift-left oznacza przesuwanie kontroli jakości na wcześniejsze etapy procesu. W praktyce może to być wspólne omawianie wymagań, testy uruchamiane przy każdym pull requeście, analiza kodu oraz weryfikacja bezpieczeństwa przed wdrożeniem.

QA nie powinno być ostatnią bramką, przez którą każda funkcja przechodzi tuż przed publikacją. Odpowiedzialność za jakość ponoszą analitycy, projektanci, programiści, testerzy i właściciel produktu. Taki model zmniejsza liczbę niespodzianek, ale wymaga dobrej komunikacji i gotowości do poprawiania procesu.

Modele SDLC i sytuacje, w których mają sens

Model SDLC określa, jak zespół przechodzi przez poszczególne etapy. Nie wybierałbym go na podstawie mody ani nazwy używanej w ofertach firm. Najpierw trzeba ocenić, jak stabilne są wymagania, jak kosztowny jest błąd i jak często produkt będzie się zmieniał.

Waterfall może być rozsądnym wyborem tam, gdzie zakres jest dobrze opisany, a zmiana wymagań jest droga, na przykład w części projektów regulowanych. W przypadku aplikacji konsumenckiej, której funkcje trzeba szybko sprawdzać na rynku, lepiej sprawdza się praca iteracyjna.

Agile nie oznacza braku planu, a DevOps nie jest wyłącznie zestawem narzędzi. W obu podejściach liczą się krótkie pętle informacji zwrotnej, odpowiedzialność za efekt i zdolność do bezpiecznego reagowania na zmianę. Samo używanie tablicy z zadaniami nie czyni procesu zwinnym.

Jak wdrożyć SDLC w zespole bez tworzenia biurokracji

Najłatwiej zacząć od prostego przepływu, który odpowiada realnej pracy zespołu. Nadmiar dokumentów może spowolnić projekt, ale całkowity brak ustaleń prowadzi do chaosu. Potrzebny jest poziom formalizacji dopasowany do ryzyka.

1. Określ cel produktu i mierzalne kryteria sukcesu.
2. Ustal, kto podejmuje decyzje dotyczące zakresu, jakości i wdrożenia.
3. Podziel wymagania na małe elementy, które można zbudować i sprawdzić.
4. Zdefiniuj kryteria akceptacji przed rozpoczęciem implementacji.
5. Dodaj do procesu przeglądy kodu, automatyczne testy i kontrolę wersji.
6. Ustal warunki wydania, plan wycofania zmiany oraz sposób monitorowania systemu.
7. Po wdrożeniu analizuj defekty i incydenty, a potem poprawiaj proces.

W małym zespole wystarczy często krótka karta funkcji, lista kryteriów akceptacji, przegląd kodu i podstawowy zestaw testów automatycznych. W systemie obsługującym dane finansowe lub medyczne potrzebne będą dodatkowe kontrole, ślad audytowy, testy bezpieczeństwa i jasno opisane uprawnienia.

Częsty błąd polega na mierzeniu wyłącznie liczby zadań zakończonych przez programistów. Lepszy obraz dają takie wskaźniki jak liczba defektów po wdrożeniu, czas przywrócenia usługi, częstotliwość wydań i odsetek testów zakończonych sukcesem. Żaden pojedynczy parametr nie opisze jakości, dlatego należy patrzeć na kilka sygnałów jednocześnie.

Przeczytaj również: ATDD - Jak poprawić jakość i komunikację w zespole?

Co najczęściej psuje proces

• Rozpoczynanie kodowania przed doprecyzowaniem problemu i kryteriów akceptacji.
• Traktowanie testów jako etapu wykonywanego wyłącznie na końcu projektu.
• Automatyzowanie testów bez utrzymywania ich jakości, przez co zespół zaczyna ignorować fałszywe alarmy.
• Brak środowiska zbliżonego do produkcyjnego.
• Wydawanie zmian bez monitoringu, planu wycofania i osoby odpowiedzialnej za reakcję.
• Przekonanie, że Agile pozwala pomijać dokumentację, analizę ryzyka i testy.

Co SDLC daje firmie i gdzie ma swoje granice

Dobrze zaprojektowany cykl ogranicza nieporozumienia, pomaga wcześniej wykrywać ryzyka i ułatwia przewidywanie pracy. Daje także wspólny język osobom biznesowym, projektantom, programistom i zespołom QA. Dzięki temu decyzja o wydaniu wynika z określonych warunków, a nie wyłącznie z presji terminu.

SDLC nie zagwarantuje jednak sukcesu produktu. Nie zastąpi rozmów z użytkownikami, trafnego modelu biznesowego ani kompetentnego zespołu. Można mieć bardzo szczegółowy proces i nadal budować funkcję, której nikt nie potrzebuje. Proces porządkuje pracę, ale nie podejmuje za ludzi właściwych decyzji.

Granice widać również przy projektach wykorzystujących uczenie maszynowe. W takim przypadku trzeba kontrolować nie tylko kod, lecz także dane treningowe, jakość predykcji, dryf modelu i wpływ zmian na wyniki. Klasyczny SDLC nadal pomaga, ale wymaga rozszerzenia o monitorowanie zachowania modelu po wdrożeniu.

Najrozsądniej traktować SDLC jako elastyczny szkielet. Powinien zapewniać powtarzalność, widoczność ryzyka i szybki feedback, ale nie może zamieniać się w procedurę, której zespół przestrzega tylko po to, by odhaczyć kolejne punkty.

Najlepszy SDLC to taki, który pomaga wcześniej podejmować decyzje

Odpowiedź na pytanie, czym jest SDLC, można zamknąć w jednym zdaniu: to uporządkowany cykl tworzenia i utrzymywania oprogramowania, obejmujący pracę od wymagań po eksploatację. Jego praktyczna wartość rośnie wtedy, gdy QA uczestniczy w projekcie od początku, a testowanie, bezpieczeństwo i monitoring są częścią codziennego przepływu pracy.

Przy wyborze modelu nie szukałbym rozwiązania idealnego. Lepiej zacząć od prostego procesu, zmierzyć jego efekty i poprawiać go na podstawie danych. Dobry SDLC nie spowalnia zespołu, tylko ogranicza kosztowne poprawki i pozwala bezpieczniej dostarczać zmiany użytkownikom.