Hvad er softwarekvalitetssikring?

  • Software Quality Assurance (SQA) er det sæt aktiviteter, der sikrer kvaliteten af ​​den software, der udvikles. Undersøgelser viste, at 98% af projekterne mislykkedes i slutningen på markedet, enten på grund af følgende årsager som estimeret tid, ændring i krav, højere omkostninger end forventet eller høje vedligeholdelsesomkostninger. Så det er meget vigtigt at huske på de forskellige parametre inden udviklingen af ​​softwaren for at minimere risikoen for fejl.
  • For at minimere risikoen for svigt af software på markedet kom softwarekvalitetssikring ind i billedet.
  • Det involverer et sæt aktiviteter, processer, procedurer og standarder, der er egnede til projektet. Det dækker alle standarder for kvalitet af software lige fra kravsamling indtil udvikling, frigivelse og vedligeholdelse af det.
  • SQA kører parallelt med udviklingslivscyklussen for software, der regelmæssigt kontrollerer, at softwaren, der udvikles, skal opfylde dens standarder på alle trin, så problemerne kan forhindres i tidlige stadier i stedet for at håndtere den efter projektets afslutning.
  • SQA inkluderer revision, træning, procesdefinition og implementering som dens vigtigste aktiviteter. Når processen er defineret, begynder SQA at finde svagheden i den og måder til at rette disse svagheder på for bedre software.

Aktiviteter for kvalitetssikring af software

Nedenfor gives nogle af aktiviteterne i Software Quality Assurance.

1. Indstilling af checkpoint

SQA-teamet indstiller checkpoints efter specifikke tidsintervaller for at kontrollere fremskridt, kvalitet, ydelse af software og om softwarekvalitetsarbejdet udføres til tiden i henhold til tidsplanen og dokumenter.

2. Mål ændringspåvirkningen

For en fejl, der er rapporteret af QA og rettet af udvikleren, er det meget vigtigt at prøve igen, om fejlen er rettet, og at kontrollere, om den faste defekt ikke indfører nye defekter i arbejdssoftwaren. Til dette opretholdes og observeres testmetrikker af ledere og udviklere for at kontrollere for nyligt genererede defekter ved indførelse af ny funktionalitet eller rettelse af enhver defekt.

3. At have flere teststrategier

Man skal ikke stole på en enkelt testmetode og -strategi til testning af software. Flere teststrategier skal implementeres i software, så de testes fra forskellige vinkler og dækker alle områder. For en e-commerce-sikkerhedstest, ydelsestest, belastningstest, databasetest, skal alt gøres for at sikre en bedre kvalitet af softwaren.

4. Vedligeholdelse af poster og rapporter

Det er vigtigt at opbevare alle poster og dokumenter i QA og dele dem til tider til interessenter. Testsager udført, testcyklusser, defekte logget, defekter rettet, testsager oprettet, ændring i krav fra en klient til en bestemt testtilfælde, alt skal dokumenteres korrekt til fremtidig reference.

5. Håndtering af gode relationer

Håndtering af gode relationer mellem testerne og udviklerne spiller en vigtig rolle i projektet. Da rollen som udvikler og tester modsiger hinanden, men dette bør ikke tages på et personligt niveau. Det vigtigste mål for begge hold skal være levering af projekter af god kvalitet med mindst mulig risiko for fiasko.

6. SQA Management Plan

Dette inkluderer at finde måder, hvordan SQA fungerer i det nye projekt på den mest effektive måde. Tænk på SQA-strategier, softwaretekniske processer, der kunne implementeres i henhold til projektkravene og teammedlemmernes individuelle færdigheder.

Komponenter i SQA-systemet

SQA-komponenter kan klassificeres i 6 klasser:

1. Komponenter inden for projektet

Dette sikrer, at projektets engagement er blevet klart defineret med hensyn til tidsestimering, afklaring af kundebehov, projektets samlede budget, evaluering af udviklingsrisici, det samlede personale, der kræves til det pågældende projekt. Det sikrer også, at udviklings- og kvalitetsplaner er klart defineret.

2. Software-projektlivscykluskomponenter

Denne komponent inkluderer gennemgang, ekspertudtalelser, softwaretestning, softwarevedligeholdelseskomponenter. I projektudviklingen livscyklus inkluderer det komponenter som anmeldelser, ekspertudtalelser og finde mangler i software design og programmering, mens det i softwarevedligeholdelsescyklussen indeholder specialiserede vedligeholdelseskomponenter og udviklingslivscykluskomponenter til forbedring af vedligeholdelsesopgaver.

3. Infrastrukturkomponenter til forebyggelse af fejl og forbedringer

