Utforsk skift-venstre-testing
Testing i programmets livssyklusbehandling er viktig for å maksimere kodekvaliteten og minimere driftsrisiko forbundet med distribusjon og oppdatering av programvare. Begrepet skift-venstre- i denne sammenhengen formidler ideen om å flytte testaktiviteter så tidlig som mulig i utviklingsfasen. Organisasjonen i vårt eksempelscenario bør vurdere å innlemme denne tilnærmingen i devOps-strategien for å minimere gjeldende sikkerhets- og stabilitetsproblemer. I denne enheten kan du se gjennom ulike typer tester som kan implementeres på denne måten, og deretter undersøke implementeringsmetodene.
Hvilke tester bør være en del av skift-venstre-testing?
Programvareutvikling inkorporerer et bredt spekter av testtyper, men de av spesiell interesse for oss inkluderer:
Enhetstester: Disse testene fokuserer på de minste testbare delene av en programkode, for eksempel individuelle funksjoner eller metoder. Målet er å fastslå om hver kodeenhet kan utføre den tiltenkte operasjonen isolert fra resten av kodebasen og eksterne avhengigheter. Slike tester bør være helautomatiske, raske (komplette innen 30 sekunder), og gi full kodedekning (noe som i utgangspunktet betyr at alle enhetstester kollektivt skal teste hele kodebasen). Enhetstesting er egnet for skift-venstre-tilnærmingen. Vi anbefaler at du bruker den på all kode så tidlig i utviklingssyklusen som mulig, fortrinnsvis i begynnelsen av programmeringsfasen.
Røyktester: Disse testene er ment å vurdere kjernefunksjonaliteten til et program i et testmiljø. Mens de tester det faktiske programmet (i stedet for individuelle, isolerte komponenter, som enhetstester gjør), er deres formål å avgjøre om programbygget eller distribusjonen er tilstrekkelig stabil til å garantere mer grundig testing. De bekrefter imidlertid ikke interoperabilitet mellom apper. Som med enhetstester bør de være helautomatiske og relativt raske (brukersamhandling kan simuleres ved hjelp av nettleserautomasjonsverktøy og rammeverk for automatisering av brukergrensesnitt). Begrepet røyktest er ment å formidle ideen om røyk som indikerer et stort problem (brann) som bør løses så snart som mulig. Røyktesting bør også implementeres tidlig i utviklingssyklusen, fortrinnsvis så snart en versjon av programvaren som gir kjernefunksjonaliteten er tilgjengelig. Dette gjelder både for programbygg- og distribusjonsfasene.
Integreringstester: Disse testene validerer samhandling mellom ulike programkomponenter. I motsetning til enhetstester kan de ta mye tid å fullføre. Den utvidede varigheten av disse testene brukes vanligvis som et argument for å kjøre dem tidlig i livssyklusen for programvareutvikling. Generelt bør du vurdere integreringstester i scenarioer der enhets- eller røyktester ikke er egnet. Anbefalingen er imidlertid å planlegge at de skal utføres med jevne mellomrom. Denne tilnærmingen gir et rimelig kompromiss mellom en potensiell forsinkelse i å oppdage integreringsproblemer og en ekstra ventetid som kreves for å fullføre dem.
aksepttester: Disse testene avgjør om et programvareprodukt oppfyller forretningskravene og er klar for levering til sine forbrukere. Aksepttesting er ikke egnet for skift-venstre-strategien, men det kan være mulig å innlemme noen av elementene tidlig i livssyklusen for programvareutvikling. Akseptkriterier og brukerhistorier, som for eksempel er viktige komponenter i aksepttesting, bør innføres tidlig i utviklingsprosessen. Dette forenkler samarbeid mellom utviklingsteam, produkteiere og prosjektinteressenter. I tillegg bør programvareforbrukere og prosjektinteressenter være engasjert i de tidligere testfasene for å kunne dele tilbakemeldingene sine. Dette kan innebære bruk av slike metoder som alfa- eller betatesting, anvendelighetstesting eller tidlige utgivelser, i forkant av den formelle aksepttestingen.