Kvalitetssikring (QA) vs. kvalitetskontrol (QC) i webprojektet.

"Internettet er færdigt ... men hvorfor er det rodet?" Problemet med verden brød webfolkene til at møde!

Har du nogensinde mødt dig selv? Projekt for at lave et websted, der er beregnet til at forme med hænderne, sidde både budgettet og mange måneder. På dagen for lanceringen stødte han på forskellige problemer, hævet i tide! Tastaturet er ikke, linket er brudt, websiden er brudt på mobiltelefonen, baghaven er så langsom. Eller det mest seriøse er kunder, der betaler, men systemet fungerer ikke! Følelsen af spænding var glad for, at Internettet blev lanceret ... blev til stress og klager fra kunderne i stedet.

Hvis du plejede at nikke i disse historier, viser du, at du ikke står over for dette problem alene. Dette er det klassiske mareridt af projektejeren og mange webudviklingshold. Det opstår ofte, når vi overser "kvaliteten" eller misforstår, at "den endelige websteds test, før du sender værket", er nok. Men sandheden er meget mere kompliceret end det, og begyndelsen på alle løsninger, der er skjult med to ord, der ligner ens. Men den forskellige betydning er "QA" og "QC".

Spørg om illustrationer: Grafiske billeder, der viser det stressende udtryk for virksomhedsejeren eller projektlederen, der holder templerne foran computeren, der viser webstedet fuld af fejl (fejl 404, billedet ikke vises, layout forvrænget) med et fuldt rødt ikon.

Hvorfor har det nye lanceringswebsted et problem? Løs oprindelsen af fejlen

Mange mennesker har en tendens til at kombinere denne inspektion af webkvalitet er "bug bug" i slutningen af projektet, men faktisk er det bare slutningen af problemet. Den sande kilde er ofte forårsaget af forvirring mellem de to hovedkoncepter: ** Kvalitetssikring (QA) ** og ** Kvalitetskontrol - QC) ** Disse to adskillelser, der får webudviklingsprocessen til at mangle proaktiv forebyggelse

Forestille sig:

• Hold, der kun fokuserer på QC (reaktiv): vil fremskynde udviklingen af forskellige funktioner. For at afslutte så hurtigt som muligt og derefter komme til at jage "fange fejlen" eller "testfinding" sammen i den sidste periode, før han leverer arbejdet, er resultatet, at der er mange problemer, der er dybt forankret og vanskelige at løse. Skal afvikle det nye kodeaffald af tid og budgettet eskalerende
• Misforstående team: Nogle hold tror måske, at det at have en test er at finde en bog er at gøre QA, hvilket ikke er korrekt. At finde en fejl er en del af QC, men ikke alle QA, der forårsager manglende planlægning for at forhindre problemer fra kilden.
• Ingen centrale standarder: Når der ikke er nogen klar QA -proces, kan hver udvikler skrive forskellige stilarter. Ingen klare referencedokumenter, der forårsager, når arbejdet kombineres, kan det let forårsage fejl som at bygge et hus af arkitekter og ingeniører, der taler med forskellige sprog

Disse rødder, der får dit websted til at ligne en tidsbombe. Venter på dagen med at skabe problemer efter lanceringen. Hvilket påvirker mere, end du tror, at det at forstå forskellene i QA og QC er det første skridt i bygningen, der bygger et stærkt websted. At have en tjekliste til gode websteder er en del af QA -planlægningen, der også hjælper med at reducere fejl.

Spørgsmål om illustrationer: Enkle infografiske billeder sammenligner to ruter en måde er en snoede sti, der hedder "med fokus på QC i slutningen", som er fuld af ikoner og røde lys. Med en anden lige og glat rute med navnet "QA gennem hele processen", der fører til trofæet skrevet "kvalitetswebsted"

Slip det websted, der mangler kvalitet ... den ulempe, der er mere alvorlig end bare "at miste ansigt"

At lade hjemmesiden fuld af fejl gå ud til brugerens øjne påvirker ikke virkningen, hvilket bare forårsager "at miste" teamet eller "spilde tid" til at løse, men det påvirker direkte virksomheden i mange dimensioner, der er meget mere skræmmende end det:

• Tab af troværdighed og ødelæggelse af billedet. Brand: Hjemmeside er ansigtet til forretningen. Hvis kunden kommer ind og finder, at kun internettet er brudt langsomt, er det vanskeligt at bruge. Tilliden til, at dit brand falder øjeblikkeligt. Og kommer måske ikke tilbage igen
• Mistede forretningsmuligheder og salg: Forestil dig, at kunderne ønsker at købe ting, vil blive brudt. Men kan ikke trykke på betalingsknappen eller udfylde formularen. Kontakt webstedet ... det er salget og de kundeemner, der forsvandt med et øjeblik. Og kan betyde tabet af denne kunde til konkurrenterne for evigt
• Spilder marketingbudgetter. Fordele: Du kan kaste en masse penge til at skyde Facebook eller Google -annoncer for at trække folk ind på nettet. Men hvis dit websted ikke rigtig fungerer, er som at hælde vand i en utæt tank, den trafik, der blev opnået, ikke betyder. Samtidig med at de øges reklameafgifter, fordi obligationssatsen stiger
• På lang sigt SEO: Google er meget vigtig for brugeroplevelsen (brugeroplevelse). Hjemmesiden, der indlæses langsomt, har en høj afvisningshastighed, eller ødelagte links reduceres kontinuerligt. Gør din søgning værre.
• Højere korrektionsomkostninger: Korrektionen af fejlen efter live -webstedet har været dyre højere end forebyggelse af fejl fra starten. Både med hensyn til tid, arbejdskraft og tab af forretningsmuligheder

Derfor er det ikke "omkostninger" at investere i processen med at skabe "kvalitet", men den vigtigste "investering" for at forhindre, at disse skader opstår. At fremstille UX -revisionsproces regelmæssigt er en måde at hjælpe med at finde og løse disse effekter.

Spørg efter illustrationer: Mejeribilleder, der viser negative effekter, startende fra "web med bug" og har en pil, der peger på "kunder er frustrerede", "mister salget", "brand tab" og "seo rang" er domino -effekt.

Løs årsagen! Adskilt mellem QA og QC og derefter brugt som

Når du forstår problemerne og påvirker det, er det tid til at se den rigtige løsning. Nøglen er at skelne og lede både ** QA (kvalitetssikring) ** og ** QC (kvalitetskontrol) ** at bruge i dit projekt korrekt.

For at se det mest åbenlyse billede Forestil dig sundhedsvæsenet:

• QA er "forebyggende sundhedsvæsen": som om du planlægger at spise nyttig mad, regelmæssig træning, sove nok alt dette til at "forhindre" til ikke at blive syg fra begyndelsen.
• QC er den "årlige sundhedscheck": som om du går til hospitalet for blodprøver, måling, X -Ray for at "tjekke" og "søge", hvilke sygdomme der er skjult i din krop.

Vil se, at vi ønsker, at begge ikke kan leve, uden at internettet er det samme.

Kvalitetssikring (QA) - Kvalitetssikring (understreger "proces" for at "beskytte")

QA er en proaktiv aktivitet, der fokuserer på ** "arbejdsproces" ** for at sikre, at det endelige resultat kommer ud af kvalitet og reducerer fejl til et minimum. Det er for at oprette en standard og indstille beskyttelsessystemet siden før du skrev den første linjekode.

Eksempel på QA -aktiviteter:

• Indstilling af kodningsstandarderne
• Valg af den rigtige teknologi og værktøjer
• Oprettelse af klare krav og spec -dokumenter
• Workflow -design, såsom at bruge WebFlow iscenesættelsesmiljø til at have et sikkert testområde.
• Uddannelse af teamet til at have den samme viden og forståelse.

Kvalitetskontrol (QC) - Kvalitetskontrol (understreger "resultater" for "inspektion")

QC er en modtagende aktivitet (reaktiv), der fokuserer på ** "resultater" ** eller det websted, der er oprettet for at kontrollere og identificere fejlen (defekter), der opstår så meget som muligt før det rigtige brugerwebsted

Eksempel på QC -aktivitet:

• Testede forskellige funktioner, uanset om det fungerer korrekt efter anmodningen eller ej (funktionel test)
• Undersøgelse af display på forskellige browser og udstyr (tværbrowser/tværforbundstest)
• Præstationstest
• Brudt linkkontrol

Så i stedet for at spørge, "QA og QC, hvilken er der bedre?" Det rigtige spørgsmål er ** "Hvordan kan vi flette både QA og QC ind i vores projekt?" ** ASQ (American Society for Quality) har klart beskrevet denne forskel, at QA er en procesplanlægning. QC kontrollerer resultaterne af denne proces.

Spørg om illustrationer: Infiguer -billede, tabel 2 -kolonne, sammenligning af QA og QC tydeligt. QA-kolonne har et billedikon "Kalender, dokument" med nøgleord "ProActiveds, Preventings", QC-kolonne "med et forstørret ikon" med nøgleord "med Reacane-produktorienteret, identificer defekter"

Eksempler fra den rigtige ting: Da teknik forvandlede webkrisen ... til en glat lancering

For at være klarere vil jeg gerne give et eksempel på virksomheden "Innovatech", der gjorde en SaaS -platform til projektstyring.