Denne komponent inkluderer uddannelse, certificering, konfigurationsstyring, forebyggende og afhjælpende foranstaltninger for at reducere antallet af fejl i en software-baseret på organisationens akkumulerede SQA-oplevelse.

4. Management SQA-komponenter

Denne klasse inkluderer metrics for softwarekvalitet, omkostninger til softwarekvalitet, der inkluderer kontrol med vedligeholdelses- og udviklingsaktiviteter og introduktion af ledelsesinddragelse for at reducere risikoen for kvalitet, tidsplan og budget i projektet.

5. Komponenter i standardisering, certificering og SQA-systemvurdering

Hovedmålet med denne klasse er udnyttelse af professionel international viden, der hjælper med til koordineringen mellem de forskellige organisations kvalitetssystemer på et professionelt niveau.

6. Organisering for SQA-menneskelige komponenter

Denne base inkluderer ledere, testere og andre SQA-udøvere, der er interesseret i SQA. Hovedmålet er at støtte og igangsætte SQA-aktiviteterne, opdage huller / afvigelser i det og foreslå forbedringer til dette.

Software Quality Assurance Standarder

Flere organisationer, nationale og internationale institutter er involveret i udviklingen af ​​SQA-standarder. Nedenstående er de vigtigste organisationer og institutter, der er involveret i det:

  1. IEEE
  2. DOT
  3. ISO
  4. ANSI
  5. VVM
  6. IEC

SQA-standarder er dybest set delt i to kategorier:

1. Software Quality Assurance Standard, der er kendt som Quality Management Standards.

Eksempel: ISO 9000-3, CMM (kapacitetsmodningsmodel).

De fokuserer på organisationens infrastruktur, SQA-system, krav, der overlader valget af værktøjer og metoder til testning til en organisation. Deres standardmål er ”hvad” man skal nå. Det sikrer, at organisationer opnår en acceptabel kvalitet af software.

2. Projektstandarder til software-projekt, der er kendt som Project Process Standards.

Eksempel: ISO / IEC 12207 IEEEStd 1012-1998.

De fokuserer på metoder, der skal implementeres i softwareudvikling og vedligeholdelse. Det fokuserer på “hvordan” man skal udføre. Det inkluderer krav til designdokumentation, trin, der skal tages, softwaretest, der skal udføres, og designgennemgang og gennemgang af problemer.

SQA-teknikker

Der er flere SQA-teknikker. Nogle af dem er nævnt nedenfor:

1. Gennemgang

Ved gennemgangen afholdes et møde af både interne og eksterne interessenter for at gennemgå hele projektet, der analyserer hele softwaren, og hvis det finder et problem, skelner om det er test, udvikling, krav eller et design Hovedmålet er at måle kvaliteten af software og sikre, at om det lever op til kundens forventninger eller ej.

2. Revision

Ved revision inspiceres hele arbejdsproduktet og alle data af interessenter for at kontrollere, om det følger standardprocesserne eller ej.

3. Funktionel testning

I den funktionelle testning testes funktionaliteten af ​​hele softwaren, uanset om den fungerer som forventet eller ej. Den kontrollerer "hvad systemet fungerer" uden at vide "hvordan systemet fungerer". Det er som den sorte boks-testning af et program, hvor brugeren kender det forventede output uden at vide, hvordan det produceres.

4. Standardisering

Det sikrer, at alt i softwaren skal standardiseres, dvs. at det følger alle standarder, enten standarderne i dokumentation, udvikling, kvalitetskontrol. Det reducerer tvetydigheden og forbedrer dermed kvaliteten af ​​softwaren.

5. Inspektion af kode

Kodeinspektion er en af ​​de mest formelle former for gennemgang med det primære mål at finde mangler i koden og fremhæve eventuelle problemer i kodeinspektionen ledes af en uddannet moderator snarere end forfatter af koden. Mødet har passende adgangs- og udgangskriterier. Brugere skal have brug for komplet forberedelse inden mødet for at have fuldt kendskab til dokumenter og alt inden deres pointer.

6. Gennemgang

Gennemgang af software er en slags uformel proces, og det initieres normalt af forfatteren til at læse dokumentet eller koden, og peer-medlemmene skriver ned deres forslag eller fejl i det og indsender dem. Det er ikke formelt dokumenteret som inspektion og moderator er ikke nødvendigt på mødet. Dets hovedmål er at kende status for koden udført indtil dato og indsamle forslag fra peers for en bedre kvalitet af software.

7. Stresstest

Stresstest udføres for at kontrollere, hvordan systemet fungerer under tung belastning. Denne test spiller en vigtig rolle i softwarekvalitet, da der i e-handelsapplikationer udføres stress og belastningstest korrekt for at teste softwarens kapacitet (hvor mange maksimale antal brugere der har adgang til en applikation ad gangen).

