Programvareteam som organiserer seg selv, bruker et bredere spekter av verktøy enn noen gang tidligere. I et typisk programvareteam kan det være så mange som tjue eller til og med tretti verktøy i bruk. For å hjelpe deg med å navigere i alt dette skal vi i denne artikkelen se på:
- Verktøy for testing
- Verktøyarkitektur
- Teststyring
- Testdesign
- Proprietære løsninger eller åpen kildekode?
- En øvelse i verktøyvalg
La oss først se på hovedtypene verktøy du kommer til å bruke i testingen.
Verktøy for testing
Det er praktisk å dele verktøyene som er relevante for testing, inn i tre typer:
- Samarbeidsverktøy: Disse støtter innsamling av ideer og krav, kommunikasjon på tvers av teamet med noe integrasjon mot automatiserte prosesser, og noen ganger roboter.
- Testverktøy: Et stort spekter av verktøy som støtter testdatabehandling, testdesign, enhetstestingsrammeverk, funksjonell testkjøring, ytelses- og belastningstesting, statisk testing, testdesign, styring av testprosessen, testtilfeller, testlogging og rapportering.
- DevOps- eller infrastrukturstyringsverktøy: Disse verktøyene støtter miljø- og plattformstyring, distribusjon ved hjelp av infrastruktur som kode og containerteknologier, samt logging, overvåking og analyse i produksjon.
The Tools Knowledge Base er et nettbasert register over verktøy som skiller seg fra de fleste nettbaserte registre ved at registeret dekker samarbeid, testing og DevOps. Det finnes over 1700 verktøy innenfor disse tre områdene. Nettsidene til verktøyene er indeksert og søkbare.
Nettstedet samler også inn og indekserer over 300 bloggere, og over 52 000 blogger er også indeksert og søkbare. Vi har lagt inn URL-er til de viktigste verktøykategoriene og snarveier for søk i disse kategoriene i bloggene.
Det finnes over 1700 verktøy som støtter samarbeid, testing og DevOps.
Senere i denne artikkelen skal vi se på de viktigste utfordringene som påvirker og støtter teststyring.
Have an account? Log In
Verktøyarkitektur
I illustrasjonen nedenfor har vi identifisert utvalget av verktøytyper som de fleste moderne programvareteam bruker. Vi har skilt ut verktøy som vanligvis brukes i utviklings-, test- og produksjonsmiljøer.
Disse verktøyene bygger på infrastruktur som tilbyr plattformer, virtuelle maskiner og containere for å være vert for miljøer, samt verktøy som utfører automatiserte distribusjoner. Verktøyene som brukes til å håndtere distribusjoner og utgivelser, kalles verktøy for utgivelses- og rørkoordinering. Kommunikasjon i teamet, samt med mange av de automatiserte prosessene, håndteres av samarbeids- eller ChatOps-verktøy.
Selv om overgangen til DevOps driver utviklingen og innføringen av verktøy som støtter kontinuerlig utvikling, er nesten alle disse verktøyene nyttige for alle utviklings- eller driftsteam for programvare.
Du trenger ikke å ha en DevOps-kultur for å bruke «DevOps»-verktøy.
Teststyring
Teststyringsverktøy er en nødvendighet i alle prosjekter av en viss størrelse. Smidige prosjekter tar vanligvis i bruk et verktøy for hendelseshåndtering og baserer seg, når det gjelder tester, i noen grad på bruk av brukerhistorier og scenarier for å følge opp viktige eksempler på, om ikke alle, tester. Teststyringsverktøy varierer i omfang fra svært enkle løsninger, som Microsoft Excel, til omfattende produkter for applikasjonslivssyklusstyring (ALM).
Generelt dekker teststyringsverktøy flere områder:
Modell for testdekning: De fleste teststyringsverktøy lar deg definere et sett med krav som testtilfeller og/eller kontroller i tester kan knyttes til. Disse kravene kan noen ganger være hierarkiske for å gjenspeile innholdsfortegnelsen i et dokument. Stadig flere modeller, som brukstilfeller eller flyter for forretningsprosesser, kan også registreres. Rapporter for dekning av testplaner og testgjennomføring er vanligvis tilgjengelige.
Testtilfellehåndtering: Testtilfeller og innholdet i dem kan administreres for å gi en dokumentert oversikt over tester. Innholdet i testtilfeller kan være utarbeidet på forhånd eller som en oversikt over tester som er gjennomført. Testtilfeller kan være i et fritt tekstformat eller struktureres i trinn med forventede resultater. Det er vanlig å importere dokumenter og bilder som skal lagres sammen med tester eller trinn.
Planlegging av testgjennomføring: Tester kan struktureres i et hierarki eller merkes for å gi en mer dynamisk struktur. Medlemmer av testteamet kan få tildelt tester. Planlagte testvarigheter kan brukes til å publisere en synkronisert tidsplan for tester som skal kjøres av teamet. Delmengder av tester kan velges for å oppnå kravdekning, teste utvalgte funksjoner og kjøre regresjonstestsett på nytt. Tester som er logget som ikke kjørt ennå, blokkert, mislykket eller med en annen status, kan også velges for gjennomføring.
Testgjennomføring og logging: Når teamet kjører tester, registreres statusen for testene. For alle tester som kjøres, registreres testeren samt dato, klokkeslett og varighet. Tester som består, kan tildeles en enkel bestått-status. Mislykkede, blokkerte eller avvikende testresultater kan få tilknyttet skjermbilder og testresultater, og en hendelsesrapport kan tildeles. Mange verktøy tilbyr integrasjonspunkter mot verktøy for testgjennomføring som administrerer og kjører tester, logger resultater og til og med oppretter utkast til hendelsesrapporter.
Hendelseshåndtering: Testfeil logges i gjennomføringsloggen. Disse krever vanligvis nærmere undersøkelse, med feilsøking og retting når en feil skyldes en programvarefeil. Feil som krever undersøkelse, registreres vanligvis ved hjelp av hendelsesrapporter, observasjonsrapporter eller feilrapporter. Hendelsesrapporter kan inneholde store mengder støtteinformasjon. Vanligvis tildeles hendelser en type, et objekt som testes, en prioritet og en alvorlighetsgrad. Noen selskaper logger svært store mengder informasjon og kobler den til en avansert prosess for hendelseshåndtering.
Rapportering: Rapporter og analyser av data fra alle funksjonene ovenfor kan opprettes etter behov. Utvalget av rapporter varierer fra planlagt mot faktisk testdekning og status for hendelsesrapporter, for å følge opp gjenstående undersøkelses-, rettings- og nytestingsarbeid, til analyser av tid til retting for ulike feil, etter funksjon, alvorlighetsgrad og hvor mye det haster, og så videre.
Det mest populære teststyringsverktøyet på planeten er fortsatt Microsoft Excel.
Testdesign
Testdesign er basert på modeller. For system- og akseptansetestere er typiske modeller kravdokumenter, brukstilfeller, flytskjemaer eller svømmebanediagrammer. Mer tekniske modeller, som tilstandsmodeller, samarbeidsdiagrammer, sekvensdiagrammer og lignende, gir også et godt grunnlag for testdesign.
I mange prosjekter brukes modeller til å fange opp krav eller overordnede design. Når de gjøres tilgjengelige for testere, kan de brukes til å spore stier for å hente dekningspunkter direkte fra modellen. Hvis slike modeller ikke er tilgjengelige, er det ofte nyttig for testteamet å utarbeide for eksempel prosessflytskjemaer eller svømmebanediagrammer. Disse hjelper testere med å ha mer meningsfulle diskusjoner med interessenter, særlig når det gjelder tilnærmingen til dekning.
På området for proprietære løsninger kommer det stadig nye verktøy som gjør det mulig å registrere modeller som flytskjemaer og bruke dem til å generere testtilfeller ved å spore stier i henhold til et bestemt dekningsmål, for eksempel alle koblinger, alle prosesser, alle beslutningsutfall, alle par eller alle stier. Disse verktøyene kan kobles sammen med verktøy for testdatahåndtering og -generering for å generere kombinasjoner av testdata som kan brukes med manuelle eller automatiserte tester.
Det finnes også verktøy som gjør det mulig å utføre modellering i verktøy for testgjennomføring. Som et eksempel kan disse verktøyene la testutvikleren registrere alle feltene på en nettside, opprette koblinger for å «koble sammen» feltene og lage en navigasjonsmodell for siden – alt i et grafisk format.
Modellen brukes deretter til å opprette navigasjonsstier og lage en testserie som oppfyller bestemte dekningskriterier – akkurat som modelleringsverktøyene ovenfor. Disse gjennomføringsverktøyene kan opprette automatiserte teststier ved hjelp av valgte kriterier eller generere dem tilfeldig, og de kan også rapportere dekning opp mot disse modellene.
Dette er et område i rask utvikling for øyeblikket – følg med på modelleringsverktøy som støtter testdesign og testgenerering, samt gjennomføringsverktøy som støtter modellering av systemet som testes og automatisert valg og rapportering av teststier.
More Articles
Proprietært eller åpen kildekode?
De siste tjue årene har bruken av produkter med fri og åpen kildekode (FOSS), særlig til drift av infrastruktur, vært utbredt. Kostnadene ved operativsystemlisenser og tilhørende webserverprogramvare fra Microsoft, samt den generelle oppfatningen av at Linux/Unix er mer pålitelig og sikkert enn Windows, innebærer at Linux/Unix er det foretrukne operativsystemet for servere i mange miljøer.
Selv om artikkelen diskuterer fordeler og ulemper ved verktøy med åpen kildekode og proprietære verktøy, kan vår omfattende veiledning om testadministrasjonsverktøy som er spesifikke for Jira hjelpe deg med å ta en informert beslutning hvis du spesifikt ser etter løsninger som integreres godt med Jira.
De to tabellene nedenfor (oppdatert daglig på w3techs.com) viser den relative populariteten til operativsystemer og webserverprodukter. Rundt 85 % av nettstedene kjører de mest kjente webserverproduktene med åpen kildekode, Apache og Nginx.
Populariteten til disse FOSS-infrastrukturproduktene beviser at åpen kildekode kan være minst like pålitelig som, om ikke mer pålitelig enn, proprietære produkter.
For et programvareteam som trenger de tjue eller tretti programvareverktøyene som støtter aktivitetene deres, finnes det pålitelige og funksjonelle FOSS-verktøy og proprietære verktøy for alle oppgaver. Hvordan velger du mellom et proprietært produkt og et FOSS-produkt?
Tabellen nedenfor oppsummerer noen av vurderingene du kan gjøre når du velger verktøytype.
| Proprietært | FOSS | |
| Tilgjengelighet | Verktøy er tilgjengelige for alle områder. | Noen områder, særlig utviklings- og infrastrukturverktøy, har bedre støtte enn andre. |
| Innkjøpskostnad | Ofte dyrt, særlig «bedriftsprodukter». | Gratis, eller lisens for bruk i fellesskapet uten kostnad. Kommersielle lisenser kan finnes for bedrifts- eller vertsbaserte versjoner. |
| Dokumentasjon | Vanligvis svært god. | Varierer. Noen ganger utmerket, andre ganger ikke-eksisterende, og alt imellom. Ofte skrevet av programmerere for programmerere, og derfor mindre brukervennlig enn kommersiell dokumentasjon. |
| Teknisk støtte | Svært god, mot betaling. | Varierer. Noen verktøyforfattere tilbyr utmerket støtte og legger til og med til funksjoner på forespørsel. Mange verktøy har nettfora – men de kan være svært tekniske. Andre verktøy har dårlig støtte. |
| Pålitelighet/kvalitet | Vanligvis svært god. | Varierende. Produkter med mange brukere, lokaliteter og store støtteteam har en tendens til å være utmerkede. Noen verktøy som er skrevet av enkeltpersoner med få bidragsytere og få brukere, kan være ustabile. |
| Funksjonsrikdom | Funksjonssettene følger vanligvis publiserte produktplaner og er som regel omfattende. | Produktene utvikler seg vanligvis basert på brukernes behov og størrelsen på teamet av bidragsytere. Bidragsytere har en tendens til å legge til funksjoner de selv trenger, snarere enn å basere seg på kundeundersøkelser, for eksempel. |
| Frekvens for utgivelser/oppdateringer | Det går vanligvis måneder, noen ganger år, mellom større utgivelser. Regelmessige oppdateringsutgivelser. Varsler og utgivelsesmerknader er som regel svært gode. | Varierer. Større utgivelser av infrastrukturprodukter – som for proprietære produkter. Mindre og mindre populære produkter utgis vanligvis oftere. Lite eller ingen varsling, dårlige utgivelsesmerknader og manglende bakoverkompatibilitet fra tid til annen. |
FOSS-produkter kan være billigere å anskaffe, men andre kostnader og ansvarsområder kan være betydelige. Det avgjørende mellom de to er vanligvis en blanding av kulturen din, risikoviljen din og den tekniske kompetansen din.
Når du kjøper proprietære produkter og supportavtaler, er risikoen knyttet til inkompatibilitet (med andre produkter), pålitelighet, brukervennlighet og oppmerksom teknisk støtte generelt lav, selv om det noen ganger kan være dyrt.
Med FOSS-produkter må du vanligvis gjøre langt mer omfattende undersøkelser før du forplikter deg til å bruke et av dem. Det finnes tross alt ingen selger å snakke med, og dokumentasjonen kan være funksjonell snarere enn informativ. En prøveperiode er selvfølgelig enkel å sette opp, og du kan ta i bruk så mange verktøy du ønsker, men du må gjøre en grundigere undersøkelse av verktøyets funksjonalitet.
Dårligere brukervennlighet og inkompatibilitet med de eksisterende verktøyene dine kan føre til problemer, så du kan bli nødt til å skrive integrasjonsprogramvare eller programtillegg samt verktøy for rapportering eller import/eksport av data.
Du må også lære opp deg selv og teamet ditt for å få dem opp på et tilstrekkelig nivå, og vanligvis stå for din egen programvarestøtte. Teamet ditt vil imidlertid ha en mer inngående kjennskap til hvordan verktøyet fungerer, og i stor grad kunne støtte seg selv.
Et FOSS-verktøy kan hjelpe deg med å få erfaring med en ny type verktøy til en lav kostnad. Med denne erfaringen vil du være bedre rustet til å velge et proprietært verktøy på lang sikt.
En øvelse i valg av verktøy
Hvis du ser etter et teststyringsverktøy som støtter det nåværende eller et kjent, nylig prosjekt og program, kan du med utgangspunkt i funksjonsområdene som er omtalt ovenfor i diskusjonen om teststyringsverktøy, lage en liste over 15–20 funksjoner som enten er:
- Obligatoriske
- Ønskelige
Dette kan omfatte funksjonelle egenskaper, integrasjoner, fokus på brukervennlighet, støtte eller en stor brukerbase, eller nettfora/FAQs. Hvis du allerede har et verktøy på plass, må du ikke velge det.
Bruk teksten i kravene dine og søk i Tools Knowledge Base for å finne tre verktøy (inkludert et proprietært produkt og et FOSS-produkt) som ser ut til å oppfylle kravene dine. Bruk funksjonsbeskrivelsene for verktøyene til å lage en funksjonssammenligningstabell for de tre produktene. Legg til en fjerde kolonne for verktøyet du faktisk bruker, slik at det kan sammenlignes.
- Hvordan står verktøyene seg når det gjelder funksjoner?
- Hvilke funksjoner mangler FOSS-verktøyene sammenlignet med de proprietære verktøyene?
- Hvor mange verktøy finnes det som i grove trekk oppfyller kravene dine?
- Hvor lang tid tror du at du måtte bruke på å undersøke verktøy for å sette opp en kortliste med for eksempel tre?
Meld deg på nyhetsbrevet til The QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls Leadership In Test-kurs – det anbefales på det sterkeste for deg som ønsker å gå dypere inn i dette og andre temaer. Hvis du gjør det, kan du bruke vår eksklusive kupongkode QALEADOFFER for å få $60 i avslag på full kurspris!
Lær av andre testere ved å lytte til podkastene våre eller lese bloggene våre. Her er én vi tror du kan lære mye av: HVORDAN TESTFERDIGHETER GJORDE MEG TIL EN BEDRE AUTOMATISERINGSUTVIKLER
