cosmetic functional bugs what has be treated
Det er alltid et stort ansvar som pålegges testeren for å avdekke enhver form for feil som programvaren har. Uavhengig av funksjonalitet og brukergrensesnitt, kan testere heve feil hvor det ikke er samsvar.
Denne artikkelen hjelper til med å forstå viktigheten av de funksjonelle og de kosmetiske feilene. I tillegg forklares faktorene som skal vurderes ved prioritering av dem her på en forståelig måte med noen live eksempler for illustrasjoner .
beste mobile spionapp for iPhone
Hva du vil lære:
Viktigheten av funksjonelle og kosmetiske feil
Feil er uunngåelig i programvareutvikling. Derfor er det alltid veldig viktig å utføre programvaren grundig testing før den kan brukes live. Programvaretesting kan bli viktigere ettersom de hjelper til med å identifisere bugs savnet av utviklerne .
Disse uidentifiserte feilene kan bli veldig kostbare i live. Derfor må en riktig testplan og testingen utføres for å forbedre programvarekvaliteten.
Figur 1:
Figuren ovenfor må laste opp en bildefil som programvaren ikke har vist. Dette er et alvorlig problem som alvorlig kan forårsake virksomhetspåvirkning.
Kosmetiske feil og deres betydningsfulle betydning
Kosmetiske krav er bare brukergrensesnittet eller bare programvarens frontend. De fleste ganger hender det at det stadig skifter mellom forskjellige utgivelser.
Dette skjer spesielt i prosjektene der den smidige metodikken følges. Utgivelsene skjer her i form av sprint. Derfor kalles de vanligvis Sprint release eller bare SR-xx, hvor ‘xx’ refererer til utgivelsesnummeret.
Hver utgivelse kan ha et visst sett med krav. Generelt forbereder kundene seg ofte på å be om endringer i brukergrensesnittet eller bare brukergrensesnittet.
Følgende er noen eksempler på kosmetiske krav:
- Menyene må være tilgjengelige med Calibri-skrift og.
- Tekstboks A må være i 1,2 tommer
- Alle genererte rapporter må ha tittelen med H1-størrelse med '002522' farge.
Ovennevnte er noen få eksempler på kosmetiske krav som kan komme opp. Dette er kravene som hovedsakelig er rettet mot improvisere programvarens brukervennlighet . En annen grunn bak de kosmetiske kravene er å optimalisere programvaren og dens design for forretningsformålet.
Fig 2
I figuren ovenfor er det både funksjonelle og kosmetiske problemer. Et funksjonelt problem som avkrysningsrute vises ikke for et alternativ “Bruk DeathByCaptcha”.
Det kosmetiske problemet kan sees her som ingen enhetlig skrift som har blitt brukt.
Prioritert faktor for kosmetiske feil eller behov fra klienter
De kosmetiske behovene er merket litt avgjørende av kundene. Dette er på grunn av bekymringen for behovet for å gjøre samspillet mellom programvaren veldig enkelt og samtidig effektivt, slik at måloppnåelsen lett oppstår. I tilfelle det er problemer med brukergrensesnittet, når klienter leverandørene med en lavprioritetsfeil.
Som det vanligvis skjer, er de funksjonelle aspektene ved programvaren bekymret for utviklerne enn de kosmetiske aspektene, da de for det meste er områder med lite påvirkning.
Programvaretesterne vil at alle kravene nevnt av klientene skal være tilgjengelige i programvaren som ikke feiler, noe de naturlig gir en feil. Og det er her hvor alle tar av. Prioriteten som testeren setter oppstår som et resultat av klientens forslag. Utviklernes syn er litt annerledes enn det testere ser på. De ser alltid om feilen kan føre til et brudd i funksjonaliteten.
Her kommer noen gjentatte diskusjoner, og resultatet av det kan få anbefalingene fra testteamet til å skje på et tidspunkt. Hvis ikke i den nåværende utgivelsen, kan det skje i den påfølgende.
Virkelig eksempel # 1)
Kunden har bedt om at firmalogoen skal vises på hjemmesiden i tittelrammen sammen med en hurtiglastingsfunksjon. Leverandøren har levert programvaren der firmalogoen tar tid å laste inn og klientene med følelsen av at logoen ikke lastes fortsetter for å reise et kundesendingsproblem.
Derfor har dette gjort mer skade for leverandørene. Årsaken til problemet kan være størrelsen på bildet eller bildet eller noe annet. Selv om dette ikke har funksjonelle pauser, har dette blitt satt opp som et live-problem.
Funksjonelle bugs - Kritiske og prioriterte faktorer
Generelt blir feilene ansett som prioritert basert på prioriteten som er satt av klientene og de potensielle konsekvensene de kan etterlate i virksomheten. Det er den generelle troen på tvers av utviklerne at de høye kritiske feilene skal jobbes med. Dette er mer åpenbart da de funksjonelle feilene er noe som undertrykker arbeidet deres.
Og basert på prioritering, vil klientene prioritere noen av de funksjonelle og kosmetiske feilene i samme utgivelse. Kritikkfaktoren avhenger av virkningen eller potensiell innvirkning feilen kan etterlate den. Prioritetsfaktoren er basert utelukkende på klienten og deres behov.
Når det gjelder kritikk, er funksjonelle feil mye nødvendig for å bli løst uten forsinkelser. For de kosmetiske feilene kan de følge beslutningene klientene tar
Fig 3
I figuren ovenfor er det funksjonelle problemer som designproblemer og tekstoverlappende og kosmetiske problemer som skriftproblemet.
Virkelig eksempel 2)
Klienten i eksempel 1 hadde flere utgivelser fra samme leverandør. Kundene er fornøyde med leveransen fra leverandørene. Nå er det plutselig få forretningsscenarier som klientene identifiserte som ikke fungerer sammen med få andre lister over skjermproblemer. Siden de funksjonelt påvirker problemene anses å være kritiske for kundene, ba de leverandørene om å fikse dem ASAP.
Og ettersom skjermproblemene hadde tegn til å gi mindre grad av påvirkning, prioriterte klientene dem i flere utgivelser. Klienter var klare til å komme i gang med reparasjoner for noen av skjermproblemene og de fleste funksjonelle problemer. Dette er fordi alle funksjonene kan påvirke virksomheten, og de få skjermproblemene har potensiale til å skape effekter.
Virksomhetspåvirkninger
Alle feil kan føre til at programvaren ikke samsvarer med kundens krav. Når det gjelder påvirkningene i virksomheten, er det definitivt de funksjonelle feilene som fortjener å forårsake alvorlige konsekvenser for virksomheten. Ettersom kosmetiske feil samsvarer med problemet med UI-design og utseende, kan de skape problemer med brukervennligheten og utseendet blant brukerne.
Disse kalles med andre ord bedre som kosmetiske forbedringer enn insekter. Selv om disse ikke kan påvirke virksomheten i større grad, kan de medføre vanskeligheter blant brukerne mens de bruker programvaren.
Virkelig eksempel # 3)
programvareutvikling livssyklus designfase
Leverandører har levert en ny versjon av programvaren i en mobilversjon. Det er få funksjoner i mobilappene som krevde at brukeren klikker på noen lenker oftere. Dette skapte en følelse av svekket brukervennlighet blant brukerne. Leverandørene må revurdere designet og flyten i applikasjonen. Etter å ha endret flyten begynte applikasjonen å få flere brukere til å bruke dem.
Brukervennlighet tar hovedrollen i mange slike applikasjoner. Selv om det ikke var noen funksjonelle endringer, var det få endringer i kosmetikk som gjorde at applikasjonene ble sterkere
Sammenlignende studie mellom kosmetiske insekter og funksjonelle insekter
Det kan være en rekke variasjoner mellom klassifiseringen av feil som funksjonelle og kosmetiske i flere aspekter i programvaretestets livssyklus. Få blant dem er formulert og tabellert som en forskjell mellom begge typene:
Sammenligningsområde | Funksjonelle bugs | Kosmetiske insekter |
---|---|---|
Potensielle årsaker | Det kan være flere årsaker: 1. Kodingsproblemer 2. Synkroniseringsproblemer 3. Avhengige applikasjonsproblemer | Følgende kan forårsake problemet: 1. Designproblemer 2. Filstøtte som ikke støttes |
Grad av rekreasjon | Rekreasjon av de funksjonelle feilene kan gjøres enten av testerne eller av klientene selv | Kosmetiske insekter krever minimal innsats i rekreasjon da de hovedsakelig identifiseres på UI-nivå |
Kritikk | De er for det meste kritiske, ettersom funksjonell nedbrytning kan påvirke virksomheten i en alvorlig form | De kan bli kritiske ved veldig få anledninger. |
Prioritet | Prioriteten er som definert av klientene | Prioriteten er som definert av klientene |
Potensiell innvirkning | Funksjonell sammenbrudd kan forårsake alvorlige problemer i kundenes virksomhet | Selv om de ikke kan skape direkte innvirkning, kan de også ta på seg å få potensielle påvirkninger. |
Forbedringer hensyn | Disse feilene kan aldri anbefales eller betraktes som forbedring | Disse feilene kan betraktes som forbedring |
Kostnader når ikke fast | Høye kostnader når problemet blir funnet på live programvare | Ikke mye kostnad |
Kosmetiske bugillustrasjoner
Den kosmetiske feilen kan forårsake innvirkning noen steder der det er firmalogoer eller partnerskapets bilder på programvaren, men den lastes ikke riktig. Selv om de ikke er funksjonelle feil, kan de bli alvorlige. La oss forstå følgende illustrasjoner for å forstå viktigheten av kosmetiske feil og deres viktige rolle.
Casestudie
Programvare A utvikles av leverandøren B. Modusen for leveranser til klienten er i form av kodedråper en gang i måneden etter at en versjonsversjon er utgitt. Fra det leverte produktet vil kundene liste opp alle problemene, feilene, forbedringene basert på deres kritikk og prioritet.
Prioritet går som P1, P2, P3 og P4.
Kritikk går som Alvorlig, stor, høy og lav.
Nå forventer kundene at alle alvorlige, store, P1-feil blir løst i uke 30. Tilsvarende forventes de høye, P2-feilene i uke 35. Lave, P3-feilrettinger forventes i uke 40. Til slutt forventes P4-feilene i uken 40. Mellom all utgivelsen av reparasjonene, blokkerer klienten tre dagers bufferperiode.
Nå blir følgende observasjon veldig kritisk:
- Ettersom det er planlagt som en rørledningsmodus, vil enhver forsinkelse påvirke de påfølgende planene på en større måte.
- Prioritetene blir dannet av klientene, og de planlegger derfor å løslate i den perioden de ønsker
- Forsinkelsen i feil med lav prioritet har potensial til å oppgradere prioriteten fra lav prioritet til høyere.
- Mindre forsinkelser kan føre til alvorlige konsekvenser for virksomheten, slik at små og små feil blir større.
Testere og utviklere møtes
“Ikke tell eggene før de klekkes ut” - Denne linjen gjelder for både utviklere og testere. Når programvare er utviklet og klar til å bli testet, har testerne en tendens til å tenke på linjene ovenfor. Etter testing er det nå utvikleres tur til å stave linjene til testerne. Følgende er tankene som flyter mellom dem:
- Testere sier utviklerne at det er så mange feil vi kan fange i programvaren din. Derfor er ikke arbeidet ditt over.
- Etter at testfasen er fullført, og etter mange feil, sier utviklere at du ikke tror du har reist flere feil, vi vil finne riktig grunn til å avvise de fleste feilene du har reist som ikke er ekte.
Derfor er det alltid en slags argumenterende tilnærming som går mellom testere og utviklere. For å sikre at hele prosjektleveransen er synkronisert, er det viktig at en mellomliggende person (prosjektleder) som kan løse kontroversene, slik at resultatene blir optimalisert og absolutt uten feillekkasje.
Konklusjon
Ovennevnte artikler må ha forklart alle uunngåelige og viktige aspekter av de kosmetiske feilene og hvordan det kan sammenlignes med de funksjonelle feilene . Ovennevnte artikkel forklarer også hvordan de kosmetiske feilene kan behandles sammenlignet med de funksjonelle feilene.
Selv om kritikkverdiene til funksjonelle bugs er høyere enn kosmetiske bugs, forbeholder sistnevnte sin egen plass i å få prioriteringer fra klientene. For å balansere programvaren med oppløsninger for alle feilene, det anbefales generelt å behandle feilene for å forstå kritikken, prioriteten og klientens anbefaling.
Om forfatteren: Dette er en artikkel skrevet av Nagarajan. Han jobber som en testleder med over 6 års erfaring med testing innen ulike funksjonelle områder som Banking, Airlines, Telecom når det gjelder både manuell og automatisering.
Hva tar du med kosmetiske og funksjonelle feil? Jeg vil gjerne se tankene dine nedenfor.
Anbefalt lesing
- Kognitiv skjevhet i programvaretesting: Hvorfor savner testere feil?
- Hvorfor har programvare feil?
- Hvordan løser jeg alle feilene dine uten 'Ugyldig feil' -merke?
- Funksjonstesting mot ytelsestesting: Bør det gjøres samtidig?
- 10 grunner til at feilene dine blir avvist, og hva du kan gjøre for det som tester!
- Hva er Longevity Testing? Hvordan fange feil før kunden finner det
- Kunsten med feilrapportering: Hvordan markedsføre og få fikset feilene dine?
- Topp 30 funksjonelle testverktøy i 2021