cosmetic functional bugs what has be treated
Der er altid et stort ansvar pålagt testeren for at afdække enhver form for fejl, som software har. Uanset funktionalitet og brugergrænseflade kan testere rejse fejl, uanset hvor der er manglende overensstemmelse.
Denne artikel hjælper med at forstå vigtigheden af de funktionelle og de kosmetiske fejl. Derudover forklares de faktorer, der skal tages i betragtning ved prioritering af dem, også her på en forståelig måde med nogle live eksempler til illustrationer .
ip adresse tracker software gratis download
Hvad du lærer:
Betydningen af funktionelle og kosmetiske bugs
Fejl er uundgåelig i softwareudvikling. Derfor er det altid meget vigtigt at udføre softwaren grundig test, før den kan bruges live. Software test kan blive mere essentielle, da de hjælper med at identificere bugs gået glip af udviklerne .
Disse uidentificerede fejl kan blive meget dyre i live. Derfor skal der udføres en ordentlig testplan og testningen for at forbedre softwarekvaliteten.
Fig 1:
Ovenstående figur skal uploade en billedfil, som softwaren ikke har vist. Dette er et alvorligt problem, der alvorligt kan forårsage forretningspåvirkninger.
Kosmetiske bugs og deres betydningsfulde betydning
Kosmetiske krav er intet andet end brugergrænsefladen eller bare frontendens udseende af softwaren. For det meste sker det, at det hele tiden skifter mellem forskellige udgivelser.
Dette sker især i de projekter, hvor den agile metode følges. Udgivelserne forekommer her i form af sprints. Derfor kaldes de normalt Sprint release eller bare SR-xx, hvor 'xx' henviser til frigivelsesnummeret.
Hver udgivelse kan have et bestemt sæt krav. Generelt forbereder klienterne sig ofte til at anmode om ændringer i brugergrænsefladen eller bare brugergrænsefladen.
Følgende er et par eksempler på kosmetiske krav:
- Menuer skal være tilgængelige med Calibri skrifttype og.
- Tekstboks A skal være 1,2 tommer
- Alle genererede rapporter skal have titlen med H1-størrelse med '002522' farve.
Ovenstående er et par eksempler på kosmetiske krav, der kan komme op. Dette er de krav, der primært er rettet mod improvisation af softwarets anvendelighed . En anden grund bag de kosmetiske krav er at optimere softwaren og dens design til forretningsformålet.
Fig. 2
I ovenstående figur er der både funktionelle såvel som kosmetiske problemer. Et funktionelt problem som afkrydsningsfelt vises ikke for en indstilling 'Brug DeathByCaptcha'.
Det kosmetiske problem kan ses her som ingen ensartet skrifttype, der er blevet brugt.
Prioriteret faktor for kosmetiske fejl eller behov fra klienter
De kosmetiske behov markeres lidt væsentligt af kunderne. Dette er på grund af bekymringen over behovet for at gøre interaktionen med softwaren meget enkel og samtidig effektiv, så gennemførelsen af mål let sker. Hvis der er problemer med brugergrænsefladen, når klienter udbyderne med en lavprioritetsfejl.
Som det generelt sker, er de funktionelle aspekter af softwaren bekymrede af udviklerne end de kosmetiske aspekter, da de for det meste er områder med lav påvirkning.
Softwaretesterne vil have, at alle de krav, der er nævnt af klienterne, skal være tilgængelige i softwaren, der fejler, hvilket de naturligvis rejser en fejl. Og det er her, hvor alle starter. Den prioritet, som testeren har indstillet, opstår som et resultat af klientens forslag. Udviklernes syn er lidt anderledes end det, testere ser på. De ser altid, om fejlen kan medføre et brud på funktionaliteten.
Her kommer nogle tilbagevendende diskussioner, og resultatet af det kan få anbefalingerne fra testteamet til at ske på et eller andet tidspunkt. Hvis ikke i den aktuelle udgivelse, kan det ske i den efterfølgende.
Rigtigt eksempel # 1)
Klienten har anmodet om, at firmaets logo skal vises på hjemmesiden i titlerammen sammen med en hurtig indlæsningsfunktion. Sælgeren har leveret softwaren, hvor firmalogoet tager tid at indlæse, og kunderne med en fornemmelse af, at logoet ikke indlæses, fortsætter med at rejse et kundes live-problem.
Derfor har dette gjort mere skade på leverandørerne. Grundårsagen til problemet kan være størrelsen på billedet eller billedets art eller noget andet. Selvom dette ikke har funktionelle pauser, er dette sat op som et live-emne.
Funktionelle bugs - Kritiske faktorer og prioritetsfaktorer
Generelt betragtes bugs som prioriterede baseret på den prioritet, der er indstillet af klienterne, og de potentielle påvirkninger, de kan efterlade i virksomheden. Det er den generelle tro på tværs af udviklerne, at de høje kritiske fejl skal arbejdes med. Dette er mere indlysende, da de funktionelle bugs er noget, der undertrykker deres arbejde.
Og baseret på prioriteten ønsker klienterne at prioritere et par af de funktionelle og kosmetiske bugs i samme udgivelse. Kritiskhedsfaktoren afhænger af påvirkningen eller den potentielle indvirkning, som fejlen kan efterlade. Prioritetsfaktoren er udelukkende baseret på klienten og deres behov.
Med hensyn til kritiskhed er funktionelle bugs meget nødvendigt for at blive rettet uden forsinkelser. For de kosmetiske bugs kan de følge beslutningerne truffet af klienterne
Fig. 3
I ovenstående figur er der funktionelle problemer som designproblemer og tekstoverlappende og kosmetiske problemer som fontproblemet.
Rigtigt eksempel # 2)
Klienten i eksempel 1 havde flere udgivelser fra den samme leverandør. Kunderne er tilfredse med leverancer leveret af leverandørerne. Nu er der pludselig få forretningsscenarier, som kunderne identificerede for ikke at arbejde sammen med få andre lister over skærmproblemer. Da de funktionelt påvirker problemer, anses for at være kritiske for klienterne, bad de sælgerne om at rette dem ASAP.
Og da skærmproblemerne havde tegn på at efterlade den mindre grad af påvirkninger, prioriterede klienterne dem i flere udgivelser. Klienter var klar til at komme i gang med rettelser til nogle få af skærmproblemerne og de fleste af de funktionelle problemer. Dette skyldes, at alle funktionerne kan påvirke forretningen, og de få skærmproblemer har potentiale til at skabe påvirkninger.
Virkninger på virksomheden
Alle fejl kan medføre, at softwaren ikke overholder kravene til klienten. Når det kommer til virkningerne i erhvervslivet, er det bestemt de funktionelle fejl, der fortjener at forårsage alvorlige påvirkninger for virksomheden. Da kosmetiske fejl svarer til problemet med UI-design og udseende, kan de skabe problemer med brugervenligheden og udseendet blandt brugerne.
Med andre ord kaldes disse bedre som kosmetiske forbedringer end bugs. Selvom disse ikke kan påvirke virksomheden alvorligt på en større måde, kan de medføre nogle vanskeligheder blandt brugerne, mens de bruger softwaren.
Rigtigt eksempel # 3)
Leverandører har leveret en ny version af softwareapplikationen i en mobil version. Der er få funktioner i mobilapps, der krævede, at brugeren klikker på et eller andet link oftere. Dette skabte en følelse af forringet brugervenlighed blandt brugerne. Sælgerne skal revurdere designet og strømmen i applikationen. Efter at have ændret flowet begyndte applikationen at få flere brugere til at bruge dem.
Brugervenlighed spiller hovedrollen i masser af sådanne applikationer. Selvom der ikke var nogen funktionelle ændringer, var der få ændringer i kosmetik, der fik applikationerne til at vokse sig stærkere
Sammenlignende undersøgelse mellem kosmetiske bugs og de funktionelle bugs
Der kan være en række variationer mellem klassificeringerne af fejl som funktionelle og kosmetiske i flere aspekter i softwaretestens livscyklus. Få blandt dem er formuleret og formuleret som en forskel mellem begge typer:
| Sammenligningsområde | Funktionelle bugs | Kosmetiske bugs |
|---|---|---|
| Potentielle årsager | Der kan være flere årsager: 1. Kodningsproblemer 2. Synkroniseringsproblemer 3. Afhængige applikationsproblemer | Følgende kan forårsage problemet: 1. Designproblemer 2. Ikke-understøttet filproblem |
| Grad af rekreation | Rekreation af de funktionelle fejl kan udføres enten af testerne eller af klienterne selv | Kosmetiske bugs kræver minimal indsats i rekreation, da de for det meste identificeres på UI-niveau |
| Kritik | De er for det meste kritiske, da den funktionelle nedbrydning kan påvirke virksomheden i en alvorlig form | De kan blive kritiske ved meget få lejligheder. |
| Prioritet | Prioriteten er som defineret af klienterne | Prioriteten er som defineret af klienterne |
| Potentiel påvirkning | Funktionel nedbrydning kan forårsage alvorlige problemer i kundernes forretning | Selvom de ikke kan skabe direkte påvirkning, kan de også påtage sig at få potentielle påvirkninger. |
| Overvejelser om forbedringer | Disse fejl kan aldrig anbefales eller betragtes som forbedring | Disse bugs kan betragtes som forbedring |
| Omkostninger, når de ikke er faste | Høje omkostninger, når problemet findes på live software | Ikke meget omkostninger |
Kosmetiske bugillustrationer
Den kosmetiske fejl kan påvirke nogle steder, hvor der er firmalogoer eller partnerskabernes billeder på softwaren, men den indlæses ikke korrekt. Selvom de ikke er funktionelle bugs, kan de blive alvorlige. Lad os forstå følgende illustrationer for at forstå vigtigheden af kosmetiske bugs og deres vigtige rolle.
Casestudie
Software A udvikles af sælgeren B. Leveringsmåden til klienten er i form af kodefald en gang hver måned, efter at der er frigivet en basisversion. Fra det leverede produkt vil klienter liste alle problemer, bugs, forbedringer baseret på deres kritiske og prioritet.
mysql interview spørgsmål og svar til 3 års erfaring
Prioritet går som P1, P2, P3 og P4.
Kritik går som Alvorlig, større, høj og lav.
Nu forventer klienterne, at alle de alvorlige, store, P1-bugs bliver rettet i uge 30. Ligeledes forventes de høje, P2-bugs i uge 35. Lave, P3-bugs-rettelser forventes i uge 40. Endelig forventes P4-bugs i ugen 40. Mellem al frigivelse af rettelserne blokerer klienten 3 dages bufferperiode.
Nu bliver følgende observation meget kritisk:
- Da det er blevet planlagt som en pipelined-tilstand, vil enhver forsinkelse påvirke de efterfølgende planer på en større måde.
- Prioriteter er dannet af klienterne, og derfor planlægger de at frigive i den periode, de ønsker
- Forsinkelsen i fejl med lav prioritet har potentialet til at opgradere deres prioritet fra lav prioritet til højere.
- Mindre forsinkelser kan medføre alvorlige konsekvenser for virksomheden, så de lave og mindre fejl bliver større.
Testere og udviklere mødes
'Tæl ikke æggene, før de bliver klækket' - Denne linje gælder for både udviklere og testere. Når software er udviklet og klar til at blive testet, har testere tendens til at tænke på ovenstående linjer. Efter test er det nu udviklerens tur til at stave linjerne til testerne. Følgende er tankerne, der flyder ind imellem dem:
- Testere siger udviklerne, at der er så mange fejl, vi kan fange i din software. Derfor er dit arbejde ikke forbi.
- Efter testfasen er afsluttet, og efter masser af bugs, siger udviklere ikke, at du har rejst flere bugs, vi finder den passende grund til at afvise de fleste af de bugs, du har rejst, der ikke er ægte.
Derfor er det altid en slags argumenterende tilgang, der går mellem testere og udviklere. For at sikre, at hele projektleverancerne er synkroniserede, er det vigtigt, at en mellemliggende person (projektleder), der kan løse kontroverserne, så leverancerne optimeres og er absolutte uden fejllækage.
Konklusion
Ovenstående artikler skal have forklaret alle de uundgåelige og vigtige aspekter af de kosmetiske bugs og hvordan det kan sammenlignes med de funktionelle bugs . Ovenstående artikel forklarer også, hvordan de kosmetiske bugs kan behandles sammenlignet med de funktionelle bugs.
Skønt kritikken af de funktionelle bugs er højere end for kosmetiske bugs, forbeholder sidstnævnte deres egen plads til at få prioriteter fra klienterne. For at afbalancere softwaren med opløsninger til alle fejlene, det tilrådes generelt at behandle fejlene, der forstår kritikken, prioriteten og klientens anbefaling.
Om forfatteren: Dette er en artikel skrevet af Nagarajan. Han arbejder som en testleder med over 6 års testerfaring inden for forskellige funktionelle områder som Banking, Airlines, Telecom med hensyn til både manuel og automatisering.
Hvad tager du med kosmetiske og funktionelle bugs? Jeg vil gerne se dine tanker nedenfor.
Anbefalet læsning
- Kognitiv bias i softwaretest: Hvorfor savner testere fejl?
- Hvorfor har software fejl?
- Hvordan får du alle dine fejl løst uden nogen 'Ugyldig fejl' -mærke?
- Funktionstestning mod ydelsestestning: Bør det gøres samtidigt?
- 10 grunde til, at dine bugs bliver afvist, og hvad du kan gøre for det som en tester!
- Hvad er Longevity Testing? Sådan fanges fejlene, før kunden finder det
- Kunsten med fejlrapportering: Hvordan markedsføres og repareres dine fejl?
- Top 30 funktionelle testværktøjer i 2021