what are iq oq pq 3 q s software validation process
Introduksjon til IQ-OQ-PQ:
IQ, OQ og PQ utgjør 3Q-ene for programvarevalideringsprosessen.
Som testere vet vi alle at programvareutviklingsteamet utvikler programvaren internt i henhold til programvarekravspesifikasjonen (SRS), funksjonell spesifikasjon og senere testteamet verifiserer implementeringen på forskjellige testnivåer i forskjellige testmiljøer, fra enkleste til high end, som dermed replikerer produksjonsmiljøet.
Med denne tilnærmingen til SDLC vasker programvareutviklingsteamet generelt hendene sine ved å overlevere den ferdige programvaren (utviklet og verifisert) til Operasjonsteamet. Videre er det Operations Team (vanligvis referert til som Ops Team) som tar seg av distribusjon av det til et produksjonsmiljø og gjør det klart til bruk av sluttbrukerne.
Her ligger den virkelige utfordringen for Operasjonsteamet å gjøre programvaren funksjonell i produksjonsmiljøet, for i løpet av programvareutviklingsfasene har utvikling og verifisering blitt gjort i et simulert miljø, og ganske sjelden nær det levende miljøet, bare i tilfelle av tilgjengelighet av data og konfigurasjoner av produksjonsmiljøet.
Det er her validering av programvaren kommer inn i bildet. Når bekreftelsen er fullført og programvaren er signert av Program- / produktteamet, vil Ops Team utføre et sett med aktiviteter før de aksepterer programvaren som skal distribueres til produksjonen, for å bevise at programvaren oppfører seg som forventet, som er ikke annet enn valideringsaktivitetene.
Hva du vil lære:
Bekreftelse mot validering
Her skal vi tydelig forstå forskjellen mellom 'Verifisering' og 'Validering' -aktiviteter. ' Bekreftelse 'Er å evaluere programvaren med hensyn til det gitte settet med krav og spesifikasjoner som gjøres internt på programvareutviklingsstedet av utviklere og testere.
Mens ‘ Validering 'Er et sett med kvalitetssikringskontroller som utføres av eksterne kunder, eiere, leverandører på produktet som blir levert til dem, for å kontrollere egnetheten før de godtar eller kjøper produktet. Valideringsaktiviteter utføres for det meste på produksjonsstedet.
Derfor, i tilfelle applikasjonsutvikling, er det Ops Team som utfører valideringsaktivitetene for programvaren.
Les også:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
Faser av valideringsprosessen
Generelt refererer valideringsprosessen til et produkt til hele produktets livssyklus fra utvikling gjennom bruk og vedlikehold. Og dermed er valideringsprosessen delt inn i 5 faser.
5 faser av valideringsprosessen er:
Denne 5-fasetilnærmingen av valideringsprosessen følges i mange bransjer som produksjon, medisin, legemidler etc. Her blir validering utført av sluttkunden før du kjøper maskiner, utstyr eller produktet.
Bestanddelene av valideringsaktivitetene for en programvare er å bevise at 'programvaren er klar til forbruk av brukerne', og å hovedsakelig verifisere vellykket installasjon av programvaren etterfulgt av funksjonalitet og brukbarhet.
3Qs tilnærming: IQ-OQ-PQ
Imidlertid, i programvaresammenheng 3Qs tilnærming, IQ-OQ-PQ blir fulgt som en del av validering, og den vil bli utført av operasjonsteamet, som til slutt er ansvarlig for å distribuere programvaren til produksjonen.
Nedenfor er strømningsdiagrammet for valideringsprosessen:
Malen, planen og andre dokumenter som legges inn for å utføre 3Q-ene, vil bli lagt ut av programvareteamet for programvaren, og den inkluderer detaljert tilnærming, oppgaver / aktiviteter / tester som skal gjennomføres som en del av disse kvalifikasjonene med testresultatene.
Sammendragsrapporter vil bli overlevert til Ops Team under programoverleveringen sammen med binærfiler og andre leveranser.
På høyt nivå,
Samlet sett er formålet med å utføre IQ, OQ og PQ å sikre at programvaren kan distribueres med suksess og alle funksjonene kan brukes uten flaskehalser.
Ideelt sett er IQ, OQ og PQ de sekvensielle aktivitetene som må utføres i rekkefølgen. Med mindre installasjonen er gjort, kan ikke funksjonaliteten til programvaren bekreftes, og med mindre funksjonaliteten er bevist, er det ingen vits i å måle ytelsen. Noen ganger på grunn av tidsbegrensning kan PQ starte parallelt med OQ, når de viktigste aspektene ved OQ er etablert.
La oss nå forstå mer om hver av disse tre fasene i detalj.
Installasjonskvalifisering (IQ)
Installasjonskvalifisering også referert til som ‘IQ’ , er valideringsprosessen om den medfølgende programvaren (binærfiler, skript osv.) kan installeres i det angitte miljøet med de spesifiserte konfigurasjonene, og for å verifisere hvordan disse installasjonstrinnene er registrert i dokumentet kalt ‘Installasjonsveiledning’.
Følgende varer leveres av utviklingsteamet sammen med den leverte programvarepakken og brukes av Ops-teamet til å utføre IQ.
1) ‘Installasjonsveiledning’-dokument, som dokumenterer installasjonstrinnene i de valgte miljøene.
to) 'Configuration Guide' dokument for å konfigurere konfigurerbar programvare. Noen ganger blir dette dokumentet en del av selve installasjonsveiledningsdokumentet.
3) Programvarepakke og installasjonsskript, helst automatiserte skript.
Programvareinstallasjon Kvalifiseringsfase anses å være den mest avgjørende og vanligvis mange problemer åpen opp i løpet av denne fasen.
Fordi:
til) Utviklingsmiljø vil ikke ha 100% sanntidsmiljø tilgjengelig for å verifisere installasjonsproblemene, og dermed bidrar en forskjell i miljøet til flere problemer.
b) På grunn av ulike årsaker kan det hende at det ikke er nok samarbeid og koordinering mellom utviklingen og driftsteamet i de innledende stadiene av programvareutvikling til å håndtere problemene i god tid.
c) Det kan være noen dokumentasjonsproblemer mens du registrerer de faktiske installasjonstrinnene i dokumentet, som kanskje ikke stemmer overens med produksjonsmiljøet.
I disse dager vil hele installasjonsprosedyren for programvare bli automatisert så mye som mulig via en serie skript. Hvis det er noen problemer med installasjonen, mislykkes den automatiske installasjonen på grunn av manglende samsvar i konfigurasjonene, og manuell intervensjon for å løse disse problemene er nødvendig.
Da Ops-teamet utfører IQ ved å følge instruksjonene som er gitt av programvareteamet i installasjonsveiledningen, er det veldig viktig og også ansvaret til programvareteamet å sørge for at 'Installasjonsveiledning' er skrevet på en slik måte at installasjonstrinn samsvarer med sanntidsmiljøet.
Og det er testernes ansvar å sørge for at installasjonsprosessen blir verifisert internt sammen med dokumentbekreftelsen for å være fullstendig, og å identifisere eventuelle feilkamp med de faktiske trinnene som skal kjøres på systemet mot de dokumenterte trinnene i Installasjonsveiledning.
Følgende punkter må huskes når du skriver en installasjonsveiledning og verifiserer dem internt, for å minimere problemene under installasjon av programvare under produksjon.
| SNO | Installasjonsveiledningspunkter |
|---|---|
| 7 | Den typiske tiden det tok å installere programvaren, bør nevnes i installasjonsveiledningen for Ops-teamet for å få en ide om den omtrentlige tidspunktet for installasjonen for å planlegge deres aktiviteter deretter. |
| 1 | Hovedsakelig og ytterst, ‘Installasjonsveiledningen’ skal være skrevet på et enkelt og lett å følge språk. |
| to | Må sørge for at den ikke går på lange, mer enn 5 sider. Det skal være kort og pent. |
| 3 | Må oppgi serienumrene for hvert utføringstrinn for å spore statusen. |
| 4 | Automatiser trinnene så mye som mulig og pakke dem alle sammen i ett enkelt skript. |
| 5 | En standard mal bør brukes til å skrive installasjonsprosedyren. |
| 6 | Forutsetninger bør nevnes tydelig for å unngå feilkamp og trinnene for å verifisere dem må gis. Hvis det er en feilkamp, bør du gi instruksjoner om å bringe dem opp til forventet nivå eller installere disse pakkene. |
| 8 | Tjenestene som må bringes ned under installasjonen, hvordan de skal bringes ned, virkningen av å bringe dem ned må nevnes tydelig i guiden. |
| 9 | Å gi lenker til andre dokumenter bør unngås og bytte fra ett dokument til et annet. Hver informasjon du trenger, bør gjøres tilgjengelig i det samme dokumentet. Hvis flere dokumenter må henvises, leverer du dem sammen med programvarepakken, og i sin tur må de henvises til hoveddokumentene. |
| 10 | Må sørge for at navnet på skriptet som er nevnt i dokumentet er det samme som det som er pakket sammen med det binære. |
| elleve | Bør sørge for at alle skriptene som er referert i installasjonsveiledningsdokumentet leveres sammen med binæren. |
| 12 | Forsikre deg om at alle konfigurasjonsparametrene er tydelig nevnt i installasjonsveiledningen / konfigurasjonsveiledningen sammen med standardverdiene og andre verdier som støttes. |
| 1. 3 | Automatiske tester for å utføre testene for byggverifisering etter at installasjonen av programvaren er fullført, skal leveres. De må være minst antall og viktige for å bekrefte at build er vellykket installert. |
| 14 | ‘Smoke Tests’ må leveres for å sikre at end-to-end-tilkoblingen til systemet er perfekt, og at alle komponentene i systemet snakker med hverandre som forventet. |
| femten | Hvis programvareinstallasjonen mislykkes, leveres tilbakeføringsskript sammen med pakken, og tilbakeføringsprosedyren er tydelig skrevet ut i installasjonsveiledningen for å utføre tilbakestilling og gjenopprette systemet. |
Med alle de ovennevnte punktene som skal tas vare på, er det en best praksis å automatisere programvareinstallasjonsprosessen med minst mulig menneskelig inngripen for å unngå menneskelige feil.
Hvis det oppdages problemer i løpet av IQ-valideringsfasen, vil det bli rapportert til programvareteamet, når det er løst, røykprøving og byggverifiseringstester vil bli utført for å sjekke om programvareinstallasjonen er vellykket.
Derfor inkluderer IQ-fasen installering av programvarepakken etterfulgt av gjennomføring av byggverifisering og røykprøver.
Så vellykket gjennomføring av IQ-fasen er veldig viktig, ettersom en vellykket og riktig installasjon av en programvare sørger for at de fleste av problemene knyttet til funksjonsfeil blir negert.
Operasjonell kvalifisering (OQ)
Operasjonell kvalifikasjon, også kalt som HVA er neste aktivitet i programvarevalideringsprosessen etter vellykket gjennomføring av IQ.
Den operasjonelle kvalifiseringsaktiviteten inkluderer t han tester for å kjøres for å verifisere at programvaren er operativt egnet til å distribueres til forbrukerne. Ideelt sett bekreftes programvarens nøkkelfunksjoner som en del av denne valideringsprosessen.
En OQ-plan for gjennomføring av OQ-validering må utarbeides av programvareteamet (testere) som skal dekke alle aspektene av OQ-testing som må utføres, inkludert detaljene som nei. av tester, testplan, metodikk, verktøy, innvirkning på tjenesten, testutførelsessekvens, metode for rapportering av problemer og SLA for å fikse dem, Defect Triage-tilnærming osv.,
Operasjonelle kvalifiseringstester som kjøres som en del av OQ, leveres igjen av programvareteamet sammen med programvareleveransen. Disse operasjonelle kvalifikasjonstestene er en samling av viktige tester som er utformet basert på dokumentet 'Functional Requirements Specification' for å sikre at hele programvaresystemet fungerer som forventet.
Dette OQ-testspesifikasjonsdokumentet er utarbeidet av testingeniørene mot spesifikasjonsdokumentet for funksjonelle krav. Ofte vil dette dokumentet være delmengden av dokumentet System Test Specification som er utarbeidet og verifisert under systemtestfasen av SDLC.
Testene kan endres eller oppdateres for å imøtekomme kravene til operativt team og forholdene på nettstedet der det skal utføres.
Derfor bør du være ekstra forsiktig når du velger testene som er en del av OQ for å sikre at alle nøkkelfunksjonalitetene og de viktigste arbeidsflytene er inkludert som en del av denne verifiseringen.
Følgende er tipsene til testere mens de forbereder OQ-testspesifikasjonsdokumentet.
| Sno | Tips for testere mens de forbereder OQ-testspesifikasjonsdokumentet |
|---|---|
| 7 | Testtilfeller relatert til grenseverdi trenger ikke å være inkludert, noe som verifiserer for ekstreme verdier, men bruker de vanligste daglige brukte verdiene som innganger, der det er nødvendig. |
| 1 | Sørg for at viktige funksjonalitetstester for å bevise at programvarefunksjoner som forventet er valgt og inkludert, og dermed er den nødvendige sporbarheten for hver av de skriftlige testtilfellene tilgjengelig i OQ Test Spec-dokumentet. |
| to | Sørg for at testene er pent skrevet med trinnvise handlinger, er selvforklarende og kan forstås av en vanlig mann. |
| 3 | Ikke henvis eller unngå bruk av tekniske termer i testtilfellene så mye som mulig, siden brukeren av dette dokumentet kanskje ikke vet om disse terminologiene. E at testdataene som brukes ikke allerede eksisterer på systemet. Gi flere datasett, i tilfelle brukeren ønsker å utføre testsakene mer enn en gang. |
| 4 | Nevn tydelig de obligatoriske og valgfrie forutsetningene for hver av testene. |
| 5 | Inkluder flertallet av positive testtilfeller for å verifisere funksjonaliteten. |
| 6 | Inkluder svært få negative testtilfeller for å sikre at programvareoppførsel er som forventet i tilfelle irrelevant input, og systemet er i stand til å håndtere de negative tilfellene. |
| 8 | Nevn konfigurasjonsverdiene som skal stilles inn, hvis behovet endres fra standardverdiene. |
| 9 | Gi de automatiserte testtilfellene som skal kjøres, der det er tilgjengelig. Forsikre deg om at automatiseringsskriptene kan kjøres på systemet der OQ planlegges. |
| 10 | Sørg for at hver testtilfelle har de klare resultatene “Forventet” og “Faktisk” som referanse. Og legg til eventuelle kommentarer om nødvendig for å forklare det faktiske resultatet. |
| elleve | Det er også nødvendig å inkludere ‘Akseptkriteriene’ for hver av testtilfellene. Akseptkriteriene kan være status for systemet etter gjennomføring av testsakene. |
| 12 | Gi testdataene som skal brukes for hver av testene, nøyaktig. Prøv å levere de vanligste dataene fra live. Og også få eksepsjonelle data for å sikre at systemet også kan håndtere unntakstilfeller. Forsikre deg om at testdataene som brukes ikke allerede eksisterer på systemet. Gi flere datasett, i tilfelle brukeren ønsker å utføre testsakene mer enn en gang. |
| 1. 3 | Hvis flere operasjonelle brukere kjører testene fra forskjellige steder parallelt, må du gi instruksjonene om å utføre testing tilsvarende med forskjellige datasett. |
| 14 | Gi sjekklister der det noen gang er nødvendig for å sikre at alle konfigurasjoner, forutsetninger er satt som forventet før du kjører testene. |
| femten | Fortsett å overvåke loggene når testene kjører, hvis tilgang er tilgjengelig til systemet. |
| 16 | Hvis det er mulig og påkrevd, gi en eksekveringsstøtte til de operasjonelle brukerne under gjennomføring av disse testsakene. |
| 17 | Forklar metoden for rapportering av problemene som ble funnet under utførelsen. Det er bedre å bruke feilsporingsverktøyet for å spore problemene. Overvåke hvert nummer nøye og ta det til slutt i henhold til avtalt SLA. |
| 18 | Kjør 'Defect Triages' som involverer rettighetshavere for å forstå de kritiske og alvorlige problemene og gi oppdateringer om disse problemene ofte. |
| 19 | Gi den endelige 'OQ Test Execution Summary Report' malen for å publisere de endelige resultatene etter at utførelsen er fullført. |
Så utarbeidet OQ-plan og testspesifikasjon bør gjennomgås grundig og undertegnes av relevante interessenter for i hovedsak å sikre at dekningen ikke er for mindre eller for mye, og at alle nøkkelfunksjonene blir dekket.
Vellykket gjennomføring av OQ demonstrerer at programvaren vil fungere i henhold til dens operasjonelle spesifikasjoner i det valgte miljøet, og det er trinnporten i å flytte programvaren mot produksjonen og er signalet om å fortsette med neste aktivitet i valideringsprosessen som er PQ .
Ytelseskvalifisering (PQ)
Etter å ha sikret vellykket IQ, er OQ fullført neste aktivitet i valideringsprosessen for å sikre om produktet / programvaren oppfyller de spesifiserte ytelsesaspektene under forventet belastning konsekvent uten å forårsake flaskehals i produksjonsmiljøet.
Hovedaspektet ved PQ er å sikre at en programvare, når den er installert på det forventede systemet, kan takle den levende belastningen og oppfylle forventet responstid og krasjer ikke under toppbelastning og stress mens du håndterer samtidige brukere.
Derfor er PQ hovedsakelig for å sikre om de spesifiserte ytelseskriteriene for en programvare oppnås over en periode (kanskje en uke) på en pålitelig basis med varierende belastningsforhold, som det er mønsteret i live. Derfor må disse testene kjøres hver dag for å overvåke programvaresystemets oppførsel, og det tar derfor litt tid å fullføre PQ til det er sikret at systemet er bevist for sin ytelse.
Ideelt sett utføres PQ-validering etter at OQ er fullført, der programvarens funksjonalitet er sikret og kan fortsette med å verifisere ytelsesaspektet til produktet eller programvaren. Noen ganger på grunn av tidsbegrensning kan PQ starte parallelt med OQ, basert på tilliten til prosentandelen av OQ-fullføring.
Det er ideelt å utføre disse ytelsestestene på live-systemet med det fullastede systemet eller på forhold som ligner på live og sikre at det ikke er noen flaskehalser på ytelsesaspektene.
Følgende tester kjøres vanligvis som en del av Performance Qualification. Og valget av testene varierer fra programvare til programvare.
# 1) Tilgjengelighetstest: For å sikre at programvaren er kontinuerlig tilgjengelig uten å krasje eller gå ned.
# 2) Tilgjengelighetstest: For å sikre at programvaren er lett tilgjengelig fra alle steder med forventet ytelseshastighet uten problemer.
# 3) Lasttest: For å måle systemets oppførsel under den forventede daglige belastningen og også toppbelastningsforholdene.
# 4) Stresstest: Å måle systemets bruddpunkt under ekstreme belastningsforhold.
# 5) Gjennomstrømningstest: Å måle responstiden til systemet og å måle TPS (transaksjoner per sekund)
# 6) Testing av skalerbarhet: Systemet kan skaleres for å håndtere forventede samtidige brukere.
Ytelsestest-scenariene og de tilsvarende automatiserte skriptene er utarbeidet basert på ytelsesrelaterte krav som er spesifisert i dokumentene 'Spesifikasjoner for brukerkrav'.
I likhet med en OQ-plan, bør en detaljert PQ-plan som tydelig angir testtilnærming, strategi, plan og tidsplan sammen med verktøy utarbeides og gjennomføres med PQ-utførere.
Prestasjonsprøve- og overvåkingsverktøyet må installeres i miljøet der PQ utføres for å måle og rapportere ytelsesberegningene.
Følgende er tipsene for testerne for å gjøre det mulig for operasjonsteamet å gjennomføre PQ med hell.
| Sno | Tips for testere for å aktivere operasjonsteamet |
|---|---|
| 7 | Veiled, støtte og trene operasjonsteamet til å utføre ytelsestesting på systemet. |
| 1 | Forbered de viktigste forretningsspesifikke scenariene for å utføre ytelsestesting basert på URS. |
| to | Sørg for at tester er inkludert for å bevise at systemet oppfyller forventningene om responstid, hastighet, skalerbarhet og stabilitet under forskjellige belastningsforhold. |
| 3 | Forsikre deg om at spesifisert belastning er tilgjengelig eller at metode og verktøy for å generere den nødvendige belastningen er tydelig nevnt i de respektive testtilfellene. |
| 4 | Nevn forutsetningen for hvert av scenariene tydelig, som forutgående belastningsforhold som skal eksistere på systemet, antall samtidige brukere osv., |
| 5 | Nevn verktøy som anbefales brukt til å utføre ytelsestesting som er spesifikk for hver testkategori og for hver test. |
| 6 | Sørg for at prosessen for å overvåke ytelsesberegningene er nevnt tydelig. |
Etter vellykket gjennomføring av PQ er det veldig viktig å oppfylle ytelseskravene, ettersom eventuelle ytelsesrelaterte avvik kan forårsake et stort forretningstap ved å skape ubehag for brukeren, og tilliten til programvaren som skal brukes, vil gå tapt og føre til at programvaren mislykkes.
I et nøtteskall, t tabellen nedenfor oppsummerer IQ-OQ-PQ-aktivitetene.
| IQ | HVA | PQ | |
|---|---|---|---|
| Hva | For å verifisere prosessen med programvareinstallasjon og hvordan prosessen er dokumentert | For å verifisere at systemet fungerer riktig | Kunder, eiere, leverandører, operasjonsteam |
| WHO | Kunder, eiere, leverandører, operasjonsteam | Kunder, eiere, leverandører, operasjonsteam | Kunder, eiere, leverandører, operasjonsteam |
| Hvor | På eiernes side, driftsteams beliggenhet, live nettsted, produkt som miljø | På eiernes side, driftsteams beliggenhet, live nettsted, produkt som miljø | På eiernes side, driftsteams beliggenhet, live nettsted, produkt som miljø |
| Når | Når programvaren mottas fra programvareteamet, før OQ og PQ. | Før du slipper systemet for bruk og etter vellykket IQ-fullføring | Før du setter systemet i live og etter vellykket IQ, fullføres OQ |
Tabellen nedenfor forklarer de forskjellige inngangene for hver valideringsfase.
| Type | Inngang |
|---|---|
| IQ | 1. Design spesifikasjonsdokument 2. Programvarebinarier og andre installasjonsskript 3. Installasjonsveiledningsdokument 4. Konfigurasjonsveiledning Dokument 5. Bygg verifiserings- og røykprøvedokument |
| HVA | 1. Funksjonelt spesifikasjonsdokument 2. OQ-plandokument 3. Dokument for operasjonell kvalifiseringstest 4. OQ Test Sammendrag Rapportmal 5. IQ fullført |
| PQ | 1. URS-dokument (User Requirement Specification) 2. PQ-plandokument 3. Testdokument for ytelseskvalifisering 4. Mal for PQ-testsammendrag 5. IQ og OQ fullført |
Konklusjon
Selv om produktet / programvaren har bestått alle verifiseringstrinnene og ikke klarer å bevise noen av IQ-OQ-PQ, kan resultatet være katastrofalt og vil medføre en enorm kostnad. Derfor er vellykket gjennomføring av IQ-OQ-PQ alene den vellykkede overføringen av produktet fra utviklingsstedet til produksjonsstedet.
Samlet sett gir vellykket gjennomføring av IQ-OQ-PQ-valideringsprosessen ikke bare tilliten til programvaren, men gir også trygghet til klienten, eieren, programvareutviklerne og testerne.
som er den beste e-postleverandøren
Å kjøre IQ-OQ-PQ reduserer også risikoen for å distribuere den til live, uten å utføre testing og reduserer kostnadene ved feil og reduserer risikoen for tilbakekalling av produktene.
Så, gutter, programvareutviklere og testere, ingen feiring etter fullført utvikling og testing internt og utgivelse av programvaren til Ops Team. Feiringen er bare når den fullfører IQ-OQ-PQ og programvaren er live på det målrettede systemet.
Derfor er suksessen til en programvare avhengig av vellykket gjennomføring av IQ-OQ-PQ, og når programvaren er live og klar til forbruk av sluttbrukerne.
Om forfatteren: Denne artikkelen er skrevet av STH-teammedlem Gayathri Subrahmanyam. Hun har mer enn to tiårs erfaring innen programvaretesting. I løpet av testkarrieren har hun gjort mange TMMI-vurderinger, testindustrialiseringsarbeider, TCOE-oppsett i tillegg til å håndtere testleveranser og implementert DevOps-praksis for et stort engasjement. Men ifølge henne stopper læringen aldri ...
Del dine erfaringer med å utføre valideringsprosessen, og gi oss beskjed hvis du har spørsmål om denne artikkelen.
Anbefalt lesing
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Programvaretesting QA Assistant Job
- Velge programvaretesting som din karriere
- Programvaretesting Teknisk innhold Writer Freelancer Jobb
- Noen interessante spørsmål om intervjuer med programvaretesting
- Programvaretestkurs Tilbakemelding og anmeldelser
- Programvaretesting Hjelp tilknyttet program!