Hva er programvarekvalitetssikring?
- Software Quality Assurance (SQA) er et sett med aktiviteter for å sikre kvaliteten på programvaren som utvikles. Studier viste at 98% av prosjektene mislyktes til slutt i markedet, enten på grunn av følgende årsaker som estimert tid, endring i krav, høyere kostnader enn forventet eller høye vedlikeholdskostnader. Så det er veldig viktig å huske på de forskjellige parametrene før utviklingen av programvaren for å minimere risikoen for feil.
- For å minimere risikoen for svikt i programvare i markedet kom kvalitetssikring av programvare inn i bildet.
- Det innebærer et sett med aktiviteter, prosesser, prosedyrer og standarder som er egnet for prosjektet. Den dekker alle standarder for kvalitet på programvare helt fra kravsamlingen til utvikling, utgivelse og vedlikehold av den.
- SQA kjører parallelt med utviklingslivssyklusen til programvare som regelmessig sjekker at programvaren som utvikles skal oppfylle standardene i alle trinn, slik at problemene kan forhindres i tidlige stadier i stedet for å håndtere den etter fullført prosjekt.
- SQA inkluderer revisjon, opplæring, prosessdefinisjon og implementering som hovedaktiviteter. Når prosessen er definert, begynner SQA å finne svakheten i den og måter å korrigere disse svakhetene for bedre programvare.
Aktiviteter for kvalitetssikring av programvare
Nedenfor er gitt noen av aktivitetene til Software Quality Assurance.
1. Innstilling av sjekkpunkt
SQA-teamet setter sjekkpunktene etter spesifikke tidsintervaller for å sjekke fremdriften, kvaliteten, ytelsen til programvaren og om programvarekvalitetsarbeidet blir utført i tide i henhold til planen og dokumentene.
2. Mål Endringpåvirkning
For en feil rapportert av QA og løst av utvikleren, er det veldig viktig å prøve på nytt feilen og å verifisere om den faste feilen ikke innfører nye feil i arbeidsprogramvaren. For dette blir testmålinger opprettholdt og observert av ledere og utviklere for å sjekke for nylig genererte feil ved innføring av ny funksjonalitet eller fikse eventuelle feil.
3. Å ha flere teststrategier
Man skal ikke stole på en enkelt testtilnærming og strategi for testing av programvare. Flere teststrategier bør implementeres i programvare for å teste den fra forskjellige vinkler og dekke alle områdene. For en sikkerhetstesting for e-handel på nettsteder, ytelsestesting, belastningstesting, databasetesting, bør alt gjøres for å sikre en bedre kvalitet på programvaren.
4. Opprettholde poster og rapporter
Det er viktig å føre alle journalene og dokumentene til QA og dele dem av og til til interessenter. Testfall utført, testsykluser, feil loggført, feil defekt, test case opprettet, endring i krav fra en klient for en spesifikk test case, alt skal være korrekt dokumentert for fremtidig referanse.
5. Å håndtere gode forhold
Å håndtere gode relasjoner mellom testerne og utviklerne spiller en viktig rolle i prosjektet. Som rollen som utvikler og tester motsier hverandre, men dette bør ikke tas på et personlig nivå. Hovedmålet for begge lagene bør være levering av god kvalitet på prosjekter med minimum risiko for å mislykkes.
6. SQA Management Plan
Dette inkluderer å finne måter hvordan SQA vil fungere i det nye prosjektet på den mest effektive måten. Tenk på SQA-strategier, software engineering prosesser som kan implementeres i henhold til prosjektkravene og de individuelle ferdighetene til teammedlemmer.
Komponenter av SQA System
SQA-komponenter kan klassifiseres i 6 klasser:
1. Forprosjektkomponenter
Dette sikrer at forpliktelsen til prosjektet er definert tydelig angående tidsestimering, avklaring av kundebehov, prosjektets totale budsjett, evaluering av utviklingsrisikoer, totalt personell som kreves for det aktuelle prosjektet. Det sikrer også at utviklings- og kvalitetsplaner er klart definert.
2. Programvarens prosjektlivssykluskomponenter
Denne komponenten inkluderer gjennomgang, ekspertuttalelser, programvaretesting, programvarevedlikeholdskomponenter. I prosjektutviklingens livssyklus inkluderer det komponenter som anmeldelser, ekspertuttalelser og å finne mangler i programvaredesign og programmering, mens det i programvarevedlikeholdssyklusen spesialiserer vedlikeholdskomponenter og utvikling av livssykluskomponenter for å forbedre vedlikeholdsoppgaver.
3. Infrastrukturkomponenter for forebygging av feil og forbedringer
Denne komponenten inkluderer opplæring, sertifisering, konfigurasjonsstyring av ansatte, forebyggende og korrigerende tiltak for å redusere frekvensen av feil i en programvarebasert på organisasjonens akkumulerte SQA-erfaring.
4. Ledelse av SQA-komponenter
Denne klassen inkluderer programvarekvalitetsberegninger, programvarekvalitetskostnader, som inkluderer kontroll av vedlikeholds- og utviklingsaktiviteter og innføring av ledelsesmessig engasjement for å redusere risikoen for kvalitet, tidsplan og budsjett i prosjektet.
5. Komponenter av standardisering, sertifisering og SQA-systemvurdering
Hovedmålet med denne klassen er bruk av profesjonell internasjonal kunnskap som hjelper i koordineringen mellom de forskjellige organisasjonens kvalitetssystemer på et profesjonelt nivå.
6. Organisering for SQA menneskelige komponenter
Denne basen inkluderer ledere, testere og andre SQA-utøvere som er interessert i SQA. Hovedmålet er å støtte og sette i gang SQA-aktivitetene, oppdage hullene / avvikene i den og foreslå forbedringer for det.
Standarder for kvalitetssikring av programvare
Flere organisasjoner, nasjonale og internasjonale institutter er involvert i utviklingen av SQA-standarder. Nedenfor nevnte er de viktigste organisasjonene og instituttene som er involvert i det:
- IEEE
- PUNKTUM
- ISO
- ANSI
- EIA
- IEC
SQA-standarder er i utgangspunktet delt inn i to kategorier:
1. Kvalitetssikringsstandard for programvare som er kjent som Quality Management Standards.
Eksempel: ISO 9000-3, CMM (Capability Maturity Model).
De fokuserer på organisasjonens infrastruktur, SQA-system, krav som overlater valget av verktøy og metoder for testing til en organisasjon. Deres standardmål er "hva" du skal oppnå. Det sikrer at organisasjoner oppnår en akseptabel kvalitet på programvaren.
2. Prosjektstandarder for programvareutvikling som kalles prosjektprosessstandarder.
Eksempel: ISO / IEC 12207 IEEEStd 1012-1998.
De fokuserer på metodologier som må implementeres i programvareutvikling og vedlikehold. Det fokuserer på "hvordan" du skal prestere. Det inkluderer krav til designdokumentasjon, trinn som skal tas, programvaretesting som skal utføres og designgjennomgang og gjennomgangsproblemer.
SQA-teknikker
Det er flere SQA-teknikker. Noen av dem er nevnt nedenfor:
1. Gjennomgang
Ved gjennomgang holdes et møte av både interne og eksterne interessenter for å gjennomgå hele prosjektet som analyserer hele programvaren, og hvis det er et problem, skiller om det er testing, utvikling, krav eller design Hovedmålet er å måle kvaliteten på programvare og sikre at om det tilfredsstiller kundens forventninger eller ikke.
2. Revisjon
Ved revisjon blir hele arbeidsproduktet og alle dataene inspisert av interessenter for å sjekke om det følger standardprosessene eller ikke.
3. Funksjonell testing
I den funksjonelle testingen testes funksjonaliteten til hele programvaren om den fungerer som forventet eller ikke. Den sjekker "hva systemet fungerer" uten å vite "hvordan systemet fungerer". Det er som den svarte boksen som tester et program der brukeren kjenner forventet output uten å vite hvordan det produseres.
4. Standardisering
Den forsikrer at alt i programvaren skal standardiseres, dvs. at det følger alle standardene, enten standardene i dokumentasjon, utvikling, kvalitetskontroll. Det reduserer tvetydigheten og forbedrer dermed programvarens kvalitet.
5. Inspeksjon av kode
Kodeinspeksjon er en av de mest formelle gjennomgangene med hovedmålet å finne mangler i koden og fremheve eventuelle problemer i kodekontrollen ledes av en trent moderator i stedet for koden som er forfatter. Møte har riktige inn- og utreisekriterier. Brukere må trenge fullstendig forberedelse før møtet for å ha full kjennskap til dokumenter og alt før de hever poengene sine.
6. Gjennomgang
Gjennomgang av programvare er en slags uformell prosess, og vanligvis initieres det av forfatteren for å lese dokumentet eller koden, og fagfeller-medlemmene skriver ned sine forslag eller feil i det og sender dem inn. Det er ikke formelt dokumentert som inspeksjon og moderator er ikke nødvendig i møtet. Hovedmålet er å kjenne statusen til koden fullført til dato og samle inn forslag fra jevnaldrende for en bedre kvalitet på programvaren.
7. Stresstesting
Stresstesting gjøres for å sjekke hvordan systemet fungerer under tung belastning. Denne testingen spiller en viktig rolle i programvarekvalitet som i e-handelsapplikasjoner, stress og belastningstesting blir utført på riktig måte for å teste kapasiteten til programvaren (hvor mange maksimale antall brukere som kan få tilgang til en applikasjon om gangen).
8. Designinspeksjon
Designinspeksjon gjøres for å sjekke de forskjellige programvarens områder ved hjelp av sjekklisten som funksjonell og grensesnittdesign, konvensjoner, generelle krav og design, kravsporbarhet, logikk, kobling og samhold.
Fordeler med SQA
La oss diskutere fordelene med SQA.
1. Øker kundens tillit
Riktig kvalitetskontroll på forskjellige nivåer av programvare som gjennomgang, inspeksjon, revisjon, osv., Og med involvering av både interne og eksterne interessenter, øker kundenes tillit til innsending av ukentlige rapporter om feil og kravmålinger, hjelper også mye med å sikre klienten at arbeidet blir utført i tide.
2. SQA sparer penger
Mangler som finnes i tidlig fase, enten ved innsamling, kode, testing, er enkle og kostnadseffektive for korrekt SQA gjort på flere nivåer, og hjelper til med å redusere risikoen da maksimale feil er avdekket og løst i tidlige stadier og dermed sparer penger for å fikse feil programvare etter å ha blitt presentert for klienten som kan koste selskapets omdømme, brukere og klienter også.
3. Øk kundetilfredsheten
Rettidig involvering av klienten i programvareutvikling og testing øker kundetilfredsheten med at kvalitetsprogramvaren utvikles og i henhold til kravene og å ta forslag imellom, øker kundetilfredsheten.
4. Fremmer produktivitet og effektivitet
Når utvikling og testing blir utført parallelt, gjør defekter som ble funnet tidlig rett etter at utviklingen av en enkelt modul er utført og fikset av utviklere, rettidig, slik at alle kan jobbe i fred og på en mer produktiv måte i stedet for å bli belastet med flere avlyttinger samtidig etter fullføringen. av hele programvaren.
5. Forhindrer uforutsette nødsituasjoner
Når du utvikler en bedriftsprogramvare, er innsatsen også veldig høy. Ettersom programvaren tar for seg mye av kundens sensitive data, må den fungere som forventet uten noen blackout, korrupsjon eller kommunikasjonsbrudd. Programvaren skal testes veldig strengt, slik at den skal fungere som forventet.
6. Reduserer sluttidsklientkonflikter
Det er mange tilfeller av uenighet fra klient og organisasjoner senere om endring i krav, tid og budsjett fast i starten som resulterer i kansellering av prosjektet, tap av penger og dårlig inntrykk av selskapet i markedet (tap av klient som det ville skape et dårlig rykte). I SQA er alt løst i starten av prosjektet og dokumentert riktig uten noen tvetydighet, slik at ingen konflikter skulle oppstå
Ulemper ved SQA
La oss diskutere ulempene ved SQA.
1. Noen ganger vanskelig å implementere
Ettersom SQA definerer alle aktiviteter og handlinger som bør utføres på hvert trinn i programvareutvikling på en veldig detaljert måte, blir det noen ganger vanskelig å implementere hver enkelt aktivitet og prosess under utvikling. Så personen vet at det ville være fordelaktig, men å fokusere på hvert trinn i detalj blir vanskelig når han jobber i store team.
2. Tid forbruker
Det er veldig tidkrevende å implementere hver handling i SQA, og noen ganger kaster det bort mer tid på dokumentasjon og møter i stedet for å jobbe med faktisk utvikling og testing av programvare.
3. Høye kostnader
Gjennom å implementere SQA, selv om kostnadene for å fikse feilene i de senere stadier kan reduseres ved å finne dem og fikse i starten bare, men for de små prosjektene med lavt budsjett er det veldig vanskelig å implementere SQA ettersom antall ressurser øker i prosjektet gjør også budsjettet til et prosjekt. For små prosjekter som ansetter hele QA-teamet og implementerer SQA, forårsaker det en drastisk økning i kostnadene for et prosjekt.
Konklusjon
SQA er en paraplyaktivitet som dekker hele prosjektet gjennom hele programvarens livssyklus, fra kravinnsamling til vedlikehold av prosjektet. Den dekker alle aktiviteter og prosesser i forskjellige stadier av programvareutvikling for å sikre at programvaren som leveres skal ha høy kvalitet og minimumsrisiko slik at den kan lykkes i markedet og oppfylle kundens og kundens forventninger.
Anbefalte artikler
Dette er en guide til kvalitetssikring av programvare. Her diskuterer vi aktiviteter, komponenter, fordeler og ulemper ved SQA. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -
- Testing av programvareprinsipper
- Testing av livssyklus for programvare
- Agile programvare
- Kvalitetssikring vs kvalitetskontroll
- Black Box Testing Techniques