SaaS: Hold kompleksitet og korte tidslinjer fra å påvirke kvaliteten

Dette er den siste delen av en serie på SaaS. Her er de første delene:

  • Verdensklasse SaaS-Bygge et holdbart konkurransedyktig aktivum
  • Ikke la rusa fare SaaS helse

Det er allment kjent at de fleste programvareselskaper sliter med å opprettholde kvaliteten jevnlig. Du har kanskje til og med hørt vitsene om hvorfor Microsoft aldri kunne produsere biler. Det er mange grunner til at kvaliteten er så vanskelig å opprettholde i programvareindustrien - industrien modnes fremdeles, programvare er ofte spesielt komplisert og den viktige kvaliteten på handel på grunn av stramme tidsfrister er blant dem. Og i SaaS-verdenen er den kompleksiteten enda høyere på grunn av skalaer og ytelseskrav, støtte for tredjepartsutviklere og så videre.

SaaS gir deg imidlertid noen ekstra spaker som kan hjelpe med kvalitet. Det dukker opp en interessant trend der noen SaaS-selskaper flytter bort fra ideen om en QA-ingeniør. Denne bloggen vil diskutere noen strategier for å bygge SaaS-produkter av høy kvalitet, og også et synspunkt på denne trenden.

Engasjement og kultur

Å bygge programvare av høy kvalitet trenger organisatorisk engasjement fra alle på teamet og begynner med ingeniør- og produktledere. Når beslutningen kommer ned på om du trenger litt mer tid for å sikre produktkvalitet eller overholde en tidsfrist; hvilken vei går de fleste beslutninger? Dommen er selvfølgelig nødvendig i alle tilfeller, men kvalitet trenger en stemme og må være en del av diskusjonen sammen med andre forretningsbetraktninger. Teammedlemmene må få fullmakt til å rekke opp hånden og lage en sak der de mener at et produkt ikke kan sendes. Dette krever en kultur som oppmuntrer og belønner de håndsøkere.

Teststrategi

Vi har lært at små, trinnvise utgivelser har den høyeste kvaliteten fordi de inneholder minst mulig risikofylt forandring. Så hvorfor slipper vi ikke hver dag? Hvert minutt? Det vanlige svaret på dette spørsmålet er at fordi det er en viss fast kostnad eller varighet å frigjøre, og at faste kostnader domineres av noen manuell regresjonstesting eller annen validering av den endelige byggingen.

Dette er grunnen til at automatisering er konge. Pyramiden nedenfor viser hvilke typer testing og dekning den gir. Enhetstester, integrasjon og UI-testing gir mer dekning i den rekkefølgen, og bør alle automatiseres. Automatisert testing gir de mest pålitelige resultatene og den bredeste dekningen på raskeste tid. UX-testing utføres med sluttbrukerhatten på for å teste produktbrukbarhet. Ideelt sett er det den eneste typen manuell testing. Denne tilnærmingen krever en betydelig investering i testing av infrastruktur, som går igjen i hvorfor organisatorisk engasjement kommer først.

SaaS spaker

Det er en høy pris å betale for en lekker lek for både krympeprogramvare og SaaS. Lapper er dyre, og at feilen noen gang har kommet ut skader merkevaren. For SaaS-produkter er det imidlertid noen ekstra spaker tilgjengelig for å dempe denne risikoen med en kontrollert utgivelse av en funksjon eller app.

Forsikre deg om at du kan kontrollere hvor mange kunder som får en ny versjon av programvaren basert på denne risikoen. For eksempel antar at funksjon X rulles ut bare til .5% av kundebasen og overvåkes nøye før du gradvis øker skiven og ruller den ut til flere kunder. Dette lar deg avdekke problemer før det rammer massene.

Forsikre deg også om at du har øyeblikkelig tilbakespillingskapasitet hvis du avdekker et alvorlig problem. Dette erstatter ikke kritikken for å få det riktig første gang, og byggekvalitet i det bør sees på som en forsikring og ikke måten å teste produktet på.

Kvalitetstrender

Det er noen SaaS-selskaper som flytter bort ingeniørfaglige roller. Forventningen er at ingeniører skal gjøre både utvikling og testing. Be en QA-ingeniør om deres mening om den strukturen, så hører du at dette aldri vil fungere. Jeg tror denne trenden vil få damp i fremtiden, men den bredere industrien er ikke klar for det.

Hvis du vurderer å gå over til denne modellen for din bedrift, fortsett med forsiktighet. Tenk nøye gjennom hvor organisasjonen din er og transformasjonen som kreves for at denne modellen skal fungere. Selv om du ikke er klar til å gå helt til denne modellen, er det en god ting å ha utviklere å gå lenger og lenger opp i testtrekanten og hjelpe deg med å få mer dekning.

Ideelt sett er det en intern anerkjennelse i utviklingsteamet som alle eier kvalitet. På Lithium kaller vi det å være "avhengig av utført". Det er ikke ferdig før det er testet, og vanligvis er den raskeste måten å komme til utført å teste den selv (eller skrive den automatiserte testen, se over).

Når industrien fortsetter å modnes, kan vi bare forvente å møte økende kompleksitet over kortere tidslinjer - to store trusler mot produktkvaliteten. Men med riktig forpliktelses-, kultur- og teststrategi, kan ditt SaaS ingeniørteam møte disse pressene mot deg uten at de gamle kjente ofrene for produktkvalitet holder deg oppe om natten.

Som SVP for ingeniørvirksomhet og drift overvåker Sunil Rajasekar kjerneutvikling og levering av Lithiums bedrifts sosiale kundeplattform.

© Copyright 2021 | mobilegn.com