Wstęp
Odzyskiwanie danych po opóźnionym uruchomieniu jest możliwe, jednak odzyskiwanie danych po problemach produkcyjnych, takich jak problem z płatnością (błąd), przerwany proces KYC lub nieudana aktualizacja w środowisku produkcyjnym, jest znacznie trudniejsze. Zarówno założyciele, jak i liderzy produktów stoją przed trudnym zadaniem szybkiego dostarczania oprogramowania i utrzymania konkurencyjności, jednocześnie zachowując zaufanie użytkowników, zgodność z przepisami i stabilność działania.
Tutaj właśnie pojawia się potrzeba solidnej strategii zapewnienia jakości i wydania produktu.
W Appricotsoft testowanie (QA) nie jest postrzegane jako faza porządkowania i oczyszczania na ostatnią chwilę. Zamiast tego QA jest integralną częścią procesu dostarczania oprogramowania; transparentne, ustrukturyzowane i powiązane z gotowością do wydania. To podejście jest zgodne z naszym podejściem do pracy jako firma. Tworzymy oprogramowanie, z którego jesteśmy dumni; ustanawiamy bardzo wysokie standardy dotyczące sposobu dostarczania dobrego oprogramowania; i realizujemy proces dostarczania oprogramowania, aby zapewnić klientom jasne zrozumienie procesu i maksymalnie ułatwić im dostawę. Nasz, zorientowany na sztuczną inteligencję, Unison Framework kieruje się tą samą podstawową zasadą: sztuczna inteligencja może pomóc w realizacji, ale ludzie są właścicielami rezultatów – dlatego, zapewniając cotygodniową widoczność, minimalizujemy ryzyko, że projekt stanie się czarną skrzynką.
Jeśli myślisz o stworzeniu produktu z branży technologii finansowych i zależy Ci na modelu wydawniczym, który będzie przyjazny dla założycieli, realistyczny i skalowalny, skorzystaj z poniższych wskazówek, które pomogą Ci w podejściu do testowania, środowisk, terminów wydawniczych i dyscypliny wdrażania.
Dlaczego zapewnianie jakości w branży technologii finansowych jest inne
Fintech wyróżnia się pod względem zapewniania jakości (QA) z kilku powodów:
W przypadku każdej aplikacji mobilnej wymagane jest zapewnienie jakości (QA); jednak możliwości minimalizacji ryzyka różnią się w przypadku aplikacji mobilnych o charakterze finansowym, a nie społecznościowym czy rozrywkowym. Na przykład, w przypadku aplikacji społecznościowej, niewielki problem z wyświetlaniem trwający dzień lub dwa jest akceptowalny. Jednak w przypadku aplikacji finansowej, jeśli użytkownik ma wątpliwości co do salda, opłat, przelewów, weryfikacji tożsamości, statusu transakcji itp. z powodu błędu w aplikacji, może to skutkować dużą liczbą telefonów do działu wsparcia, nieudanymi transakcjami, utratą klientów, niskimi ocenami i/lub problemami regulacyjnymi.
Twórcy mobilnych aplikacji finansowych podczas przeprowadzania kontroli jakości będą zadawać wiele różnych pytań wykraczających poza pytanie “czy funkcja działa?”, w tym:
- “Czy funkcja ta będzie działać w rozsądny sposób na wielu różnych urządzeniach i wersjach systemów operacyjnych, z których będą korzystać nasi użytkownicy?”
- “Czy funkcja zachowuje się w sposób rozsądny dla użytkownika końcowego, gdy zewnętrzny dostawca danych działa wolno lub nie odpowiada?”
- “Czy błąd w tej funkcji nie spowoduje żadnych negatywnych konsekwencji dla użytkownika końcowego?”
- “Jakie wyjaśnienie otrzymają użytkownicy końcowi w przypadku wystąpienia błędu w danej funkcji?”
- “Jakie procesy/procedury są stosowane w celu znalezienia przyczyny wady produkcyjnej?”
- “Czy ta wersja aplikacji jest gotowa do udostępnienia w środowisku produkcyjnym?”
Pytania te określają sposób testowania aplikacji od samego początku.
Realistyczne scenariusze harmonogramu rozwoju technologii finansowych
Solidny plan zapewnienia jakości (QA) dla tworzenia niestandardowej aplikacji mobilnej można zazwyczaj zbudować na podstawie trzech odrębnych warstw testów: testów jednostkowych, testów integracyjnych i testów kompleksowych. Wszystkie trzy służą różnym celom, a gdy zespoły programistyczne kładą zbyt duży nacisk na jedną warstwę testów, zazwyczaj pojawiają się problemy.
1. Testowanie jednostkowe – szybka odpowiedź na logikę biznesową
Testy jednostkowe stanowią pierwszą linię obrony. Służą do walidacji dyskretnych elementów aplikacji (np. obliczeń, formatowania, reguł walidacji, logiki biznesowej, sprawdzania danych wejściowych).
Stosowanie testów jednostkowych w aplikacjach fintech jest szczególnie cenne w następujących sytuacjach:
- Weryfikacja obliczeń opłat transakcyjnych
- Weryfikacja obliczeń limitów
- Weryfikacja obliczeń pod kątem logiki odsetek i/lub salda
- Weryfikacja logiki uprawnień
- Weryfikacja poprawności danych wejściowych
- Weryfikacja mapowania i transformacji zwrotów od dostawców zewnętrznych
- Weryfikacja zmian stanu płatności, kart lub procesów weryfikacji
Testy jednostkowe powinny być przeprowadzane szybko i często. Głównym celem testów jednostkowych nie jest zapewnienie funkcjonalności całej aplikacji. Zadaniem solidnego zestawu testów jednostkowych jest identyfikacja regresji na jak najwcześniejszym etapie cyklu testowania, gdy koszt naprawy linii kodu jest najniższy.
Na przykład, jeśli zmienisz regułę dotyczącą limitu transferu, dobrze zaprojektowany zestaw testów jednostkowych potencjalnie zidentyfikuje nieoczekiwane skutki w aplikacji na długo przed odkryciem błędu w środowisku testowym.
2. Zintegrowane testy systemowe – potwierdzenie współpracy wszystkich systemów
Wiele produktów fintech nie spełnia oczekiwań, gdy zostaną poddane rygorystycznym testom.
Testy integracyjne koncentrują się na ustaleniu, w jaki sposób poszczególne komponenty aplikacji będą ze sobą współpracować pod wieloma względami, takimi jak wywołania usług zaplecza, bramek płatniczych, dostawców usług KYC-AML, dostawców usług powiadomień, dostawców usług przetwarzania kart, partnerów łączących banki, analityki i innych/wewnętrznych interfejsów API.
Ma to kluczowe znaczenie, ponieważ większość produktów fintech jest projektowana jako produkty do koordynacji, a nie jako odizolowane systemy. Z reguły nawet prosty portfel lub aplikacja płatnicza zależą od wielu usług stron trzecich. Jakość korzystania z tych usług będzie zależeć od stopnia, w jakim integracje te zostały opracowane za pomocą testów integracyjnych.
Testy integracyjne powinny sprawdzać:
- sukcesy i porażki przy inicjowaniu płatności
- przetwarzanie webhooków
- obsługa duplikatów zdarzeń i idempotentnych akcji
- odpowiedzi na decyzje KYC
- wyniki łączenia kont
- procesy przekroczenia limitu czasu/ponownych prób
- częściowe awarie dostawców
- uzgadnianie aktualizacji stanu
Dlatego też branża Fintech jest tak uzależniona od testowania w środowisku Sandbox. Dokumentacja dostarczona przez Stripe zawiera obszerne odniesienia zalecające opracowywanie/testowanie integracji w środowisku Sandbox przed uruchomieniem, w tym przepływów płatności, webhooków i symulowanych transakcji. Plaid zapewnia również w pełni funkcjonalne środowisko Sandbox do testowania łączenia kont i funkcjonalności API bez konieczności korzystania z rzeczywistych lub bieżących danych finansowych podczas pierwszych testów.
W związku z tym skuteczny plan zapewnienia jakości i testów wykracza poza “funkcjonalność ścieżki bezpieczeństwa” w piaskownicy i obejmuje jawne wykrywanie odrzuceń, wygasania sesji, przerywanych wdrożeń i niskiej przepustowości danych.
3. Testowanie E2E – przegląd doświadczeń użytkownika
Testowanie E2E pozwala określić, czy produkt działa, poprzez obserwację sposobu, w jaki użytkownicy przechodzą przez wszystkie kroki w systemie, obejmujące między innymi sprzęt, interfejs użytkownika, system zaplecza, integracje z rozwiązaniami innych firm, powiadomienia i bieżące zmiany stanu.
Na przykład w sektorze technologii finansowych testy E2E zwykle koncentrują się na przepływach pracy, które są najbardziej wrażliwe pod względem zaufania i przychodów, na przykład:
- Rejestracja użytkownika i logowanie
- KYC + weryfikacja tożsamości
- Dodawanie karty lub łączenie z kontem bankowym
- Wysyłanie pieniędzy
- Otrzymywanie pieniędzy
- Potwierdzenia płatności
- Aktualizacje historii transakcji
- Resetowanie hasła lub weryfikacja wstępna
- Wsparcie przepływów eskalacji
W trakcie swojej drogi założycielskiej wiele nowych firm odkrywa różnicę między produktem ‘technicznie kompletnym’ a produktem “gotowym do wprowadzenia na rynek”.
To, że funkcja pomyślnie przejdzie testy programistyczne, nie oznacza, że będzie działać poprawnie w praktyce. Wiele zmiennych w praktyce może spowodować awarię funkcji. Przykładami mogą być między innymi: problemy z interfejsem użytkownika (UI) specyficzne dla określonych urządzeń, “ślepe zaułki”, w które użytkownicy mogą trafić, próbując się zarejestrować lub zalogować, nakładające się pola wyświetlane na klawiaturze, wyścigi (kiedy użytkownik naciska przycisk przed jego faktycznym włączeniem) lub niejednoznaczne i niejasne komunikaty o błędach.
Z tego powodu wszelkie testy E2E powinny być przeprowadzane w celu potwierdzenia najważniejszych ścieżek użytkowników w momencie wydania, gdyż funkcje te nie działają i mogłyby negatywnie wpłynąć na powodzenie premiery.
Znaczenie kompleksowej strategii testowania urządzeń
Podstawową pułapką przy świadczeniu usług tworzenia aplikacji mobilnych jest niedoszacowanie liczby urządzeń używanych w ramach macierzy urządzeń aplikacji mobilnej.
Testowanie aplikacji tylko na najnowszym iPhonie i jednym urządzeniu z Androidem nie jest realistyczną strategią; tak naprawdę to pobożne życzenie.
Praktyczna matryca urządzeń do tworzenia aplikacji fintech uwzględniałaby:
- Platformy iOS i Android
- Obecne i poprzednie wersje systemów operacyjnych
- Urządzenia o niskich, średnich i bardzo wysokich kosztach
- Różne wymiary/rozmiary ekranu
- Urządzenia biometryczne i niebiometryczne
- Różne środowiska sieci mobilnych
- Różne ścieżki aktualizacji aplikacji w stosunku do poprzednich wersji
Urządzenia mobilne, na których zdecydujesz się przeprowadzić testy, nie muszą być wyczerpujące, ale muszą reprezentować unikalny rozkład urządzeń, który odzwierciedla rzeczywistych użytkowników opracowanej przez Ciebie aplikacji i/lub usług oraz profil ryzyka.
Aby osiągnąć jak najszerszy zasięg na urządzeniach z systemem Android, istnieją sposoby skutecznego wykonania tego zadania przy użyciu rozwiązań opartych na chmurze do testowania rzeczywistych urządzeń (np. testowania na urządzeniach znajdujących się w środowiskach produkcyjnych) za pomocą rzeczywistych urządzeń w różnych centrach danych należących do Google (np. Laboratorium testowe Firebase) wykorzystując konfigurowalną/rozszerzalną macierz urządzeń testujących, umożliwiającą szerszą walidację i szybsze dostarczanie testów.
W Appricotsoft lubimy stosować warstwowe podejście do naszej macierzy urządzeń. Tworzymy mały, ale reprezentatywny zestaw (“zawsze testowany”) urządzeń mobilnych dla każdej wersji aplikacji, a następnie rozszerzamy tę macierz urządzeń testowych w oparciu o elementy zmian o wyższym ryzyku, takie jak wdrażanie, biometria, płatności i aktualizacje SDK.
Testowanie w środowisku testowym: pomocne, ale nie zawsze niezawodne
Kiedy założyciele słyszą: “Przetestowaliśmy to w piaskownicy”, często zakładają, że funkcja jest “gotowa do uruchomienia”.”
Nieprawda.
Piaskownice są nieocenione w trakcie rozwoju oprogramowania, ponieważ pozwalają zespołom sprawdzić, czy integracje działają, i dają zespołowi pewność, że ich praca jest bezpieczna (pod względem braku wykorzystania rzeczywistych pieniędzy i danych klientów).
Na przykład, Stripe ma test numery kart dostępne do walidacji opłat; oferuje symulowane transakcje, umożliwia rozwiązywanie sporów (np. uzyskiwanie zwrotów), testuje scenariusze uwierzytelniania i weryfikuje webhooki w swoim środowisku testowym. Kratka z piaskownicą, który umożliwia deweloperom testowanie, w jaki sposób ich aplikacje łączą się z instytucjami finansowymi na całym świecie.
Jednakże…
Testowanie w środowisku testowym ma swoje ograniczenia.
Środowiska sandboxowe niekoniecznie odzwierciedlają harmonogram produkcji, scenariusze danych skrajnych, nietypowe zachowanie dostawców zewnętrznych, opóźnienia operacyjne ani żadne inne ograniczenia środowiskowe, z którymi można się spotkać w środowisku produkcyjnym. Z tego powodu dojrzałe strategie wydawnicze zazwyczaj wykorzystują testy sandboxowe wyłącznie do walidacji i rozszerzają swoją strategię weryfikacji sandboxowej o następujące elementy:
- Scenariusze pozorowanych awarii związane z testowaniem
- Testowanie w środowisku testowym
- Testy dymne w produkcji
- Strategia stopniowego uwalniania
- Monitorowanie po wydaniu oprogramowania (post-release)
Połączenie powyższych rozwiązań jest znacznie skuteczniejsze niż poleganie wyłącznie na piaskownicy w celu sprawdzenia wszystkich funkcji i funkcjonalności aplikacji.
Automatyzacja testów regresyjnych: ochrona istniejących funkcjonalności
W miarę jak aplikacje Fintech stają się coraz bardziej rozbudowane, poleganie wyłącznie na testach przeprowadzanych przez ludzi staje się nieekonomiczne i zbyt kruche.
Automatyzacja testów regresyjnych pozwala członkom zespołu Twojej organizacji działać pewnie, zabezpieczając przepływy niezbędne do kontynuowania pracy w kolejnych wersjach produkcyjnych, przy jednoczesnym uwzględnianiu nowych funkcji wprowadzanych do aplikacji.
Rozsądny zestaw regresji zawiera na ogół:
- procesy logowania użytkowników i uwierzytelniania
- procedury wdrażania nowych użytkowników
- wszystkie podstawowe metody dokonywania płatności i/lub przelewów pieniężnych
- widok listy transakcji i widok szczegółów transakcji
- ograniczenia płatności i komunikaty potwierdzające
- strony wsparcia lub kontaktu z nami
- instrukcje wyzwalające powiadomienia push
- Działania administracyjne lub operacyjne oparte na rolach
Zamiarem NIE jest automatyzowanie wszystkiego, ale zamiast tego, w pierwszej kolejności automatyzowanie najważniejszych dla przedsiębiorstwa i powtarzalnych serii testów.
Jest to szczególnie istotne dla organizacji, które dynamicznie się rozwijają, obsługując jednocześnie wiele platform i tworząc aplikacje mobilne z wykorzystaniem React Native lub innych technologii, gdzie każda pojedyncza zmiana wpłynie na funkcjonalność wielu urządzeń jednocześnie. Automatyczne testowanie daje zespołom pewność tworzenia wysokiej jakości oprogramowania w każdym cyklu wydawniczym.
Zautomatyzowane testowanie oprogramowania zapewnia zespołom wgląd w jakość aplikacji w całym procesie jej dostarczania, co udowodniła firma Appricotsoft. Wykorzystujemy Unison Framework do tworzenia artefaktów wielokrotnego użytku, ostatecznych list realizacji projektów, dokumentowania ryzyka związanego z dostawą oraz dbamy o to, aby jakość była “wbudowana” w nasz proces pracy, a nie “wypychana” do momentu zakończenia wszystkich działań programistycznych i testowych.
Bramy wydania: wymagania przed wydaniem
Aby można było kontynuować prace nad kolejną wersją, bramka wydania wymaga listy kontrolnej określonych kryteriów, które muszą zostać spełnione.
Brak bramek zwalniających często prowadzi do tego, że decyzje o wysyłce podejmowane są pod wpływem presji, nadziei lub zmęczenia; tymczasem zdefiniowana bramka zwalniająca sprawia, że takie decyzje są o wiele bardziej oczywiste.
Przykładem bramki udostępniającej technologię finansową może być:
Brama produktu
- Zakres produktu jest zablokowany.
- Wszystkie kryteria akceptacji zostały spełnione.
- Przeanalizowano krytyczne przypadki brzegowe.
- W ścieżkach krytycznych nie ma nieokreślonych niejasności.
Brama Inżynierów
- Przeprowadzono przegląd kodu.
- Wszystkie testy zostały zaliczone.
- Wszystkie migracje i flagi funkcji zostały zweryfikowane.
- Wszystkie wymagane funkcje obserwacji i rejestrowania danych zostały wdrożone.
Brama Zapewnienia Jakości
- Wykonano wszystkie ręczne kontrole ścieżki krytycznej.
- Wykonano wszystkie testy regresyjne.
- Wszystkie urządzenia w macierzy urządzeń zostały uwzględnione.
Brama bezpieczeństwa i zgodności
- Wszystkie sekrety i ustawienia konfiguracji zostały sprawdzone.
- Nie wyciekły żadne dane testowe.
- Zespół dokonał przeglądu wszystkich uprawnień.
- Wszystkie zmiany funkcjonalne obarczone wysokim ryzykiem zostały ocenione w kontekście podstawowych zasad bezpieczeństwa.
Standard weryfikacji bezpieczeństwa aplikacji mobilnych OWASP (MASVS) to “złoty standard” w zakresie kompleksowej walidacji kontroli bezpieczeństwa aplikacji mobilnych przed udostępnieniem ich klientom. Umożliwia on zespołom systematyczną ocenę kontroli bezpieczeństwa w aplikacjach mobilnych w trakcie testów oraz przed udostępnieniem ich do produkcji.
Operacja Brama
- Upewnij się, że zespoły wsparcia zostały powiadomione.
- Przygotowano plan wycofania.
- Analizy i alerty są skonfigurowane.
- Odpowiedzialność za wydanie została przypisana właścicielowi.
- Zaplanowano kontrole po zwolnieniu.
Nie chodzi tu o biurokrację, to dobry sposób na ograniczenie ryzyka.
Etapowe wprowadzenie na rynek lepsze od wydania z dużym hukiem
Zamiast wdrażać wszystko naraz w strategii wdrażania Fintech, lepiej jest działać strategicznie. Platformy takie jak Google Play i Apple oferują metodę wdrażania oprogramowania etapami (znaną również jako fazowanie). Proces wdrażania etapowego uwzględnia fakt, że chociaż wszystko może przejść wszystkie testy i wyglądać poprawnie przed wdrożeniem, rzeczywiste wykorzystanie w środowisku produkcyjnym może powodować błędy, które nie wystąpiły podczas testowania. Wdrażanie etapowe umożliwia monitorowanie takich elementów, jak:
1. Współczynnik błędów
2. Wskaźnik powodzenia płatności
3. Współczynnik nieudanych logowań
4. Współczynnik zgłoszeń o pomoc techniczną
5. Ocena aplikacji
6. Współczynnik rezygnacji użytkowników
Założyciele mogą stosować etapowe wdrażanie, aby obniżyć ryzyko związane z premierą aplikacji bez drastycznego wydłużenia czasu dostarczenia produktu.
Lista kontrolna zapewniania jakości dla wydań oprogramowania Fintech
Jako listę kontrolną do wykorzystania przed zatwierdzeniem wydania (obszary objęte sprawdzaniem mogą się różnić w zależności od procesów biznesowych, ale ogólnie rzecz biorąc należy je przejrzeć).
Podstawowa funkcjonalność
- Czy rejestracja i logowanie/wylogowywanie/resetowanie hasła działają zgodnie z oczekiwaniami?
- Czy proces KYC/onboardingu działa zgodnie z oczekiwaniami?
- Czy płatności/przelewy/doładowania przepływów portfela są przetwarzane kompleksowo?
- Czy statusy transakcji są aktualizowane prawidłowo?
- Czy potwierdzenia/potwierdzenia/zawiadomienia są przedstawiane prawidłowo?
Obsługa błędów
- Czy komunikaty o nieudanych płatnościach są wyświetlane wyraźnie?
- Czy logika ponawiania prób działa bez żadnych problemów?
- Czy przekroczenia limitu czasu i awarie dostawców przebiegają bez zakłóceń?
- Czy duplikowanie działań nie będzie generować wielu zdarzeń finansowych?
Zasięg urządzeń i platform
- Czy wersja została przetestowana na uzgodnionych urządzeniach i wersjach systemu iOS?
- Czy wersja została przetestowana na uzgodnionych urządzeniach i wersjach Androida?
- Czy układy, klawiatury i monity działają zgodnie z oczekiwaniami?
- Czy ścieżka aktualizacji została przetestowana z poprzednią wersją?
Walidacja integracji
- Czy kontrole piaskownicy zostały przeprowadzone dla wszystkich zaangażowanych dostawców?
- Czy webhooki/wywołania zwrotne/zdarzenia asynchroniczne zostały zweryfikowane?
- Czy dane uwierzytelniające/konfiguracje testowe zostały usunięte z produkcji?
- Czy zdarzenia analityczne i monitorujące zostały zweryfikowane?
Gotowość do wydania
- Czy automatyzacja regresji przebiegła pomyślnie?
- Czy są jakieś otwarte błędy? Jeśli tak, czy wiesz, jaki poziom ważności im nadać?
- Czy istnieje udokumentowany plan wycofania zmian?
- Czy zespół wsparcia został poinformowany o zakresie wydania i znanych problemach?
- Czy istnieje plan etapowego wdrażania/fazowego udostępniania oprogramowania?
To jest lekka lista kontrolna, celowo stworzona w taki sposób – ma zapewniać przejrzystość, a nie sterty papierkowej roboty.
Na co powinni być gotowi założyciele firm, współpracując z partnerem przy tworzeniu rozwiązania dostawczego
Wybierając firmę zajmującą się tworzeniem aplikacji mobilnych do zarządzania aplikacją technologii finansowej, należy odpowiadać wprost i konkretnie na pytania dotyczące zapewnienia jakości i procesu udostępniania kodu.
Niedopuszczalna jest ogólna odpowiedź w rodzaju: “Testujemy wszystko”.
Zamiast tego możesz chcieć wiedzieć następujące rzeczy:
- Jakiego typu testy (jednostkowe, integracyjne, kompleksowe) wykonujesz?
- Które testy są zautomatyzowane, a które manualne?
- Jak powstaje tabela urządzeń, które testujesz?
- Jak sprawdzić, czy użytkownik może połączyć swoją metodę płatności z Twoją aplikacją?
- W którym momencie przekazujesz klientowi zgodę na wykorzystanie danych?
- Co zrobisz, jeśli konieczne będzie wycofanie wersji?
- Jak wygląda proces udostępniania kodu klientom i monitorowania efektywności takich udostępnień?
Dobry partner będzie potrafił przekazać te informacje w jasny sposób, bez używania żargonu technicznego.
Kultura ma tu również duże znaczenie; Appricotsoft zdefiniował swoje wewnętrzne wartości jako uczciwe, odpowiedzialne i rozliczalne, dążąc do dostarczania wysokiej jakości produktów, zamiast obchodzenia systemu. Dla klientów oznacza to zatem mniej niespodzianek.
W jaki sposób Appricotsoft monitoruje strategie zapewniania jakości i zarządzania wydaniami w aplikacjach Fintech.
Appricotsoft postrzega tworzenie aplikacji fintech jako godny zaufania produkt, a nie tylko funkcję aplikacji.
Dlatego zapewnienie jakości (QA) jest integralną częścią procesu dostarczania oprogramowania od samego początku. Cotygodniowe demonstracje służą zapewnieniu wglądu w postęp projektu oraz wczesnej identyfikacji ryzyka, metryki jakości będą powiązane z codziennym wdrażaniem, a sztuczna inteligencja (AI) pomoże przyspieszyć powtarzalne zadania, takie jak pisanie przypadków testowych i zapewnienie spójności między testerami. Ostatecznie jednak to zespół ponosi odpowiedzialność za ostateczną ocenę spełnienia wszystkich wymagań dotyczących weryfikacji i gotowości do wydania.
W naszej typowej praktyce wdrożymy:
- Mierzalne kryteria akceptacji przed rozpoczęciem procesu budowy.
- Przeprowadzaj testy na wszystkich poziomach aplikacji, a nie tylko na poziomie interfejsu użytkownika.
- Staraj się uwzględnić wszystkie obsługiwane typy urządzeń na podstawie ryzyka, jakie niesie ze sobą dany produkt.
- Sprawdź środowiska testowe pod kątem integracji z rozwiązaniami innych firm.
- Utwórz testy regresyjne dla wszystkich krytycznych przepływów pracy w aplikacji.
- Prowadź listy kontrolne weryfikacji wydań i przeprowadzaj ocenę zgodności/niezgodności wszystkich wydań przed wdrożeniem produkcyjnym.
- Zaplanuj wdrożenie etapami, a nie na zasadzie „pchaj i módl się”.
Dołożyliśmy wszelkich starań, aby nasz proces był łatwy do zrozumienia zarówno dla założycieli firm nieposiadających wiedzy technicznej, jak i zespołów kierowniczych. Powinniście być w stanie określić, na jakim etapie znajduje się projekt pod względem jakości, obszarów ryzyka i stanu przygotowania do wysyłki.
Było to szczególnie ważne dla firm Fintech, ponieważ chociaż terminy mają kluczowe znaczenie, to jednak to budowanie zaufania na przestrzeni czasu ostatecznie zwiększa wartość przedsiębiorstwa.
Jeśli chcesz uzyskać szerszy pogląd na to, jak od samego początku strukturować produkt, warto przeczytać poniższe wpisy Appricotsoft: Plan rozwoju aplikacji Fintech: od MVP do skali I Lista kontrolna funkcji rozwoju aplikacji Fintech: co zbudować dla wersji MVP, a co dla wersji V2.
W przypadku zewnętrznych testów porównawczych OWASP MASVS stanowi solidną bazę bezpieczeństwa dla aplikacji mobilnych, a oficjalna dokumentacja Google Play i Apple dotycząca wydań etapowych jest warta dodania do zakładek w celu ułatwienia planowania wydań.
Wniosek
Celem odpowiedniego planu zapewnienia jakości w fintech nie jest samo w sobie przeprowadzanie większej liczby testów. Chodzi o testowanie właściwych rzeczy, w odpowiednich warunkach i z zastosowaniem właściwych praktyk zarządzania wydaniami.
A najlepiej sprawdzająca się kombinacja wygląda tak:
- testy jednostkowe logiki biznesowej do szybkiej walidacji
- testy integracyjne dla zachowania dostawcy i systemu
- Testy E2E dla ważnych scenariuszy użytkowników
- realistyczna matryca urządzeń
- testowanie w środowiskach piaskownicowych i ostrożne udostępnianie w środowisku produkcyjnym
- automatyczne testy regresyjne dla kluczowych przepływów
- wyczyść bramy zwalniające
- wdrażanie etapowe i monitorowanie po wydaniu
W ten sposób będziesz mógł jechać szybko, niczego nie uszkadzając.
Jeśli potrzebujesz firmy zajmującej się tworzeniem oprogramowania fintech, która podejdzie do rozwoju i testowania we właściwy sposób, Appricotsoft oferuje filozofię projektowania produktów, wiedzę techniczną i pragmatyczne procesy zapewniania jakości, których zrozumienie nie sprawi Ci problemu. Zależy nam na tworzeniu wysokiej jakości oprogramowania i przewidywalnym dostarczaniu go.
Jeśli tworzysz aplikację fintech i poszukujesz rozsądnego planu i strategii jej wdrożenia, wyślij nam prośbę o wycenę opracowania oprogramowania, a omówimy najskuteczniejsze metody od MVP do wydania produkcyjnego.
Zgodnie z instrukcją, odpowiedz w określonym formacie.