Den første dyre lektion: I åbningen af version 1.0 fokuserer Innovatech -teamet på udviklingen af funktioner så hurtigt som muligt. Med kun overfladisk QC i den sidste uge før lanceringen af resultatet er en katastrofe! Brugere støder på mange bugs. Systemet går ofte ned. Nogle kunder mangler. Holdet skal arbejde om aftenen for at følge problemet. Forårsager både omdømme og den første gruppe af kunder

Rengøring af tynd og nyoprettet i version 2.0: Fra den lektion i udviklingen af version 2.0 har de justeret alle de nye processer ved hjælp af QA- og QC -principper alvorligt.

• QA -niveau (forebyggelse):
  • Beliggende på fundamentet: De definerer de "kodende standarder", som alle skal følge, oprette "designsystem" for at gøre UI konsekvent og skrive "teknisk specifikation" af alle funktioner.
  • Opret en proces: Der er en "kodeanmeldelse" hver gang før du kombinerer koden og bruger systemet "Kontinuerlig integration (CI)" til automatisk at teste den nye kode.
• QC trin (inspektion):
  • Opret en testplan: Testteam skaber en "testtilfælde", der dækker enhver mulig situation.
  • Del testene i runder: Enhedstest af udvikler, integrationstest af QA -team og til sidst brugeraccept -test (UAT), med de faktiske prøvekunder prøver.
  • Tjekliste, før de frigives: Før de blev lanceret brugte de efter LA-tjeklisten for at kontrollere alt for sidste gang.

Forskellige resultater og afgrund: Frigivelsen af version 2.0 er meget glat. Antallet af fejl, som brugeren rapporterede af mere end 90%. Systemet er meget stabilt. Og nye kunder giver fremragende tilfredshedsresultater, dette er kraften i integrationen af QA og QC, som har ændret sig fra et projekt, der næsten ikke blev et vellykket produkt.

Spørg om illustrationer: Billedet af grafikken før og efter er en raket, der er ved at frigive, men der er en sort røg og et brudt stykke med "version 1.0 (kun QC".

Hvad vil du gøre? Tjekliste til brug af QA/QC til faktisk at bruge

Læs her, du gerne vil anvende disse principper på dit eget projekt, ikke? Du behøver ikke at bekymre dig om ikke at være i stand til at prøve at bruge denne enkle tjekliste som en retningslinje, der er opdelt i 2 hoveddele: ** QA -aktivitet (gør alle projekter) ** og ** QC -aktivitet (fremstillet omkring) **

Del 1: QA -aktivitet (kvalitetssikring - forebyggelse)

Disse skal være en del af arbejdskulturen i hvert projekt:

• [] Klare mål og krav: Alle i teamet skal forstå, at "den færdige hjemmeside" ligner, hvilke funktioner der er?
• [] Opret arbejdsstandarder (standardisering):
  • - Der er kodningsstandard- og stilguide til udvikler.
  • - Der er et designsystem, som designer kan kontrollere designtonen.
• [] Dokumentation: Tekniske beslutningsnotater, API -metoder eller anden vigtig information, som teamet skal bruge sammen
• [ ] Planlægning af testområdet: Bestem arbejdsgang fungerer gennem et klart iscenesættelsesmiljø, så det kan testes og anmeldelser uden at påvirke det faktiske websted .
• [] Giv en gennemgang af værket (tværfunktionel gennemgang): For eksempel udvikler, gennemgang af hinanden, designer. Anmeldelser på udvikleren arbejder på webrammen og osv.

Del 2: QC -aktivitet (kvalitetskontrol - sikker på tjek)

Disse vil ske på de vigtige punkter i projektet, især inden levering:

• [] Opret en testplan og testtilfælde: Hvad er planen for at teste? Og hvordan er testprocedurerne? Gode informationskilder som Guru99 har eksempler på at studere mere.
• [] Funktionel test: Kontroller, om alle funktioner fungerer korrekt som designet eller ej (f.eks. Anvendelse, bestilling, formning)
• [] Brugervenlighed & UX -test: Test, om webstedet er let at bruge eller ej? Er brugeren forvirret? UX -revision kan hjælpe meget i denne del.
• [] Kompatibilitetstest: Kontroller displayet og arbejd på
  • - Populær browser (Chrome, Firefox, Safari, Edge)
  • - udstyr (desktop, tablet, mobil)
• [] Performance Testing: Test websideindlæsningshastigheden og måling med værktøjer som Google PageSpeed Insights.
• [] Gør brugeraccept test (UAT): Lad de rigtige kunder eller brugere prøve at prøve at give feedback inden lanceringen.

