5 tips for å sikre en feilfri programvareutvikling

Har programvaren din feil? Selvfølgelig gjør det det, siden alle programmer som er tilgjengelige der ute har problemer og feilfri programvarehistorie er en myte. Det er imidlertid fortsatt mulig å redusere feil, feil og sikkerhetsproblemer betraktelig ved å følge noen få boklige, men praktiske begrensningsteknikker.

Det er mye disiplin involvert når det kommer til feilsporing, da det krever å oppmuntre alle til å holde seg til reglene. Spesielt i startups og kreativt drevne bransjer kan det være ganske vanskelig å fraråde enhver uformell kommunikasjon. Faktisk nevner folk i mange tilfeller ikke «feilsporing» som den mest fokuserte delen av et prosjekt.

Hva handler feilsporing egentlig om?

Ifølge Technopedia: «Feilsporing er en prosess som brukes av kvalitetssikringspersonell og programmerere for å holde styr på programvareproblemer og løsninger.»

Et feilsporingssystem administrerer derfor all informasjon om rapporterte feil og holder styr på statusen til hver feil. Du ser definitivt behovet for omfattende informasjon mens du sporer problemer. Å gi tilstrekkelig data krever ikke bare en enorm mengde tid, men også rikelig med ferdigheter innen programvareutvikling.

Feilklassifiseringen

Det er tre typer programvarefeil:

• Feil spesifikasjoner
• Gjennomføringsfeil
• Mangler spesifikasjon

Enhver av disse feiltypene kan enkelt klassifiseres som et kritisk problem (eller omklassifiseres som en forbedring). Nedenfor er noen av retningslinjene for omklassifisering som brukes av Sam Hatoum, grunnlegger av Xolv.io.

• Gir feil spesifikasjon oss tap? For eksempel angir spesifikasjonen spore klikk teller, når det skal spore utgifter Reclassify Bug.
• Kan gjennomføringsmangelen neglisjeres? For eksempel installeres nettskrift når den skal være innebygd i programvaren.
• Innebærer den manglende spesifikasjonen nye funksjoner? For eksempel kan ikke brukere dele og redigere profildetaljer på sosiale nettverk.

Innsatsen økes for at produktlederne effektivt skal kunne klassifisere feil, siden utviklingsteamet er instruert om å prioritere feil fremfor alt annet arbeid. Utviklerne vil ikke fungere eller noe annet før alle feilene er fjernet.

Danne teamkvalitetsstandarder

Når et design- og utviklingsteam bestemmer om et appvirus kan omklassifiseres som en forbedring eller ikke, angir den beslutningsprosessen implisitt teamets kvalitetsstandarder. For eksempel kan en merkevareeier som legger vekt på grafikk av høy kvalitet ha lav toleranse for designavvik. De ville i stedet omklassifisere disse problemene som feil.

Et konsistent omklassifiseringssystem lar deg kontinuerlig tilpasse forventning kontra virkelighet, samtidig som du opprettholder en strukturert leveringstilnærming som setter teamets kvalitetsstandarder først.

Feilen feiler

Nyere studier hevder at nesten 40 prosent av systemfeilene er forårsaket av programvarefeil, mens andre sikkerhetsproblemer og programsårbarheter står for 60 prosent, forårsaket av vanlig minne og samtidighetsrelaterte problemer. Å redusere programvarefeil i applikasjonen din er den beste måten å øke sikkerheten, stabiliteten og påliteligheten til programvaren på.

Tips for å sikre en feilfri programvareutvikling

Under utviklingen av loggverktøyet SmartInspect brukte utviklerne mange metoder for å holde kvaliteten på systemet deres høy. Listen nevnt foran inneholder noen av teknikkene de brukte.

1 Skape rom for kommunikasjon

Å oppdage og rapportere feil krever ferdigheter til å identifisere relevant informasjon som deretter legges til i hver problemrapport. Det er mange feilsporings- og kvalitetssikringsverktøy som Usersnap som tilbyr muligheten til automatisk å legge ved nødvendig informasjon. Det vil likevel alltid være rom for manglende eller misforståelse av informasjon, noe som resulterer i behov for forsvarlig kommunikasjon.

