Skaalautuv kvaliteedikontroll ja testimisprotsess teie

Ausalt öeldes ei ole kvaliteedi tagamine MVP loomise ajal alati teie tegevuste nimekirjas. Tõenäoliselt pingutate, et täita tähtaegu, teha toote turule sobivuse teste ja võib-olla isegi koguda rahalisi vahendeid – kõike seda korraga. Piiratud eelarve puhul on kiusatus jätta kvaliteedikontroll hilisemaks. Kuid tegelikkus on selline, et kui teie MVP on vigane, rikkis või kasutamisel frustreeriv, siis te ei pruugi saada teist võimalust asju parandada. Kliendid nõuavad lihtsat kasutuskogemust ja idufirmasid hinnatakse nende esialgse turuletoomise järgi. Kvaliteedikontrolli ohverdamist võib võrrelda pidurite ohverdamisega võidusõiduautos – võite olla kiire, kuid kaugele te ei jõua. Hea uudis? Pole vaja kvaliteedikontrolli osakonda ega kulukaid automatiseerimisplatvorme. Kõik, mida vajate, on kerge strateegia, mis sobib teie praeguse etapiga ja laiendab teie toodet. Juhend tutvustab teile kõike, mida peate teadma selle protsessi loomiseks, sealhulgas testimise meetodeid ja vahendeid ning skalpeeruvaid nutikaid strateegiaid.

MVP idee on kiire käivitamine ja kiire õppimine. Siiski on oluline, et sel juhul peaks MVP olema funktsionaalne. Põhitoode on sobiv. Rikkis toode ei ole. Teie parimad kasutajad on varased kasutuselevõtjad. Nad annavad tagasisidet, reklaamivad teie toodet ja aitavad kaasa teie tegevuskava koostamisele. Kui aga teie rakendus logimise käigus kokku jookseb või teie kasutuselevõtu protsess on vigane, lähevad nad ära ja ei tule kunagi tagasi. See annab teile kindluse, et saate oma toodet kasutada, tutvustada ja skaleerida.

Tegelik mõju: mida kvaliteedikontroll tegelikult pakub

• Kiirem iteratsioon: kui vead avastatakse varakult, peavad arendajad kulutama vähem aega probleemide lahendamisele.
• Kvaliteetsem tagasiside: kvaliteedikontroll tagab, et kasutajad saavad läbida protsessi ja anda konstruktiivset tagasisidet.
• Minimaalne ümbertegemine: vea parandamine pärast käivitamist on 4–5 korda kallim kui enne käivitamist.
• Parem investorite arvamus: see on viimane asi, mida inimesed tahavad riskikapitalistidele esitada – vigane rakendus.
• Parem meeleolu meeskonnas: arendajad eelistavad luua uusi asju, mitte parandada vigu, mida kaks sprinti tagasi ei märgatud.

MVP väljakutsed ilma kvaliteedikontrollita

Et analüüsida, mis juhtub, kui kvaliteedikontrolli üldse ei teostata, vaatame esmalt, mis juhtub, kui kasutaja satub katkenud voo ette:

• Kasutajate lahkumine: ebastabiilsed vood saadavad kasutajad minema enne, kui saate isegi tagasisidet
• Võlg muutub tehniliseks võlgnevuseks: probleemid kuhjuvad ja järgmine arenguetapp muutub keerulisemaks
• Meeskonna stress: meeskonna arendajad on pidevalt pigem reaktsioonilised kui planeerivad
• Aeglane kasv: vigaste toodete puhul on raske turule siseneda või raha kaasata

Piisavalt lihtne. Igal funktsioonil võib olla kümneid teste, mida teostab täielik kvaliteedikontrolli osakond. MVPde puhul tuleb lihtsalt seada prioriteedid selle järgi, mis on oluline. Järgnev on lühendatud tarkvara testimise protsess, millega saate kohe alustada:

1. Nõuete valideerimine

Enne arendustöö alustamist veenduge, et see sisaldab järgmist:

• Selge
• Testitav
• Vastavuses kasutaja väärtusega

Te ei tea, mida tähendab funktsiooni edukus, kuidas te otsustate, millal see toimib?

2. Testplaani koostamine

Selleks ei pea olema geenius, praegu piisab Google'i tabelist. Loend:

• Funktsioonid, mida soovime testida
• Testige samme
• Oodatavad tulemused

Seda saab teha ka koos oma meeskonnaga. Kasutajate vood võivad pakkuda arendajatele, disaineritele ja isegi projektijuhtidele testjuhtumeid.

3. Testi täitmine

See on etapp, kus te toote käivitate. Eelistatavalt teeb seda isik, kes koodi ei kirjutanud (kuna tal on parem ülevaade sellest, mis puudub või ei tööta). Test:

• Lõpp-lõpuni vood (nt registreerumine, sisseelamine, põhitegevus)
• Äärmuslikud juhtumid (nt mis juhtub, kui jätan kohustusliku välja tühjaks?)
• Mitmed seadmed või brauserid (vähemalt Chrome ja Safari)

4. Veakontroll

Te ei vaja keerukaid süsteeme. Kasutage:

• Trello – kerge (ka visuaalne), suurepärane, kui teie meeskond seda juba kasutab
• GitHub Issues - parem, kui sul on juba meeskond olemas
• Jira – kohaldatav, kui töötate sprintides

Iga vea kirjeldus peaks sisaldama selle kordamise samme, ekraanipilte ja prioriteeti.

5. Regressioonitestimine

