Udforsk test af skift til venstre
Test i administration af programlivscyklus er afgørende for at maksimere kodekvaliteten og minimere den driftsmæssige risiko, der er forbundet med udrulning og opdatering af software. Udtrykket shift-left i denne sammenhæng formidler ideen om at flytte testaktiviteter så tidligt som muligt i udviklingsfasen. Organisationen i vores eksempelscenarie bør overveje at indarbejde denne tilgang i sin DevOps-strategi for at minimere de aktuelle sikkerheds- og stabilitetsproblemer. I denne lektion skal du gennemgå forskellige typer test, der kan implementeres på denne måde, og derefter undersøge deres implementeringsmetoder.
Hvilke test skal være en del af shift-left-test?
Softwareudvikling omfatter en lang række testtyper, men dem af særlig interesse for os omfatter:
Enhedstests: Disse test fokuserer på de mindste testbare dele af en programkode, f.eks. individuelle funktioner eller metoder. Målet er at fastslå, om hver kodeenhed kan udføre den tilsigtede handling isoleret fra resten af kodebasen og eksterne afhængigheder. Sådanne test bør være fuldt automatiserede, hurtige (fuldføres inden for 30 sekunder) og give fuld kodedækning (hvilket dybest set betyder, at alle enhedstests samlet skal teste hele kodebasen). Enhedstest er velegnet til skift-venstre-tilgangen. Vi anbefaler, at du anvender den på al kode så tidligt i udviklingscyklussen som muligt, helst i begyndelsen af programmeringsfasen.
røgtests: Disse test er beregnet til at vurdere kernefunktionaliteten af et program i et testmiljø. Selvom de tester det faktiske program (i stedet for dets individuelle, isolerede komponenter, som enhedstests gør), er deres formål at afgøre, om programbuildet eller -installationen er tilstrækkeligt stabilt til at sikre en mere dybdegående test. De bekræfter dog ikke interoperabilitet mellem apps. Som med enhedstests skal de automatiseres fuldt ud og relativt hurtigt (brugerinteraktion kan simuleres ved hjælp af browserautomatiseringsværktøjer og automatiseringsrammer for brugergrænsefladen). Udtrykket røgtest er beregnet til at formidle ideen om røg, der angiver et stort problem (brand), der bør behandles så hurtigt som muligt. Røgtest bør også implementeres tidligt i udviklingscyklussen, helst så snart en version af softwaren, der leverer dens kernefunktionalitet, er tilgængelig. Dette gælder både for programbuild- og udrulningsfaserne.
integrationstests: Disse test validerer interaktionen mellem forskellige programkomponenter. I modsætning til enhedstests kan det tage lang tid at fuldføre dem. Den forlængede varighed af disse test bruges ofte som et argument for at køre dem tidligt i softwareudviklingslivscyklussen. Generelt bør du overveje integrationstest i scenarier, hvor enheds- eller røgtest ikke er egnede. Anbefalingen er dog at planlægge, at de skal udføres med jævne intervaller. Denne fremgangsmåde giver et rimeligt kompromis mellem en potentiel forsinkelse i registreringen af integrationsproblemer og en ekstra ventetid, der kræves for at fuldføre dem.
accepttests: Disse test afgør, om et softwareprodukt opfylder de forretningsmæssige krav og er klar til levering til sine forbrugere. Accepttest er ikke egnet til shift-left-strategien, men det kan være muligt at inkorporere nogle af elementerne tidligt i softwareudviklingslivscyklussen. Eksempelvis bør acceptkriterier og brugerhistorier, som er vigtige komponenter i accepttest, introduceres tidligt i udviklingsprocessen. Dette faciliterer samarbejde mellem udviklingsteams, produktejere og projektinteressenter. Derudover bør softwareforbrugere og projektaktører være involveret i de tidligere testfaser for at dele deres feedback. Dette kan omfatte brug af metoder som alfa- eller betatest, anvendelighedstest eller tidlige udgivelser forud for den formelle accepttest.