8. Designinspektion

Designinspektion udføres for at kontrollere de forskellige softwareområder ved hjælp af checklisten som funktionel og interface design, konventioner, generelle krav og design, kravsporbarhed, logik, kobling og samhørighed.

Fordele ved SQA

Lad os diskutere fordelene ved SQA.

1. Øger kundens tillid

Korrekt kvalitetskontrol på forskellige niveauer af software som gennemgang, inspektion, revision osv. Og med involvering af både interne og eksterne interessenter øger klienternes tillid til indsendelse af ugentlige rapporter om mangelfuldt og kravsmåling hjælper også meget med at sikre klienten, at arbejdet udføres til tiden.

2. SQA sparer penge

Mangler, der findes i den tidlige fase, enten ved kravsamling, kode, test er lette og omkostningseffektive for korrekt SQA udført på flere niveauer hjælper med at reducere disse risici, da maksimale mangler er blevet afdækket og løst i tidlige stadier og dermed sparer penge til at rette op på defekt software efter at have været præsenteret for klienten, hvilket også kan koste virksomhedens omdømme, brugere og klienter.

3. Øg kundetilfredsheden

Rettidig inddragelse af klienten i softwareudvikling og -test øger kundetilfredsheden med, at kvalitetssoftwaren udvikles, og i henhold til kravene og tager forslag imellem overvejelse øger kundetilfredsheden.

4. Fremmer produktivitet og effektivitet

Når udvikling og test udføres parallelt, defekter, der findes tidligt lige efter udviklingen af ​​et enkelt modul, er udført og rettet af udviklere rettidigt, giver alle mulighed for at arbejde i fred og på en mere produktiv måde snarere end belastet med flere fejl på én gang efter færdiggørelsen af hele softwaren.

5. Forebygger uforudsete nødsituationer

Når du udvikler en virksomhedssoftware, er indsatsen også meget høj. Idet softwaren beskæftiger sig med en masse kunders følsomme data, skal den arbejde som forventet uden blackout, korruption eller kommunikationsnedbrud. Softwaren skal testes meget strengt, så den fungerer som forventet.

6. Reducerer sluttidsklientkonflikter

Der er mange tilfælde fundet med uenighed mellem klient og organisationer senere om ændringen i krav, tid og budget fastlagt i starten, hvilket resulterer i annullering af projektet, tab af penge og dårligt indtryk af virksomheden på markedet (tab af klient som det ville skabe et dårligt omdømme). I SQA er alt fast i starten af ​​projektet og dokumenteret korrekt uden nogen tvetydighed, så der ikke ville opstå konflikter

Ulemper ved SQA

Lad os diskutere ulemperne ved SQA.

1. Nogle gange svært at implementere

Da SQA definerer alle de aktiviteter og handlinger, der skal udføres på hvert trin i softwareudvikling på en meget detaljeret måde, bliver det undertiden vanskeligt at implementere hver enkelt aktivitet og proces under udvikling. Så personen ved, at det ville være fordelagtigt, men at fokusere på hvert trin i detaljer bliver vanskeligt, når man arbejder i store teams.

2. Tidskrævende

Implementering af hver handling i SQA er meget tidskrævende, og nogle gange spilder det mere tid på dokumentation og møder i stedet for at arbejde på den faktiske udvikling og test af software.

3. Høj pris

Gennem implementering af SQA kan skønt omkostningerne til at rette bugs i de senere faser reduceres ved kun at finde dem og fikse dem i starten, men for de små projekter med et lavt budget er det meget vanskeligt at implementere SQA, da antallet af ressourcer stiger i projektet gør det også med et projekt. For små projekter, der ansætter hele QA-teamet og implementerer SQA, forårsager en drastisk stigning i prisen på et projekt.

Konklusion

SQA er en paraplyaktivitet, der dækker hele projektet gennem hele softwarens livscyklus startende fra kravsamling indtil vedligeholdelse af projektet. Det dækker alle aktiviteter og processer i forskellige stadier af softwareudvikling for at sikre, at den leverede software skal være af høj kvalitet og minimal risiko, så den kan få succes på markedet og imødekomme kundens og kundens forventninger.

Anbefalede artikler

Dette er en guide til softwarekvalitetssikring. Her diskuterer vi aktiviteter, komponenter, fordele og ulemper ved SQA. Du kan også gennemgå vores andre foreslåede artikler for at lære mere -

  1. Principper for test af software
  2. Softwaretest livscyklus
  3. Agile software
  4. Kvalitetssikring vs kvalitetskontrol
  5. Black Box Testing Techniques

Kategori: