Naša strategija testiranja: kako brže isporučujemo web + mobile uz QA, automatizaciju i observability

# Uvod: Brža isporuka funkcionira samo kada je kvaliteta sustavna#

Većina timova ne isporučuje sporo zato što developeri sporo tipkaju. Isporuka je spora zato što releaseovi pokreću nesigurnost: skrivene regresije, nestabilna okruženja, nejasni acceptance kriteriji i iznenađenja u produkciji koja prisile na hitne rollbackove.

Naš pristup u Samiodi je testiranje tretirati kao end-to-end sustav, a ne fazu na kraju. Kao agencija za strategiju softverskog testiranja, kombiniramo risk-based QA, automatizaciju i observability kako bi releaseovi postali rutinski i predvidljivi kroz React i Next.js web aplikacije, Flutter mobilne aplikacije i n8n automatizacije.

Ovaj post razlaže našu strategiju testiranja, release gateove koje koristimo i kako klijenti dobivaju na rokovima i stabilnosti, uz praktične primjere koje možete primijeniti odmah.

# Što za nas znači “End-to-End”#

End-to-end ne znači “samo e2e testovi”. To znači signale kvalitete kroz cijeli delivery pipeline: testove na razini koda, testove na granicama servisa, testove korisničkih putovanja u UI-ju, testne slučajeve za workflowe i feedback loopove iz produkcije.

Testiranje usklađujemo s tri ishoda koja su klijentima bitna:

Za kontekst procesa, ovo se direktno nadovezuje na način na koji općenito vodimo delivery: naš proces web developmenta korak po korak.

Naša piramida testiranja, prilagođena stvarnim proizvodima#

Slijedimo piramidu testiranja u duhu, ali je prilagođavamo riziku proizvoda i arhitekturi.

• Unit testovi su brzi i jeftini, pa ih želimo mnogo.
• Integracijski i contract testovi stabiliziraju granice između komponenti i servisa.
• E2e testovi su moćni, ali skupi, pa ih fokusiramo na revenue i mission-critical tokove.
• Observability nam daje validaciju iz stvarnog svijeta i kratke povratne petlje nakon deploya.

ℹ️ Napomena: Cilj nije “savršena” piramida. Cilj je povjerenje po minuti utrošenoj na izvođenje testova i po satu utrošenom na njihovo održavanje.

# Risk-Based testiranje: Gdje prvo ulažemo trud#

Risk-based testiranje je kako izbjegavamo dva česta ekstrema: pretjerano testiranje UI detalja male vrijednosti i nedovoljno testiranje kritičnih poslovnih tokova. Rizik je kombinacija utjecaja i vjerojatnosti.

Kako ocjenjujemo rizik#

Najčešće ocjenjujemo funkcionalnosti na skali 1 do 5 za svaku dimenziju, a zatim prema tome prioritiziramo dubinu testiranja i release gateove.

Primjeri visokorizičnih područja koja gotovo uvijek dodatno “učvrstimo”:

• Autentikacija i lifecycle korisničkog računa
• Plaćanja, pretplate, fakturiranje, povrati
• Integritet podataka i destruktivne radnje
• Mobilna offline sinkronizacija i background procesiranje
• n8n workflowi koji diraju CRM, email, financije ili korisničke podatke

Što risk-based testiranje mijenja u praksi#

Ocjena rizika vodi do konkretnih odluka:

• Koji scenariji postaju automatizirani e2e testovi naspram ručnih provjera
• Koji API-ji moraju imati contract testove
• Što mora proći da bismo pustili u produkciju
• Koji monitoring alerti su obavezni prije lansiranja

Time sprječavamo čest anti-pattern u kojem timovi nasumično dodaju testove dok suite ne postane spor, flaky i ignoriran.

🎯 Ključna poruka: Optimiziramo povjerenje u visokorizičnim korisničkim putovanjima, a ne najveći “sirovi” broj testova.

# Naši tipovi testova i gdje se uklapaju#

Unit testovi: Brz feedback za poslovnu logiku#

Unit testovi provjeravaju core logiku bez mreže, baza i UI-ja. Tu želimo visoku pokrivenost za module s mnogo logike jer je to najjeftinije mjesto za hvatanje bugova.