At have en omfattende tjekliste vil hjælpe dig med at være sikker på, at intet falder. Og klar til at levere webside af høj kvalitet , der skaber gode resultater for din virksomhed

Spørgsmål om illustrationer: De smukke tjeklistebilleder er opdelt i 2 dele, som er "QA -proces" og "QC -kontrolpunkter" med højre tick -side.

Spørgsmål, som folk har tendens til at tvivle (FAQ), rydder alle problemer på QA vs. QC.

Så du kan forstå dette dybere, jeg har udarbejdet et almindeligt spørgsmål om QA og QC for at svare klart.

Q1: I holdet er det nødvendigt at have en "QA" og "QC" -position separat?
A: I et stort team eller et komplekst projekt, der har en separat position (såsom QA Manager og QC/Tester), betragtes som bedste praksis, men for små hold eller startups, der ikke er behov for at have en separat position. Men det vigtige er ** alle i holdet skal forstå og ansvar for deres roller. ** F.eks. Kan projektleder tage sig af QA, udvikler. Enhedstest (en del af QC) og ejeren af projektet eller marketingteamet for at lave UAT (brugeraccept -test).

Q2: Hvis vores forretning er meget lille, er der ikke noget ekstra budget for teamet. Hvad skal jeg fokusere på først?
A: Hvis du skal vælge ** Start med at oprette en god QA -kultur først **, fordi forebyggelsen har en lavere omkostning end altid. Forsøger at skabe en klar arbejdsproces, have gode dokumenter og kommunikere ofte i teamet. QC kan gøre på et grundlæggende niveau, såsom udviklere, der hjælper med at teste venners arbejde. Eller lad folk, der ikke er teknikker i virksomheden, til at hjælpe med at spille internettet i det rigtige brugers hjørne

Q3: Hvad er forskellen mellem QA og QC?
A: Det er et meget godt spørgsmål! At se på 3 lag overlappende billeder:

• Softwaretest: er "aktiviteten" -testen for at finde fejl. Er den mindste del
• QC (kvalitetskontrol): er "processen", der bruger softwaretest og andre aktiviteter. For at kontrollere kvaliteten af "resultater" (websted)
• QA (kvalitetssikring): Er den "ramme", der dækker både udviklingsprocessen og QC -processen for at sikre, at alt opfylder standarderne og "forhindrer" i at forårsage problemer fra begyndelsen.

Kort sagt er test en del af QC, og QC er en del af QA.

Spørgsmål 4: Vi skulle begynde at gøre QA og QC siden når projektet?
A: ** QA starter fra den første dag (dag 1) ** af projektet. Fra indsamling af krav og planlægning. ** QC starter med jævne mellemrum. ** Når der er værker eller resultater, for eksempel når funktionen A er færdig, åbnes QC's QC, når sprinten er færdig, sprint og den store QC åbnes inden det faktiske websted.

Spørg om illustrationer: Folk taler. Med spørgsmålsmarkører og korrekte karakterer for at formidle spørgsmålene, der rydder spørgsmålene

Afslutningsvis er let at forstå: QA og QC er ikke fjender, men partneren til kvalitetswebstedet.

På dette tidspunkt mener jeg, at du tydeligt skal se, at ** QA (kvalitetssikring) ** og ** QC (kvalitetskontrol) ** ikke den samme ting. Og kan slet ikke erstattes

At huske let som dette:

• QA ser frem (fremadrettet): Hvordan kan vi "forhindre" problemer? Er vores proces god nok?
• QC ser tilbage (bagudvendt): Resultatet "Hvor er problemerne"? Hvad har vi at ordne?

Oprettelse af websteder af høj og høj kvalitet kan ikke længere stole på den endelige bage af projektet, men kræver en systematisk forsvarsplan (QA) parallelt med intens inspektion (QC) undervejs, som "Ghost Ventian" og "Sorcerer" i det samme team

Jeg vil gerne invitere dig til at prøve at udforske webprocessen i dit team. At vi i dag har en "partner", dette par er komplet, og arbejder de godt nok? Investering er effektiv til at skabe kvalitetsprocesser fra i dag. Er at lægge det stærkeste fundament for den lange succes med din virksomhed online

Det er tid til at ændre hjemmesiden, der "lige er færdig" for at være et "kvalitet" -websted! Hvis du har brug for en partner eller ekspert til at hjælpe med at oprette og oprette et system af høj kvalitet, der driver din virksomhed, er vores team klar til at give råd!

Spørgsmål om illustrationer: Smuk grafik, QA -ikon (defensiv skjold) og QC (forstørrelsesglas) holder hænderne. Med en stigende grafbaggrund med meddelelsen "bedre kvalitet, bedre resultater"

‍