5 vinkkiä virheettömän ohjelmistokehityksen varmistamiseksi

Onko ohjelmistossasi bugeja? Tietysti on, koska jokaisessa saatavilla olevassa ohjelmistossa on ongelmia ja virheettömän ohjelmiston tarina on myytti. On kuitenkin edelleen mahdollista merkittävästi minimoida bugeja, virheitä ja tietoturvaongelmia noudattamalla muutamia kirjallisia mutta käytännöllisiä rajoitustekniikoita.

Virheenseurantaan liittyy paljon kurinalaisuutta, koska se edellyttää kaikkien rohkaisemista noudattamaan sääntöjä. Etenkin startup-yrityksillä ja luovilla aloilla voi olla melko vaikeaa estää epävirallista viestintää. Itse asiassa monissa tapauksissa ihmiset eivät nimeä ”vikojen seurantaa” projektin keskittyneimmäksi osaksi.

Mistä vikaseurannassa oikein on kysymys?

Technopedian mukaan: ”Virheiden seuranta on prosessi, jota laadunvarmistushenkilöstö ja ohjelmoijat käyttävät seuratakseen ohjelmistoongelmia ja ratkaisuja.”

Virheenseurantajärjestelmä hallitsee siksi kaikkia tietoja ilmoitetuista virheistä ja seuraa jokaisen vian tilaa. Näet varmasti laajan tiedon tarpeen ongelmien seurannassa. Riittävän tiedon tarjoaminen vaatii paitsi valtavan ajan, myös runsaasti ohjelmistokehityksen taitoja.

Virheluokitus

Ohjelmistovirheitä on kolmenlaisia:

• Väärät tiedot
• Toteutusvirheitä
• Erittely puuttuu

Mikä tahansa näistä virhetyypeistä voidaan helposti luokitella kriittiseksi ongelmaksi (tai luokitella uudelleen parannukseksi). Edellä mainitaan joitain uudelleenluokitteluohjeita, joita Xolv.io:n perustaja Sam Hatoum käyttää.

• Aiheuttaako virheellinen määrittely meille tappiota? Esimerkiksi määrittelytiloissa seurataan napsautusten määrää, milloin sen pitäisi seurata kulutusta Luokittele vika uudelleen.
• Voiko toteutusvirheen jättää huomiotta? Esimerkiksi verkkofonttia asennetaan, kun se pitäisi upottaa ohjelmistoon.
• Tarkoittaako puuttuva spesifikaatio uusia toimintoja? Esimerkiksi käyttäjät eivät voi jakaa ja muokata profiilitietojaan sosiaalisessa mediassa.

Tuotepäälliköiden panokset kasvavat bugien tehokkaaseen luokitteluun, sillä kehitystiimiä ohjeistetaan priorisoimaan virheet kaiken muun työn kustannuksella. Kehittäjät eivät toimi tai mitään muuta ennen kuin kaikki virheet on poistettu.

Ryhmän laatustandardien muodostaminen

Kun suunnittelu- ja kehitystiimi päättää, voidaanko sovellusvirus luokitella uudelleen parannukseksi, tämä päätösprosessi ilmaisee implisiittisesti tiimin laatustandardit. Esimerkiksi korkealaatuista visuaalisuutta korostavalla brändin omistajalla saattaa olla alhainen toleranssi suunnittelun eroavaisuuksiin. Sen sijaan he luokittelevat nämä ongelmat uudelleen bugeiksi.

Johdonmukaisen uudelleenluokitusjärjestelmän avulla voit jatkuvasti mukauttaa odotuksia ja todellisuutta samalla kun säilytät jäsennellyn toimitustavan, joka asettaa tiimisi laatustandardit etusijalle.

Bugien epäonnistumiset

Viimeaikaiset tutkimukset väittävät, että lähes 40 prosenttia järjestelmävioista johtuu ohjelmistovirheistä, kun taas muut tietoturvaongelmat ja ohjelmien haavoittuvuudet aiheuttavat 60 prosenttia yleisistä muistiin ja samanaikaisuuteen liittyvistä ongelmista. Ohjelmistovirheiden vähentäminen sovelluksessasi on paras tapa lisätä ohjelmistosi turvallisuutta, vakautta ja luotettavuutta.

Vinkkejä virheettömän ohjelmistokehityksen varmistamiseksi

Logging-työkalun SmartInspectin kehittämisen aikana kehittäjät käyttivät monia menetelmiä pitääkseen järjestelmänsä korkeana. Edellä mainittu luettelo sisältää joitain heidän käyttämänsä tekniikat.

1 Kommunikaatiotilan luominen

Virheiden havaitseminen ja ilmoittaminen vaatii taitoja tunnistaa asiaankuuluvat tiedot, jotka sitten lisätään jokaiseen ongelmaraporttiin. On olemassa monia virheenseuranta- ja laadunvarmistustyökaluja, kuten Usersnap, jotka tarjoavat mahdollisuuden liittää tarvittavat tiedot automaattisesti. Siitä huolimatta, aina on tilaa puuttuville tai väärinymmärretyille tiedoille, mikä johtaa asianmukaisen viestinnän tarpeeseen.

Tietyissä testausskenaarioissa ei ole tilaa sellaiselle paljastamiselle kehittäjien ja testaajien välillä. Kysymyksiä, kuten: ”Miten voin ottaa yhteyttä vastaaviin asiantuntijoihin?” tai ”Voiko palautetta pyytää puhelimitse tai sähköpostitse?” on vastattava virheenseurantaprosessin alussa.

Väärinkäsitysten välttämiseksi testaajien ja kehittäjien puolesta yritä tuoda kaikki samalle sivulle ja luoda palautelähtöinen kulttuuri, jossa molempien osapuolten työtä kunnioitetaan samalla tavalla.

2 Pidä se yksitellen

Vältä keskustelemasta virheistä projektikokouksessa. Älä nyt ymmärrä minua väärin. Ryhmätyöskentelyssä, toistamisessa ja virheiden korjaamisessa ei ole mitään pahaa. Mutta älä keskustele ongelmista pitkissä kokouksissa koko kabinetin kanssa. Usersnap.comin tech-bloggaajan Thomas Pehamin mukaan virheiden ilmoittaminen ja niistä keskusteleminen seuraavassa kehitystestivaiheessa on melko hidasta lähestymistapaa.

On todellakin paljon tehokkaampaa pitää se yksittäin. Kuten Yegor kirjoitti artikkelissaan virheseurannan viidestä periaatteesta, jokainen vikaraportti on linkitetty kahden henkilön – määrittäjä ja ongelmanratkaisija – välillä. Riippumatta siitä, kuinka monta henkilöä prosessissa on mukana, raportoidun ongelman ratkaisemisessa on vain kaksi päävastuuta (kaksi eri roolia).

3 Varmista sisäänosto joukkueeltasi

Jos koko tiimisi ei käytä sitä, hyvä virheenseurantatietokanta olisi tehoton. On parasta aloittaa pyytämällä kaikki sidosryhmäsi (asiakaspalvelu, laadunvarmistus, projektipäälliköt ja kehittäjät) arvioimaan työkaluja ja yrittämään tehdä päätös yhdessä. virheiden kirjaaminen ja korjaaminen johdonmukaisella tavalla käyttämällä samaa järjestelmää.

Jos sinulla on vaikeuksia saada ihmisiä mukaan, tässä on mitä voit tehdä;

Kehittäjille on säädettävä laki virheilmoitusten hyväksymisestä yksittäisten tietokantojen kautta eikä minkään muun menetelmän kautta. Kun testaajat lähettävät sinulle palautetta sisältäviä sähköposteja, pyydä heitä vain heittämään raportit tietojärjestelmään. Sen lisäksi, että asiat pysyvät järjestyksessä, tämä auttaa myös raportoinnissa antamalla kaikki tarvittavat tiedot ja määrittelemällä tarvittavat kentät.

Toinen tapa tehokkaamman prosessin luomiseen on laadunvarmistus tai tuki asiakkaiden virheiden tarkistamiseksi ja tarkan vaiheiden lisääminen tietokantaan ennen kuin kehittäjille on edes ilmoitettu. Ohjelmistoongelmien tehokas seuranta on yksi luotettavan ja johdonmukaisen projektinhallintakehyksen tärkeimmistä puolista.

• Hyvä debuggeri

Jos käytät järjestelmiä, kuten Visual Studio tai Delphi, sinulla on jo pääsy erittäin tehokkaaseen debuggeriin, jota sinun tulee käyttää. Jos kyseessä on komentosarjaympäristö, jossa kehittäjät yrittävät usein poistaa virheitä yrityksen ja erehdyksen avulla, prosessi ei ole vain hankala tapa tunnistaa ja ratkaista ongelmia, vaan se on myös erittäin vaarallinen, jos et ymmärrä koodiasi täysin etkä pysty käy se läpi debuggerilla. Tee itsellesi palvelus hankkimalla tiimillesi hyvä virheenkorjausalusta – virheenkorjauksia on lähes kaikkeen.

4 Tiedä mitä ”suljettu” bugi tarkoittaa

Oletko koskaan ollut mukana keskustelussa vian sulkemisesta? No, onnittelut, olet ollut pahimmassa mahdollisessa virheenseurantatilanteessa, mitä koskaan voi tapahtua.

Jos huomaat keskustelussa ”vian tilasta”, harkitse askelta taaksepäin ja kysy itseltäsi seuraavat kysymykset:

• Kenen vastuulla on hyväksyä tulokset?
• Mitkä ovat hyväksymiskriteerit?
• Kuka on vastuussa tilauksen antamisesta?