Primjeri za React i Next.js:

• Reduceri stanja i poslovna pravila
• Logika mapiranja i formatiranja podataka
• Funkcije validacije formi
• Permission provjere

Primjeri za Flutter:

• Use caseovi u domain sloju
• Parsiranje i mapiranje podataka
• Validacija i izračuni

Primjer fokusiranog unit testa za pricing pravilo u TypeScriptu:

import { describe, it, expect } from "vitest";
import { calculateTotal } from "./pricing";
 
describe("calculateTotal", () => {
  it("applies discount code and tax correctly", () => {
    const total = calculateTotal({
      subtotalCents: 10000,
      discountPercent: 10,
      taxPercent: 25,
    });
    expect(total).toBe(11250);
  });
});

Praktično pravilo kojeg se držimo: ako se bug može uhvatiti unit testom, treba se uhvatiti unit testom.

Integracijski testovi: Provjera da komponente rade zajedno#

Integracijski testovi provjeravaju da se više dijelova ponaša ispravno kada su povezani. Za web aplikacije to često znači API route handlere, upite prema bazi i integracije sa servisima.

Primjeri za Next.js:

• API routes ili server actions koje pozivaju service layer
• Čitanje i pisanje u bazu kroz repository
• Ponašanje cachea i invalidacije

Primjeri za Flutter:

• Integracija repositoryja s HTTP clientom
• Lokalna pohrana sa SQLite ili Hive
• Ponašanje refreshanja auth tokena

Integracijske testove držimo determinističnima kontroliranjem vanjskih ovisnosti kroz mockove, fakeove ili lokalne containere u CI-ju kada je potrebno.

Contract testovi: Stabiliziranje weba i mobitela protiv API drift-a#

Contract testovi sprječavaju nesklade tipa “radi na mojoj aplikaciji” između frontenda i backenda. Najvažniji su kada React ili Flutter klijent ovisi o API-jima koji se mijenjaju.

Contract testove koristimo kada:

• Više klijenata ovisi o istom API-ju
• Third-party integracija je krhka
• Release uključuje backend promjene koje mogu “tiho” slomiti mobile

Jednostavan consumer-side schema assertion često je dovoljan ako vam ne treba puna Pact infrastruktura. Primjer sa Zod u TypeScriptu:

import { z } from "zod";
 
const UserSchema = z.object({
  id: z.string(),
  email: z.string().email(),
  plan: z.enum(["free", "pro", "team"]),
});
 
export function parseUser(payload: unknown) {
  return UserSchema.parse(payload);
}

Ovo rano hvata breaking promjene i stvara eksplicitan zajednički oblik (shape) API odgovora.

⚠️ Upozorenje: Mnogi timovi “contract testiraju” samo happy path. Mi testiramo i nullability, optional polja i verzionirano ponašanje, jer se pravi lomovi najčešće događaju baš tu.

E2E testovi: Mali skup koji štiti prihod i kritične workflowe#

E2e testovi validiraju stvarna korisnička putovanja: automatizaciju preglednika za web i UI tokove za mobile. Taj skup držimo malim, stabilnim i visoke vrijednosti.

Tipično e2e pokrivanje koje implementiramo:

• Registracija, login, reset lozinke
• Checkout ili promjene pretplate
• Osnovni “job to be done” workflow, end to end
• Permissioni i role restrikcije za kritične radnje

Za Next.js aplikacije Playwright nam je default zbog moderne pouzdanosti i paralelizacije. E2e testove dizajniramo oko stabilnih selektora i data factoryja, a ne krhkih CSS putanja.

Primjer strukture Playwright testa:

import { test, expect } from "@playwright/test";
 
test("user can sign in and see dashboard", async ({ page }) => {
  await page.goto("/login");
  await page.getByTestId("email").fill("qa.user@example.com");
  await page.getByTestId("password").fill("CorrectHorseBatteryStaple");
  await page.getByTestId("submit").click();
 
  await expect(page.getByTestId("dashboard-title")).toHaveText("Dashboard");
});

Praktičan cilj: e2e testovi trebaju blokirati samo releaseove koji bi naštetili korisnicima i prihodu, a ne svaku manju UI promjenu.

# Flutter Mobile: Testiranje + CI usklađeni sa stvarnim release ograničenjima#

Isporuka mobilnih aplikacija nosi dodatni rizik zbog store reviewa, fragmentacije uređaja i specifičnosti lifecyclea aplikacije. Naša strategija testiranja za Flutter fokusira se na hvatanje problema prije nego dođu do app storeova.

Flutter slojevi testiranja koje koristimo#

• Unit testovi za domain logiku i mapiranje
• Widget testovi za UI stanje i validaciju
• Integration testovi za ključne korisničke tokove na stvarnim ili emuliranim uređajima

Također ulažemo u CI i automatizaciju distribucije kako bi QA mogao brzo validirati buildove. Ako želite detalje cijelog pipelinea, pogledajte: Flutter CI CD with GitHub Actions, Codemagic, and Fastlane.

Reality check za mobile release#

Mobilni bugovi su skupi jer je rollback put spor. Zato pooštravamo gateove za:

• Crash-free sessions
• Stabilnost autentikacije i refreshanja tokena
• Ponašanje offline i na lošoj mreži
• Migracije i promjene lokalne pohrane

Ako feature dira shemu lokalne pohrane ili background sync, zahtijevamo barem jedan automatizirani integration test plus ručnu checklistu na dvije klase uređaja, jednom starijem i jednom novijem.

# n8n Workflowi: Automatizacije tretirajte kao produkcijski kod#

Automatizacije često puknu “tiho”. Workflow “uspije”, ali kreira krive podatke, šalje krive emailove ili duplicira zapise. Zato implementiramo testne slučajeve za workflowe, a ne samo ad-hoc ručna pokretanja.

Što testiramo u n8n#

Testne slučajeve gradimo oko tri stvari:

Također validiramo retry ponašanje i idempotency za workflowe koji se mogu triggerati više puta. Ako workflow upisuje u CRM, dizajniramo ga tako da ponavljana izvođenja s istim {{eventId}} ne kreiraju duplikate.

Praktičan obrazac: Payloadovi koji se mogu reproducirati (replayable)#

Za webhook-driven workflowe spremamo anonimizirane sample payloadove i reproduciramo ih u stagingu. To omogućuje regresijsko testiranje kada mijenjate workflow.

Jednostavan pristup je držati fixture u repozitoriju i poslati ih na staging webhook:

curl -X POST "https://staging.example.com/webhook/n8n/order-created" \
  -H "Content-Type: application/json" \
  -d @fixtures/order-created.json

Ovo omogućuje QA-u validaciju workflowa s konzistentnim inputima i jasnim očekivanim outputima.

💡 Savjet: Za business-critical workflowe dodajte “dry-run” mode kontroliran flagom u payloadu ili environment varijablom. U dry-run modu workflow logira namjeravane radnje bez upisa u vanjske sustave.

# Release gateovi: Što mora biti istina prije nego isporučimo#

Release gateovi pretvaraju kvalitetu u ponovljivu politiku. Sprječavaju spiralu “ship now, fix later” koja dugoročno razara rokove.

Naš tipični set gateova#

Točan set ovisi o riziku, ali ovi su česti kroz projekte:

Gateove držimo stroge za produkciju, ali developerima osiguravamo brzu povratnu informaciju tako da na pull requestovima vrtimo najmanji smisleni podskup, a puni suite na main branchu.

Kako gateovi smanjuju rizik za rokove#

Gate je koristan samo ako sprječava rework. Najskuplji bugovi otkriju se kasno, kada je kontekst izgubljen i više promjena je “spakirano” zajedno.

DORA research program konzistentno povezuje jake inženjerske prakse s boljim performansama isporuke softvera. High performeri postižu i brže lead timeove i veću stabilnost, bez trade-offa. Gateovi su dio načina kako do toga doći, kada su dizajnirani oko rizika, a ne birokracije.

# Observability: QA koji se nastavlja nakon deploya#

Testiranje smanjuje vjerojatnost kvara. Observability smanjuje cijenu kvara i skraćuje povratne petlje. To je ono što održava brzu isporuku kroz mjesece, ne samo tijekom jednog releasea.

