5 näpunäidet veavaba tarkvaraarenduse tagamiseks

Kas teie tarkvararakendustes on vigu? Muidugi on, kuna igal seal saadaoleval tarkvaraprogrammil on probleeme ja veavaba tarkvara lugu on müüt. Siiski on vigu, vigu ja turvaprobleeme võimalik märkimisväärselt minimeerida, järgides mõningaid raamatupäraseid, kuid praktilisi kärpimisvõtteid.

Vigade jälgimisega kaasneb palju distsipliini, kuna see nõuab kõigi julgustamist reeglitest kinni pidama. Eriti idufirmades ja loovalt juhitud tööstusharudes võib mitteametliku suhtluse takistamine olla üsna keeruline. Tegelikult ei nimeta inimesed paljudel juhtudel „vigade jälgimist” oma projekti kõige keskendunumaks osaks.

Milles veajälgimine tegelikult seisneb?

Technopedia sõnul: “Veajälgimine on protsess, mida kvaliteedi tagamise personal ja programmeerijad kasutavad tarkvaraprobleemide ja lahenduste jälgimiseks.”

Seetõttu haldab vigade jälgimise süsteem kogu teavet teatatud vigade kohta ja jälgib iga vea olekut. Probleemide jälgimisel näete kindlasti vajadust ulatusliku teabe järele. Piisavate andmete esitamine ei nõua mitte ainult tohutut aega, vaid ka ohtralt oskusi tarkvaraarenduse vallas.

Vigade klassifikatsioon

Tarkvaravigu on kolme tüüpi:

• Valed spetsifikatsioonid
• Rakendusvead
• Puudub spetsifikatsioon

Kõiki neid veatüüpe saab kergesti liigitada kriitiliseks probleemiks (või ümber liigitada täiustusteks). Eespool on mainitud mõningaid ümberliigitamisjuhiseid, mida kasutab saidi Xolv.io asutaja Sam Hatoum.

• Kas vale spetsifikatsioon põhjustab meile kahju? Näiteks spetsifikatsiooniolekud jälgivad klikkide arvu, millal see peaks jälgima kulutusi. Klassifitseeri viga ümber.
• Kas teostusviga võib tähelepanuta jätta? Näiteks installitakse veebifont, kui see peaks olema tarkvarasse manustatud.
• Kas puuduv spetsifikatsioon tähendab uusi funktsioone? Näiteks ei saa kasutajad sotsiaalvõrgustikes oma profiiliandmeid jagada ja muuta.

Tootejuhtidel tõstetakse panuseid vigade tõhusaks klassifitseerimiseks, kuna arendusmeeskonnal on ülesandeks seada vead kõigi muude tööde ees esikohale. Arendajad ei tööta ega muud, kuni kõik vead on eemaldatud.

Meeskonna kvaliteedistandardite kujundamine

Kui disaini- ja arendusmeeskond otsustab, kas rakenduse viirust saab täiustuseks ümber klassifitseerida või mitte, sätestab see otsustusprotsess kaudselt meeskonna kvaliteedistandardid. Näiteks võib kvaliteetset visuaali rõhutav kaubamärgiomanik taluda vähe kujunduslikke lahknevusi. Selle asemel liigitaksid nad need probleemid vigadeks.

Järjepidev ümberliigitamissüsteem võimaldab teil pidevalt kohandada ootusi tegelikkusele, säilitades samal ajal struktureeritud tarneviisi, mis seab teie meeskonna kvaliteedistandardid esikohale.

Vigade tõrked

Hiljutised uuringud väidavad, et peaaegu 40 protsenti süsteemitõrgetest on põhjustatud tarkvaraveadest, samas kui muud turbeprobleemid ja programmide haavatavused moodustavad 60 protsenti, mis on põhjustatud tavalistest mälu ja samaaegsusega seotud probleemidest. Tarkvaravigade vähendamine rakenduses on parim viis tarkvara turvalisuse, stabiilsuse ja töökindluse suurendamiseks.

Näpunäiteid veavaba tarkvaraarenduse tagamiseks

Logimistööriista SmartInspect väljatöötamise käigus kasutasid arendajad mitmeid meetodeid, et oma süsteemi kvaliteeti kõrgel hoida. Eespool mainitud loend sisaldab mõningaid nende kasutatud tehnikaid.

1 Suhtlemisruumi loomine

Vigade tuvastamine ja sellest teatamine nõuab oskusi tuvastada asjakohane teave, mis lisatakse seejärel igasse probleemiaruandesse. Seal on palju vigade jälgimise ja kvaliteedi tagamise tööriistu, nagu Usersnap, mis pakuvad võimalust vajaliku teabe automaatselt manustada. Sellegipoolest jääb alati ruumi puudulikuks või valesti mõistmiseks, mille tulemuseks on vajadus korraliku suhtluse järele.

Teatud testimise stsenaariumide korral ei ole arendajate ja testijate vahel ruumi selliseks avalikustamiseks. Sellised küsimused nagu: „Kuidas saan ühendust võtta vastutavate ekspertidega?” või “Kas on okei küsida tagasisidet telefoni või meili teel?” tuleb vastata veajälgimise protsessi alguses.

Et vältida arusaamatusi testijate ja arendajate nimel, proovige tuua kõik ühele lehele ja luua tagasisidele orienteeritud kultuur, kus mõlema poole tööd austatakse ühtemoodi.

2 Hoidke seda üks-ühele

Vältige vigade arutamist projekti koosolekul. Ärge nüüd minust valesti aru saage. Meeskonnatöös, paljundamises ja vigade parandamises pole midagi halba. Kuid ärge arutlege probleemide üle pikkadel koosolekutel kogu kabinetiga. Kasutajasnap.com-i tehnikablogija Thomas Pehami sõnul on vigadest teatamine ja nende arutamine järgmises arenduse „taastestimise” etapis üsna aeglane lähenemine.

Tõepoolest on palju tõhusam seda üks-ühele hoida. Nagu Jegor kirjutas oma artiklis vigade jälgimise 5 põhimõtet, on iga veateade seotud kahe inimese – täpsustaja ja probleemilahendaja – vahel. Olenemata sellest, kui palju inimesi protsessi kaasatakse, on teatatud probleemi lahendamisel ainult 2 peamist vastutust (kahe erineva rolliga).

3 Tagage oma meeskonna sisseost

Kui kogu teie meeskond seda ei kasuta, oleks hea vigade jälgimise andmebaas ebaefektiivne. Alustuseks on kõige parem panna kõik sidusrühmad (klienditeenindus, kvaliteedi tagaja, projektijuhid ja arendajad) tööriistu hindama ja ühiselt otsust langetama. vigade logimine ja kõrvaldamine järjepidevalt, kasutades sama süsteemi.

Kui teil on raskusi inimeste kaasamisega, siis siin on, mida saate teha.

Arendajate jaoks kehtestage seadus veateadete vastuvõtmise kohta üksikute andmebaaside kaudu, mitte mõne muu meetodi kaudu. Kui testijad saadavad teile tagasisidega e-kirju, paluge neil lihtsalt aruanded infosüsteemi visata. Lisaks asjade organiseerituse tagamisele aitab see ka aruandlusel, pakkudes kogu vajaliku teabe ja määratledes vajalikud väljad.

Teine võimalus tõhusama protsessi loomiseks on kvaliteedikontrolli või klientide vigade kontrollimise tugi ja täpsete sammude lisamine andmebaasi enne, kui arendajaid üldse teavitatakse. Tarkvaraprobleemide tõhus jälgimine on usaldusväärse ja järjepideva projektijuhtimise raamistiku üks olulisemaid aspekte.

• Hea silur

Kui kasutate süsteeme nagu Visual Studio või Delphi, on teil juba juurdepääs äärmiselt võimsale silurile, mida peaksite kasutama. Skriptimiskeskkonnas, kus arendajad püüavad sageli katse-eksituse meetodil vigu kõrvaldada, ei muutu see protsess mitte ainult tülikaks viisiks probleemide tuvastamiseks ja lahendamiseks, vaid on ka väga ohtlik, kui te ei mõista oma koodi täielikult ega suuda astuge siluriga läbi. Tehke endale teene, hankides oma meeskonnale hea silumisplatvormi – silureid on peaaegu kõige jaoks.

4 Tea, mida tähendab “suletud” viga

Kas olete kunagi osalenud arutelus vea sulgemise üle? Palju õnne, olete olnud halvimas võimalikus veajälgimise olukorras, mis kunagi juhtuda sai.

Kui leiate end nn vea oleku arutelust, kaaluge sammu tagasi astumist ja esitage endale järgmised küsimused.