Katsokaa sanan ”suljettu” merkitystä. Useimmissa kehitystiimeissä virheen korjaanut henkilö sulkee vian. Peham suosittelee virheilmoituksen sulkemista ongelmasta ilmoittaneen henkilön toimesta. Kun kehittäjä on esittänyt ratkaisun tiettyyn bugiin, toimittajaa tulee pyytää sulkemaan raportti. Näin varmistettaisiin, että palaute on riittävä ratkaisu ohjelmistosekaannuksiin.

5 virtuaalikonetta

Jotta voit testata ohjelmistosi virheiden varalta useissa eri käyttöjärjestelmissä ja ympäristöissä, sinun tulee käyttää virtuaalikoneita työkalujen, kuten Virtual PC:n tai muiden saatavilla olevien virtualisointiohjelmistojen kanssa. Voit säästää tonnia aikaa tällä menetelmällä, koska voit helposti kopioida, jakaa ja nollata virtuaalikoneita, jolloin voit testata ohjelmistoasi kaikenlaisissa kokoonpanoissa.

On aina parempi luoda erilaisia ​​​​standardiotoksia kaikille säännöllisesti testaamillesi käyttöjärjestelmille ja laittaa ne tiedostopalvelimelle. Kun tarvitset erittäin spesifisen kokoonpanon testataksesi jotain, voit aloittaa jollakin peruskuvasta asentamatta käyttöjärjestelmää, tarvittavia ohjelmistoja ja ohjaimia ja niin edelleen.

Se ei ole uusi käsite

Kun Hatoum keksi tämän konseptin, hän huomasi, että Zero-Bug-ohjelmiston idea ei ole uusi. Se on itse asiassa ollut olemassa 1960-luvulta lähtien, kuten monet unohdetut vanhan koulukunnan filosofiat.

Legendaarinen laatuasiantuntija Phillip Crosby keksi termin Zero-Defect työskennellessään Martin Companyssa tai tällä hetkellä tunnetulla nimellä ”Lockheed Martin”, jossa kerrottiin, että he saavuttivat ”hallituksen tarkastuksen alaisena laitteistovikojen vähentämisen 54 %”.

Aluksi Zero-Defect -tekniikkaa käytettiin ilmailuteollisuudessa 60-luvulla, ja sitten sitä sovellettiin autoteollisuudessa 1990-luvulla. Valmistavan teollisuuden ja ohjelmistotoimituksen välillä on monia yhtäläisyyksiä.

Esimerkiksi suosittu ketterä johtamismuoto Kanban sai alkunsa Toyotan tuotantojärjestelmästä. Pohjimmiltaan tämä kertoo meille, että voimme helposti tutkia näitä valmistusprosesseja saadaksemme teknistä inspiraatiota ohjelmistojen tai sovellusten kehittämisessä, ja Zero-Bug on yksi niistä inspiraation lähteistä.

Standardin täyttämisen äärimmäiset kustannukset ovat kuitenkin yksi suuri kritiikki Zero-Defect -lähestymistavasta kohtaan. Ja jos se toteutetaan väärin, tämä voi todellakin olla totta. Zero-Bug -lähestymistavassa Hatoum on käsitellyt tätä ongelmaa suoraan luokittelemalla bugit ominaisuuksiin ja parantamalla merkittäviä parannuksia, jolloin kustannuksia voidaan hallita joukkueen laatustandardien avulla.

Aloita tänään

Tekniikkakäyttäjänä ja kehittäjänä voit alkaa käydä läpi kaikki olemassa olevat virheet ja luokitella ne käyttämällä edellä mainittua järjestelmää. Jos uskot, että sinulla on satoja tuhansia ongelmia, tämä saattaa olla hyvä aika ruuhkauttaa ne ja aloittaa alusta. Älä huoli, voit aina siirtää vikoja arkistoista nykyiseen verkkotunnukseen tarpeen mukaan.

Kehitystiimin ei välttämättä tarvitse odottaa, kunnes koko luokitteluharjoitus on suoritettu, ennen kuin he alkavat purkaa vikoja; ne voivat aloittaa heti, kun muutama bugi on luokiteltu. Ryhmä ei saa aloittaa työskentelyä muiden ruuhkassa olevien kohteiden parissa ennen kuin kaikki kohteet on ”vapautettu” tai luokiteltu uudelleen. Juuri tämä sääntö pakottaa tuotepäälliköt priorisoimaan uusia töitä oikein.

Yhteenvetona

Jokainen projektin ilmoitettu virhe vaatii lisäaikaa korjaamiseen. Virheiden seuranta vaatii siksi hyviä kommunikointitaitoja virheitä jäljittäviltä henkilöiltä sekä herkkyyttä niitä korjaavilta. Edellä mainittujen seurantahakkerointien avulla tiimisi voi yrittää olla tuottavampi raportoidessaan kaikenlaisista teknisistä tai tietoturvaesteistä.