I visse testscenarier er det ikke rom for den typen avsløring mellom utviklerne og testerne. Spørsmål som: ‘Hvordan kan jeg komme i kontakt med de ansvarlige ekspertene?’ eller ‘Er det greit å be om tilbakemelding via telefon eller e-post?’ må besvares i begynnelsen av feilsporingsprosessen.

For å unngå misforståelser på vegne av testere og utviklere, prøv å bringe alle på samme side og skap en tilbakemeldingsorientert kultur der arbeidet til begge parter respekteres på samme måte.

2 Hold det en-til-en

Unngå å diskutere feil i et prosjektmøte. Ikke misforstå meg nå. Det er ikke noe dårlig med å jobbe som et team, reprodusere og fikse feil. Men ikke diskuter problemer i langvarige møter med hele kabinettet. Ifølge Thomas Peham, en tech-blogger på Usersnap.com, er det en ganske treg tilnærming å rapportere feil og deretter diskutere dem i neste utviklings-‘retest’-fase.

Det er faktisk mye mer effektivt å holde det en-til-en. Som Yegor skrev i sin artikkel om de 5 prinsippene for feilsporing, er hver feilrapport koblet mellom to personer – spesifisereren og problemløseren. Uansett hvor mange personer som er involvert i prosessen, er det kun 2 hovedansvar (med to forskjellige roller) for å løse et rapportert problem.

3 Sørg for en buy-in fra teamet ditt

Hvis hele teamet ditt ikke bruker det, vil en god feilsporingsdatabase være ineffektiv. Det er best å starte med å få alle dine interessenter (kundeservice, kvalitetssikring, prosjektledere og utviklere) til å evaluere verktøy og prøve å ta en beslutning sammen; logging og adressering av feil på en konsistent måte ved å bruke samme system.

Hvis du sliter med å få folk om bord, er dette hva du kan gjøre;

For utviklere, fastsetter loven om å akseptere feilrapporter gjennom individuelle databaser og ikke noen annen metode. Når testere sender deg e-post med tilbakemelding, ber du dem ganske enkelt om å kaste rapportene i informasjonssystemet i stedet. I tillegg til å sikre at ting holder seg organisert, hjelper dette også med rapporteringen ved å gi all nødvendig informasjon og definere de nødvendige feltene.

En annen måte å lage en mer effektiv prosess på er å la QA, eller støtte verifisere feil fra kunder og legge til de nøyaktige trinnene i databasen før utviklerne i det hele tatt blir varslet. Effektiv sporing av programvareproblemer er en av de mest essensielle aspektene ved å ha et pålitelig og konsistent rammeverk for prosjektstyring.

• En god debugger

Hvis du bruker systemer som Visual Studio eller Delphi, har du allerede tilgang til en ekstremt kraftig debugger som du bør bruke. I tilfelle av et skriptmiljø der utviklere ofte prøver å eliminere feil ved prøving og feiling, blir prosessen ikke bare en tungvint måte å identifisere og løse problemer på, men den er også veldig farlig hvis du ikke forstår koden din fullt ut og ikke er i stand til å gå gjennom det med en debugger. Gjør deg selv en tjeneste ved å få en god feilsøkingsplattform for teamet ditt – det finnes feilsøkingsprogrammer for nesten alt.

4 Vet hva en «lukket» feil betyr

Har du noen gang vært involvert i en diskusjon om å lukke en feil? Vel, gratulerer, du har vært i den verst mulige feilsporingssituasjonen som noen gang kan finne sted.

Hvis du befinner deg i en diskusjon om «feilstatus», bør du vurdere å ta et skritt tilbake og stille deg selv følgende spørsmål:

• Hvem sitt ansvar er det å akseptere resultater?
• Hva er kriteriene for aksept?
• Hvem er ansvarlig for å gi ordren?

