SygnITy Expert
Od analizy, przez prace deweloperskie, po testy oprogramowania – jak powstaje
Wstęp
Bramka KSeF to warstwa integracyjna pomiędzy systemami klienta a Krajowym Systemem e-Faktur, odpowiadająca za ciągłość, bezpieczeństwo i zgodność procesów fakturowania z obowiązującymi regulacjami. Jej stabilność ma bezpośredni wpływ na funkcjonowanie kluczowych procesów finansowych organizacji.
To rozwiązanie jest wynikiem wielu uzgodnień realizowanych na kolejnych etapach projektu. Jego jakość nie wynika z pracy jednej osoby ani pojedynczej decyzji, lecz ze współpracy zespołu, który patrzy na system z kilku perspektyw jednocześnie.
Analityk mapuje wymagania na rzeczywiste ścieżki biznesowe, minimalizując ryzyka. Deweloper projektuje rozwiązanie tak, aby działało stabilnie nawet w zmiennym i nieprzewidywalnym środowisku, a testerzy sprawdzają, jak całość zachowa się w codziennych scenariuszach użycia – tam, gdzie niezbędna jest ciągłość operacji finansowych.
Choć każdy etap pracy wygląda inaczej i wnosi inną wartość, wszystkie prowadzą do jednego celu: stabilnego i bezpiecznego działania procesów finansowych klienta w rzeczywistych warunkach biznesowych. Dopiero połączenie tych działań pozwala zbudować rozwiązanie, które nie tylko spełnia wymagania, ale jest gotowe na zmiany, nieprzewidziane sytuacje i codzienne użycie.
W efekcie, gdy aplikacja jest już gotowa do użycia, rzadko widać skalę prac przygotowawczych, które doprowadziły ją do wersji produkcyjnej. Analiza zmieniających się wymagań, projektowanie odpornego rozwiązania, bieżące uzgodnienia między zespołami oraz testy w realistycznych scenariuszach to działania, które odbywają się w tle projektu.
Choć niewidoczne dla użytkownika, mają bezpośredni wpływ na stabilność i bezpieczeństwo aplikacji. To właśnie dzięki nim gotowe rozwiązanie jest intuicyjne, przewidywalne i odporne na codzienne wyzwania. Ta praca zespołu, realizowana poza ekranem użytkownika, decyduje o tym, czy aplikacja sprawdzi się nie tylko w dniu wdrożenia, ale również w długofalowym, codziennym użyciu.
Analiza – jak powstają wymagania i dlaczego mają kluczowe znaczenie dla projektu
Analiza w projekcie Bramki KSeF to nie tylko przygotowanie dokumentacji. To etap, podczas którego wymagania regulatora są konfrontowane z realnymi procesami biznesowymi oraz możliwościami technicznymi rozwiązania.
Choć sam produkt nie jest skomplikowany funkcjonalnie, największym wyzwaniem okazała się zmienność dokumentacji po stronie regulatora. Specyfikacja KSeF nie była dokumentem statycznym – schematy, interpretacje i założenia procesowe zmieniały się w czasie. W praktyce oznaczało to konieczność ciągłego aktualizowania analizy i podejmowania decyzji pod presją czasu.
Z tego powodu analiza nie mogła być traktowana jako zamknięty etap projektu. Wymagania były na bieżąco weryfikowane, aktualizowane i konfrontowane z realiami wdrożeniowymi, równolegle z trwającymi pracami deweloperskimi i testowymi.
Dobrym przykładem tej zmienności był etap realizacji projektu trwający w czasie gdy nie istniała jeszcze specyfikacja KSeF 2.0. Rozwiązanie zostało udokumentowane analitycznie a następnie zakończone dewelopersko, jednak po około roku (pojawienie się nowej specyfikacji KSeF) projekt musiał wrócić do fazy analizy i dewelopmentu w celu przeprojektowania. Okazało się, że pomiędzy wcześniejszą a nową specyfikacją występowały istotne różnice, których nie dało się obsłużyć jedynie poprzez drobne poprawki. Wymagało to cofnięcia się do wcześniejszych założeń i ponownego zaprojektowania części mechanizmów.
Dodatkowym czynnikiem wpływającym na analizę była zmiana zespołu deweloperskiego (długi okres trwania projektu wpłynął na zmiany osobowe w zespole). W takiej sytuacji rola analityka polegała nie tylko na aktualizacji dokumentacji, ale również na utrzymaniu spójności wiedzy projektowej i zapewnieniu ciągłości rozumienia założeń systemu.
W ostatnim etapie projektu szczególnym wyzwaniem była presja czasu. Finalna wersja specyfikacji została opublikowana w grudniu, co oznaczało bardzo krótki okres na analizę zmian, ich implementację oraz przygotowanie rozwiązania do wdrożenia produkcyjnego. W tym czasie prace analityczne, deweloperskie i testowe toczyły się równolegle, co wymagało stałej synchronizacji zespołów.
Istotne zmiany dotyczyły m.in. procesu importu i eksportu faktur oraz sposobu pobierania UPO. W praktyce oznaczało to konieczność przeprojektowania części mechanizmów i dostosowania ich do innych scenariuszy obsługi. Zmiany te miały bezpośredni wpływ na harmonogram projektu i wymagały bardzo ścisłej współpracy analityka z zespołem deweloperskim.
Współpraca z zespołem testerskim była w tym procesie niezbędnym wsparciem. Testy pomagały wychwytywać rozbieżności pomiędzy zapisami w dokumentacji a rzeczywistą implementacją systemu. Uwagi zgłaszane przez testerów pozwalały doprecyzować wymagania, eliminować niejasności oraz ograniczać ryzyko błędów na dalszych etapach projektu.
Gdy wymagania są już opisane, a istotne ryzyka nazwane, projekt naturalnie przechodzi w fazę, w której decyzje analityczne muszą zostać przełożone na konkretne rozwiązania techniczne. To moment, w którym odpowiedzialność przejmuje zespół deweloperski.
Grzegorz Jamer – Ekspert ds. Analizy Biznesowej, Sygnity S.A.
Perspektywa analityczna
Development Bramki KSeF w warunkach zmiennych wymagań – jak decyzje techniczne budują jakość rozwiązania
Na etapie rozpoczęcia prac nad Bramką KSeF nie istniało stabilne rozwiązanie referencyjne w postaci biblioteki, którą regulator rekomendował do realizacji funkcjonalności. KSeF udostępnił bibliotekę i zalecał jej użycie jako preferowanej formy integracji, alternatywnie dopuszczając wykorzystanie REST API.
W momencie przystąpienia do projektu stan tej biblioteki był jednak bardzo niepewny. Jakość kodu budziła wątpliwości, a dodatkowo brakowało jasnych informacji, kiedy biblioteka osiągnie stabilną, produkcyjną wersję. Z perspektywy zespołu deweloperskiego oznaczało to realne ryzyko dla jakości i terminowości projektu.
Z tego powodu podjęta została decyzja o rezygnacji z gotowej biblioteki i bezpośredniej integracji z wystawionym przez KSeF REST API. Była to decyzja świadoma, ale wiązała się z istotnym zwiększeniem zakresu prac. Zespół musiał zaprojektować i zaimplementować własne rozwiązanie, co naturalnie wydłużyło czas realizacji, ale dawało większą kontrolę nad jakością i stabilnością systemu.
Równolegle z pracami deweloperskimi pojawiały się zmiany po stronie analizy w wielu obszarach. Część z nich generowała zupełnie nowe zadania, inne powodowały konieczność cofnięcia funkcjonalności, które były już praktycznie gotowe do testów, z powrotem do etapu realizacji. Było to szczególnie wymagające w kontekście utrzymania ciągłości prac i planowania kolejnych iteracji.
Dodatkowym wyzwaniem były decyzje wewnętrzne, m.in. dotyczące grup użytkowników, które zostały podjęte stosunkowo późno. Wpływało to na konieczność modyfikacji wcześniej przygotowanych rozwiązań oraz dostosowania ich do nowych założeń.
Istotnym problemem była również forma komunikowania zmian przez KsEF. Zmiany były publikowane w sposób niesyntetyczny. W KsEF pojawiały się nowe wersje dokumentów, jednak często brakowało jednoznacznej informacji jakie dokumenty uległy zmianie co dokładnie zostało zmienione i w jak sposób wpływa to na konkretne funkcjonalności. W przeciwieństwie do trybu „śledzenia zmian” w dokumentach analitycznych, w KsEF nie było jasnych odnośników, co powodowało niewystarczającą przejrzystość informacji i utrudniało szybkie reagowanie zespołu, doprowadzając również do niedopuszczalnej sytuacji, w której o zmianie funkcjonalności informowała nas niedziałająca aplikacja.
Takie czynniki, mimo dużych starań zespołu, mogą wpływać na zakłócenia w procesach produkcyjnych i w dłuższej perspektywie oddziaływać na jakość rozwiązania. Dlatego komunikacja okazała się jednym z kluczowych obszarów, nad którymi należało pracować na każdym etapie projektu.
Presja czasu i tempo prac sprawiały, że zespół momentami stosował odstępstwa od standardowych procedur, aby możliwie szybko dostarczać kolejne wersje rozwiązania. Nie było to podejście idealne z perspektywy procesu produkcji, dodatkowo generując problemy w komunikacji. Jednak zespół potrafił identyfikować te problemy, korygować je i stopniowo usprawniać proces.
Projekt stał się również źródłem ważnych lekcji. W toku prac zespół nauczył się rozpoznawać momenty, w których tempo zmian wymuszało „chodzenia na skróty”, i świadomie pracować nad poprawą organizacji, komunikacji oraz jakości współpracy między rolami.
Renata Kordylewska – Starszy Programista, Sygnity S.A.
Część deweloperska
Zapewnienie jakości Bramki KSeF w zmiennym środowisku wymagań
Jednym z największych wyzwań przy testowaniu Bramki KSeF była dynamicznie zmieniająca się dokumentacja. Specyfikacje techniczne, schematy XML oraz interpretacje biznesowe zmieniały się wielokrotnie w trakcie trwania projektu. Dla zespołu testerskiego oznaczało to, że raz przygotowane przypadki testowe bardzo szybko stawały się nieaktualne lub niepełne.
Zmiany w dokumentacji wymuszały inne podejście do tworzenia testów. Przypadki testowe nie mogły być traktowane jako ostateczne i niezmienne elementy projektu, lecz bardziej jako obiekty żyjące razem z analizą funkcjonalną. W praktyce oznaczało to pracę na konkretnych wersjach dokumentów, śledzenie zmian oraz ciągłe porównywanie opisanych funkcjonalności z już istniejącymi testami.
Praca testera wyglądała następująco: pojawiała się zmiana w wymaganiu, co wymagało aktualizacji odpowiednich przypadków testowych. Następnie konieczne było dostosowanie danych testowych – szczególnie w projekcie integrującym KSeF, gdzie poprawność struktury i zależności pomiędzy polami miała kluczowe znaczenie. Dopiero po wykonaniu tych kroków możliwe było przeprowadzenie testów regresji, które potwierdzały, że zmiana nie wpłynęła negatywnie na inne obszary systemu.
Aby ograniczyć ryzyko „rozjechania się” testów z aktualnym stanem analizy, zespół testerski stosował wspólne i regularne przeglądy przypadków testowych. Często odbywały się one z udziałem analityka i programistów. Takie spotkania przed kolejnymi etapami testów pozwalały wychwycić rozbieżności na wczesnym etapie i upewnić się, że testy faktycznie odzwierciedlały aktualne funkcjonalności Bramki KSeF, a nie ich historyczne wersje.
Przy częstych zmianach w analizie szczególne znaczenie miała kolejność aktualizacji przypadków testowych. W pierwszej kolejności modyfikowane były scenariusze krytyczne oraz przypadki obejmujące główne ścieżki biznesowe – przede wszystkim te, które miały bezpośredni wpływ na poprawność komunikacji z KSeF. Dopiero w dalszym etapie aktualizowane były przypadki mniej istotne, zależne od stabilności podstawowej logiki systemu.
Testerzy musieli również podejmować decyzje, czy dany przypadek testowy należało zmodyfikować, czy stworzyć nowy. Przyjęta zasada była prosta: jeśli zmiana w wymaganiu istotnie wpływała na przebieg scenariusza, zakres walidacji lub dane wejściowe, tworzony był nowy przypadek testowy. Dzięki temu unikano sytuacji, w której jeden przypadek testowy po wielu cyklach zmian stawał się trudny do zrozumienia i utrzymania. Modyfikacje istniejących przypadków stosowane były wyłącznie wtedy, gdy zmiany miały charakter doprecyzowujący lub kosmetyczny.
W praktyce zespołu istotną rolę odgrywało wersjonowanie przypadków testowych bezpośrednio w Jirze. Do każdego przypadku przypisywane były konkretne wersje dokumentacji, na podstawie których wykonywano testy. Wraz z każdą zmianą w analizie do przypadku dopisywana była kolejna wersja, a testy realizowane były ponownie w ramach regresji. Dopiero w momencie, gdy zespół miał pewność, że dany obszar analizy jest stabilny i nie będą wprowadzane kolejne zmiany, przypadek testowy zamykany był statusem „done”.
Takie podejście pozwalało zachować spójność pomiędzy aktualnym stanem dokumentacji a przypadkami testowymi, a jednocześnie ograniczało ryzyko powstawania nieczytelnych, nadmiernie modyfikowanych scenariuszy testowych.
W projekcie Bramki KSeF ścisła współpraca zespołu testerskiego z analitykami i deweloperami miała istotne znaczenie dla spójności wymagań i jakości rozwiązania. Wątpliwości analityczne były na bieżąco omawiane podczas przeglądów testów, a wspólnie ustalone statusy gotowości wersji pozwalały jasno określać zakres retestów i testów nowych funkcjonalności. Codzienne spotkania zespołu testerskiego oraz wspólne sesje testerskie umożliwiały regularną weryfikację newralgicznych obszarów systemu poprzez testy regresji. Takie podejście znacząco ograniczało ryzyko pominięcia istotnych scenariuszy i sprzyjało wczesnemu wykrywaniu problemów, które niewykryte mogłyby wpłynąć na stabilność środowiska produkcyjnego.
Zofia Kamińska – Specjalista ds.testów
Perspektywa testerska
Podsumowanie
Projekt Bramki KSeF pokazuje, że stabilne i bezpieczne rozwiązania nie powstają przypadkiem ani w wyniku pojedynczych decyzji technicznych. Są efektem świadomej współpracy zespołu, który potrafi łączyć perspektywę biznesową, technologiczną i jakościową, jednocześnie reagując na zmieniające się wymagania regulacyjne.
Doświadczenia analityka, programisty i testera potwierdzają, że w projektach regulowanych nie ma miejsca na pracę bez bieżącej wymiany informacji. Każda zmiana w wymaganiach wpływa na analizę, prace deweloperskie i testy, a powodzenie projektu zależy od tego, jak sprawnie i spójnie zespół potrafi na nią odpowiedzieć.
Dodatkowym wyzwaniem była integracja z firmami zewnętrznymi, z których każda działała w oparciu o własne cele biznesowe, strategie i harmonogramy. Wymagało to stałej koordynacji, uzgodnień i elastyczności po stronie zespołu projektowego. Choć proces ten nie zawsze przebiegał bezproblemowo, był niezbędny dla zachowania spójności rozwiązania i jego skutecznego działania w ekosystemie klienta.
Całość doświadczeń z projektu Bramka KSeF pokazuje, że gotowość systemu do wejścia na produkcję jest wynikiem nie tylko technologii, lecz także jakości współpracy, komunikacji i odpowiedzialnego podejścia do wytwarzania oprogramowania.
Autor artykułu: Emilia Franko
Współautorzy: Renata Kordylewska, Zofia Kamińska, Grzegorz Jamer
Emilia Franko