• Kelle kohustus on tulemuste aktsepteerimine?
• Millised on vastuvõtmise kriteeriumid?
• Kes vastutab käsu andmise eest?

Heitke pilk sõna “suletud” tähendusele. Enamikus arendusmeeskondades sulgeb vea vea parandanud isik. Peham soovitab probleemist teatanud isikul veateate sulgeda. Kui arendaja on teatud veale lahenduse esitanud, tuleks paluda reporteril aruanne sulgeda. See tagaks, et tagasiside on tarkvaraprobleemide jaoks piisav lahendus.

5 virtuaalset masinat

Selleks, et testida oma tarkvara vigu paljudes erinevates operatsioonisüsteemides ja keskkondades, peaksite kasutama virtuaalmasinaid koos selliste tööriistadega nagu Virtual PC või muu saadaolev virtualiseerimistarkvara. Selle meetodi abil saate säästa palju aega, kuna saate virtuaalseid masinaid hõlpsalt kopeerida, jagada ja lähtestada, võimaldades teil oma tarkvara igasuguste konfiguratsioonidega testida.

Alati on eelistatav luua erinevaid standardkujutisi kõikidele operatsioonisüsteemidele, mida regulaarselt testite, ja panna need failiserverisse. Kui vajate millegi testimiseks väga spetsiifilist konfiguratsiooni, võite alustada mõne põhipildiga, installimata operatsioonisüsteemi, vajalikku tarkvara ja draivereid jne.

See ei ole uus kontseptsioon

Kui Hatoum selle kontseptsiooniga välja tuli, sai ta teada, et Zero-Bugi tarkvara idee pole uus. See on tegelikult eksisteerinud alates 1960. aastatest, nagu paljud unustatud vana kooli filosoofiad.

Legendaarne kvaliteediekspert Phillip Crosby leiutas termini Zero-Defect, töötades Martin Companys või praeguse nimega “Lockheed Martin”, kus teatati, et nad saavutasid “riistvara defektide vähenemise 54% valitsuse auditi käigus”.

Algselt kasutati nulldefekti tehnikat kosmosetööstuses 60ndatel ja seejärel 1990ndatel autotööstuses. Töötleva tööstuse ja tarkvara tarnimise vahel on palju sarnasusi.

Näiteks populaarne agiilne juhtimisviis Kanban sai alguse Toyota tootmissüsteemist. Põhimõtteliselt ütleb see meile, et saame hõlpsalt uurida neid tootmisprotsesse, et saada tarkvara või rakenduste arendamisel tehnilist inspiratsiooni, ja Zero-Bug on üks neist inspiratsiooniallikatest.

Standardi täitmise äärmuslik hind on aga üks suur kriitika nulldefekti lähenemisviisi suhtes. Ja kui seda rakendatakse valesti, võib see tõesti tõsi olla. Zero-Bug lähenemisviisi puhul on Hatoum selle probleemiga otseselt tegelenud, muutes vead funktsioonideks ja tehes olulisi täiustusi, võimaldades kulusid meeskonna kvaliteedistandardite kaudu kontrollida.

Alusta juba täna

Tehnikakasutajate ja -arendajatena võite hakata kõiki olemasolevaid tõrkeid läbi vaatama ja neid eelnimetatud süsteemi abil klassifitseerima. Kui arvate, et teil on sadu tuhandeid probleeme, võib olla õige aeg need maha jätta ja uuesti alustada. Ärge muretsege, saate alati vajadusel vead arhiivist praegusesse domeeni teisaldada.

Arendusmeeskond ei pea ilmtingimata ootama, kuni kogu klassifitseerimisharjutus on lõpetatud, enne kui nad hakkavad vigu ajama; nad saavad alustada kohe, kui mõned vead on klassifitseeritud. Meeskond ei tohi alustada tööd ühegi teise mahajäänud esemega enne, kui kõik üksused on vigadest vabastatud või ümber klassifitseeritud. Just see reegel sunnib tootejuhte uut tööd õigesti tähtsustama.

Kokkuvõtteks

Iga teatatud viga projektis nõuab parandamiseks lisaaega. Vigade jälgimine nõuab seetõttu vigu jälgivatelt isikutelt suurepäraseid suhtlemisoskusi ja nende parandajate tundlikkust. Eespool nimetatud jälgimishäkkide abil saab teie meeskond püüda olla produktiivsem, teatades samal ajal mis tahes tehnika- või turvatõkkest.