Kui viga on parandatud või lisatud uus funktsioon, testige kriitilisi teid uuesti. See aitab vältida tüütut tsüklit, kus ühe probleemi parandamisel tekib teine.

Veenduge lihtsalt, et see toimib. Käsitsi vs automaatne testimine

Mis sobib MVP-dele kõige paremini? See küsimus kerkib sageli esile. Ja see on täiesti õigustatud. Käsitsi testimine on lihtne käivitada. Pole vaja installida ega programmeerida, piisab teie tootest, kontrollnimekirjast ja inimesest, kes seda kasutab. Teisalt säästab automaatne testimine pikas perspektiivis aega, kuid osutub rakendamise seisukohalt ajamahukamaks. Mis on siis teie jaoks õige?

Alguses kasutage kvaliteedi tagamise käsitsi testimist.

Käsitsi testimine on teie piibel. Miks?

• See on kiire käivitada
• Saate testjuhtumeid kiiresti muuta, kui funktsioonid muutuvad
• Visuaalsed või kasutajaliidese testid

Võite kasutada kvaliteedi tagamise käsiraamatut. Testimine on eriti kasulik reaalajas demonstratsioonidel, enne turule toomist toimuvatel testidel ja kasutajate intervjuudel.

Kui automatiseerimine on mõistlik

Startupina on teil stabiilne MVP ja teil on:

• Saadetakse kord nädalas või kord päevas
• Säilitage järjepidev kasutajate voog
• Arendustiimi või kasutajate baasi suurendamine

Siin on mõned kättesaadavad ja odavad automatiseeritud testimise tööriistad, mis võivad huvi pakkuda:

Selenium

Algne avatud lähtekoodiga brauseri automatiseerimise raamistik. Mitme ülesande täitmine erinevates keeltes ja brauserites. Rakendused: meeskonnad, kes vajavad paindlikkust ja brauseritevahelist piirangut.

Cypress

Kaasaegne, lihtne kasutada ja brauseris töötav tööriist. JavaScript-põhine, lihtne kirjutada, lugeda ja hooldada. Parim: meeskonnad, kes loovad SPAd raamistikele nagu React või Vue.

Dramaturg

Avatud lähtekoodiga, kirjutatud Microsofti poolt ja põhineb Chromiumil, Firefoxil ja WebKitil. Testib kaasaegseid veebirakendusi ilma raskusteta. Parim: keerulisemad veebitestimise nõuded, näiteks mobiilseadmete emulatsioon.

Postman

Automaatseid API-kontrolle saab teha mitte ainult Postmani kogumise käivitaja ja monitoridega, vaid ka API-de käsitsi testimisel. Parim kasutamine: API-esimesed meeskonnad või raskekaalulised rakendused.

TestRail

Suurepärane testide, testitulemuste ja testide korraldamiseks. Parim: asutajad või projektijuhid, kes soovivad näha, mida testitakse.

Kuidas valida sobiv testimisplatvorm

Kõiki neid ei pea olema. Tegelikult, saatke mulle alguses vähem, siis saan rohkem. Küsige:

• Mis on meie stack? (JavaScript? Python? Midagi muud?)
• Mida me peame testima? (Veebiliides? API-d? Backend-loogika?)
• Milline on meie väljalaske sagedus?
• Kes kirjutab teste?

Valige vahendid, mis ei mõjuta teie meeskonda negatiivselt.

Teil on olemas vajalikud vahendid ja testplaan. Nüüd on aeg töötada välja strateegia, mis ei ole hea ainult täna, vaid mida saab ka homme laiendada.

1. Lisage kvaliteedikontroll oma CI/CD-sse

Kasutage GitHub Actions, GitLab CI või CircleCI, et teha iga push'i puhul lihtsaid teste. Isegi kui tegemist on vaid mõne lihtsa kontrolliga, arendab see häid harjumusi.

2. Kirjutage taaskasutatavad testjuhtumid

Iga kord, kui testite ühte voogu, peaksite sellest tegema korratava testjuhtumi. Salvesta see Notion-dokumendis või TestRailis. Sel viisil ei pea te iga sprindi alguses nullist alustama.

3. Prioriseerige automatiseeritavad tegevused

• Registreerimine
• Põhilised juhtpaneeli toimingud
• Logi sisse
• Maksed

Need on asjad, mida te iga sprindi jooksul testite. Automatiseerige need varakult, et need muutuksid lihtsamaks.

4. Vaadake üle kvaliteedikontroll iga sprindi järel

Iga sprindi lõppedes küsige:

• Mis läks katki?
• Mida me unustasime?
• Mis on parem: automatiseeritavus või dokumentatsioon?

Kvaliteedikontroll ei ole pelgalt test, vaid õppimisprotsess ja teie meeskonna tarkvara tarnimise viisi parandamine.

Skaalautuv kvaliteedikontrolli protsess aitab teil arendada toodet kiiremini, avastada probleeme varakult ja vältida kulukaid vigu. See muudab esialgsed kasutajate reaktsioonid tootearenduse osaks ja annab teie meeskonnale piisava enesekindluse, et rakendada uuendusi graafiku järgi. Kvaliteedikontrolli käsitlemine MVP osana, mitte kõrvalprojektina, võimaldab teil luua midagi, mida inimesed usaldavad, investorid hindavad ja arendajad naudivad. Ärge oodake, kuni teie rakendus kokku jookseb või teie algsed kasutajad on ära läinud. Ärge kartke mastaapi suurendada, sest teie loodava kvaliteet on osa sellest juba algusest peale.