Ta en titt på betydningen av «stengt». I de fleste utviklingsteam lukkes en feil av personen som fikset feilen. Peham anbefaler å lukke feilrapporten av personen som rapporterte problemet. Når løsningen for en bestemt feil er fremmet av utvikleren, bør reporteren bli bedt om å lukke rapporten. Dette vil sikre at tilbakemeldingen er en tilstrekkelig løsning for programvareforvirringene.

5 virtuelle maskiner

For å teste programvaren for feil på mange forskjellige operativsystemer og miljøer som mulig, bør du bruke virtuelle maskiner med verktøy som Virtual PC eller annen tilgjengelig virtualiseringsprogramvare. Du kan spare tonnevis av tid gjennom denne metoden fordi du enkelt kan kopiere, dele og tilbakestille de virtuelle maskinene, slik at du kan teste programvaren din på alle slags konfigurasjoner.

Det er alltid å foretrekke å lage forskjellige standardbilder for alle operativsystemer du regelmessig tester og legge dem på en filserver. Når du har behov for en svært spesifikk konfigurasjon for å teste noe, kan du starte med et av basisbildene uten å installere operativsystemet, nødvendig programvare og drivere og så videre.

Det er ikke et nytt konsept

Da Hatoum kom opp med dette konseptet, fant han ut at ideen om Zero-Bug-programvare ikke er ny. Det har faktisk eksistert siden 1960-tallet, som mange av de glemte old-school filosofiene.

Den legendariske kvalitetseksperten, Phillip Crosby, fant opp begrepet Zero-Defect mens han jobbet i Martin Company eller som i dag kjent ‘Lockheed Martin’, hvor det ble rapportert at de oppnådde «en 54% defektreduksjon i defekter i maskinvare under statlig revisjon».

Opprinnelig ble Zero-Defect-teknikken brukt i romfartsproduksjon på 60-tallet, og ble deretter brukt i bilproduksjon på 1990-tallet. Det er mange likheter mellom produksjonsindustrien og programvarelevering.

Den populære smidige administrasjonsmetoden Kanban stammer for eksempel fra Toyota Production System. Det dette i utgangspunktet forteller oss er at vi enkelt kan se nærmere på disse produksjonsprosessene for teknisk inspirasjon i programvare- eller apputvikling, og Zero-Bug er en av disse inspirasjonene.

Den ekstreme kostnaden ved å møte standarden er imidlertid en stor kritikk av Zero-Defect-tilnærmingen. Og hvis det implementeres feil, kan dette faktisk være sant. I Zero-Bug-tilnærmingen har Hatoum direkte håndtert dette problemet gjennom omklassifisering av feil til funksjoner og betydelige forbedringer, slik at kostnadene kan kontrolleres gjennom teamets kvalitetsstandarder.

Start i dag

Som teknologibrukere og utviklere kan du begynne å gå gjennom alle eksisterende feil og klassifisere dem ved å bruke det nevnte systemet. Hvis du tror du har hundretusenvis av problemer, kan dette være et godt tidspunkt å logge dem på og starte på nytt. Ikke bekymre deg, du kan alltid flytte feil fra arkivene til det gjeldende domenet etter behov.

Utviklingsteamet trenger ikke nødvendigvis å vente til hele klassifiseringsøvelsen er fullført før de begynner å klemme feil; de kan komme i gang så snart noen få feil er klassifisert. Teamet må ikke begynne å jobbe med noen andre elementer i backlog før alle elementer er «feilfrigjort» eller omklassifisert. Det er nettopp denne regelen som tvinger produktledere til å prioritere nytt arbeid riktig.

Oppsummerer det

Hver rapporterte feil i et prosjekt krever ekstra tid for å bli fikset. Feilsporing krever derfor gode kommunikasjonsevner fra enkeltpersoner som sporer feilene, samt følsomhet fra de som fikser dem. Med de nevnte sporingshackene kan teamet ditt prøve å være mer produktivt mens de rapporterer alle slags teknologi- eller sikkerhetshinder.