Implementiramo logging, metrike i tracing kako bi problemi bili “actionable”, a ne misterij. Za dublji uvid pročitajte naš vodič: Web app observability with logging, metrics, and tracing.

Što instrumentiramo po defaultu#

Instrumentiramo oko korisničkih putovanja i poslovnih događaja, ne samo infrastrukture.

• Strukturirani logovi s request ID-jevima i korisničkim kontekstom kada je sigurno
• Metrike za error rate, latenciju i throughput
• Traceovi od web servera do downstream servisa gdje je moguće
• Poslovne metrike poput grešaka u checkout konverziji ili neuspjelih plaćanja
• Alerti koji se pale na utjecaj, ne na šum

Observability kao release gate#

Za nove proizvode ili velike module, observability tretiramo kao dio definition of done:

• Dashboard postoji za core user journey
• Alerti postoje za spikeove grešaka i regresije latencije
• Dogovoren je on-call ili eskalacijski put za launch prozor

To sprječava čestu situaciju gdje produkcija postane prvo pravo testno okruženje.

# Kako klijenti profitiraju: Predvidljiv delivery i manje incidenata u produkciji#

Strategija testiranja treba se prevesti u poslovne ishode. Evo što klijenti tipično vide kada implementiramo ovaj end-to-end pristup.

Kraći QA ciklusi kroz fokus i automatizaciju#

Kada risk-based testiranje određuje što automatiziramo, timovi prestaju gubiti vrijeme na regresiju male vrijednosti. Mali, pouzdan e2e smoke suite plus snažna unit i integracijska pokrivenost tipično svode “dan ručne regresije” na ciljanu checklistu.

U praksi to znači:

• Manje čekanja na QA sign-off
• Manje iznenađenja tipa “otkrili smo ovo prekasno”
• Brže iteracije na UX-u jer su core tokovi zaštićeni

Bolja stabilnost kroz testiranje granica#

Contract testovi i integracijski testovi hvataju kvarove koje e2e testovi često promaše ili uhvate prekasno. To je posebno vrijedno za proizvode web + mobile gdje API drift može slomiti samo jednog klijenta.

Brže debugiranje kroz observability#

Kada se problemi dogode, logovi, metrike i traceovi skraćuju vrijeme istrage. Umjesto pokušaja reprodukcije nejasnog reporta, možemo brzo locirati korak koji pada, payload, segment korisnika ili downstream ovisnost i isporučiti ciljanu ispravku.

ℹ️ Napomena: Ovo je i mjesto gdje n8n posebno profitira. Workflow koji logira correlation ID i ključne decision brancheve puno je lakše validirati i održavati nego onaj koji tiho “pada”.

# Ključne poruke#

• Koristite ocjenjivanje rizika da odlučite gdje ulagati: duboki testovi i strogi release gateovi za tokove visokog utjecaja, lakše provjere za niskorizične UI promjene.
• Gradite povjerenje slojevito: unit testovi za logiku, integracijski i contract testovi za granice, te mali e2e suite za revenue-kritična korisnička putovanja.
• Tretirajte n8n workflowe kao produkcijski kod s replayable payload fixtureima, eksplicitnim očekivanim ishodima i idempotency provjerama.
• Implementirajte release gateove koji sprječavaju kasni rework, i vrtite najmanje smislene provjere na pull requestovima kako bi feedback bio brz.
• Uvedite observability kao dio done kako bi produkcija validirala ponašanje uz actionable logove, metrike, traceove i alertove temeljene na utjecaju.

# Zaključak#

Brža isporuka bez lomljenja stvari nije pitanje biranja između brzine i kvalitete. Radi se o sustavu testiranja koji je risk-based, automatiziran tamo gdje je važno i potkrijepljen observabilityjem kako biste brzo učili iz stvarne upotrebe.

Ako želite agenciju za strategiju softverskog testiranja koja može postaviti ovaj end-to-end pristup kroz Next.js, Flutter i n8n, možemo napraviti audit vašeg trenutnog pipelinea i predložiti praktičan plan s release gateovima, ciljevima pokrivenosti testovima i osnovama observabilityja. Krenite s pregledom našeg pristupa deliveryju u našem procesu web developmenta korak po korak, a zatim se javite Samiodi za roadmap implementacije prilagođen vašem proizvodu.