Finns det något som en bug-free-applikation? [duplicera]

Det närmaste du kommer till en felfri applikation, dyrare blir det. Det är som att rikta in 100% kodtäckning: du spenderar lika mycket tid och pengar på att få från 0% till 95%, från 95% till 99% och från 99% till 99,9%.

Behöver du dessa extra 0,1% av kodtäckningen eller kvaliteten? Förmodligen ja, om du arbetar med en mjukvaruprodukt som styr kylsystemet i en kärnreaktor. Förmodligen inte om du jobbar med en affärsapplikation.

För att skapa mjukvara av hög kvalitet krävs ett helt annat tillvägagångssätt . Du kan inte bara be ett team av utvecklare som tillbringade sitt liv med att skriva affärsappar att skapa en nästan buggfri applikation. Högkvalitativ programvara kräver olika tekniker, såsom formellt bevis , något som du verkligen inte vill använda i en affärsapp på grund av den extremt höga kostnaden det representerar.

Som jag förklarade i en av mina artiklar :

• Affärsappar bör inte rikta in sig på den kvalitet som krävs för livskritisk programvara, för om de här affärsapparna misslyckas då och då, gör det bara inte ” Det spelar ingen roll. Jag har sett fel och stillestånd på webbplatser för förmodligen alla stora företag, Amazon är det enda undantaget. Den här stilleståndstiden och dessa buggar är irriterande och kanske kostar företaget några tusentals dollar per månad, men det skulle vara mycket dyrare att fixa det.

• Kostnaden bör vara det primära fokuset, och bör studeras pragmatiskt. Låt oss föreställa oss ett fel som påverkar 5 000 kunder och är så viktigt att dessa kunder kommer att lämna för alltid. Är det viktigt? Ja? Tänk mer. Vad händer om jag säger att var och en av dessa kunder betalar 10 dollar per år och att det kommer att kostar nästan 100 000 $ för att åtgärda felet? Bug fixing ser nu mycket mindre intressant ut.

Nu för att svara på dina frågor specifikt:

varför rapporteras buggar även efter att ha testats så mycket? Är det våra krav? Vår klient verkar inte vara nöjd med något vi tillhandahåller? gör vi något felaktigt?

Många saker kan gå fel. Med testning menar du egentligen automatiserad testning? Om inte, är detta ett stort problem i sig. Förstår testare kraven? Kommunicerar du med kunden regelbundet – åtminstone en gång per iteration, i bästa fall kundrepresentanten kan omedelbart nås på plats av alla medlemmar i ditt team ? Är dina iterationer tillräckligt korta? Testar utvecklare sin egen kod?

På samma sätt som De skriver rätt saker artikeln som länkas ovan, tar en felrapport och studerar varför detta fel uppträdde i första hand och varför missades det av varje testare . Detta kan ge dig några idéer om luckorna i ditt lags process.

Det är viktigt att tänka på: betalar din kund för felkorrigeringar? vara ett fel. Att få honom att betala för den tid du spenderar på buggar kommer då att minska antalet felrapporter avsevärt.

Har någon utvecklat något program som var helt felfritt? Vad är processen? Varför kan vi inte distribuera applikationen med mindre buggar? Ska vi vara perfektionistiska?

Jag. Jag har skrivit en app för mig själv förra helgen och har inte hittat något fel hittills.

Fel är bara fel när de rapporteras. Så i teorin är det helt möjligt att ha en bug-free-applikation: om den inte används av någon kommer det inte att finnas någon att rapportera buggar.

Skriv nu en storskalig applikation som perfekt matchar specifikation och har visat sig vara korrekt (se formellt bevis som nämns ovan) är en annan historia. Om detta är ett livskritiskt projekt bör detta vara ditt mål (vilket inte betyder din ansökan kommer att vara felfri).

Är det aktuella scenariot rätt process för utveckling och testning? Om inte vad är ett effektivt sätt där utvecklare, testare och klienter får maximal nytta tillsammans?

1. För att förstå varandra , de borde kommunicera. Det här är inte vad som händer i de flesta företag jag har sett. I de flesta företag är projektledare den enda som pratar med kunden (ibland med en representant).Sedan delar han (ibland delvis) sin förståelse av kraven med utvecklare, interaktionsdesigners, arkitekter, DBA och testare.

   Det är därför det är viktigt antingen för kunden (eller kundens representant) att kunna nås av alla i teamet (Agile approach) eller ha formella kommunikationsmedel som bemyndigar en person att bara kommunicera med några andra personer i ett team och att göra det på ett sätt som informationen kan delas med hela teamet, se till att alla har samma information.

2. Det finns många processer att göra utveckling och testning. Utan att veta exakt företaget och teamet finns det inget sätt att avgöra vilken som ska tillämpas i ditt fall. Överväg att anställa en konsult eller anställa en projektledare som är skicklig nog.

Kommentarer

• +1. Innan du ens startar ett projekt måste du ha en förståelse för vad som är " tillräckligt bra för att släppas " och bygg därefter.
• @JuliaHayward Kunde inte ' inte håller med mer. Slutspelet här är inte ' t nollfel – det producerar funktionell programvara som lägger till värde i rätt tid.

Inte alla buggar är lika, så du måste sortera vete från agnet.

Förväntningar

Många buggar tas upp helt enkelt på grund av en brist på vad programvaran gör och vad slutanvändaren förväntar sig. Denna förväntan kommer från många områden: använder annan programvara, felaktig dokumentation, alltför nitisk säljpersonal, hur programvaran brukade fungera etc. etc.

Räckviddskrypning

Det säger sig självt att ju mer du levererar, desto större är potentialen för buggar. Många buggar höjs helt enkelt på baksidan av nya funktioner. Du levererar X & Y men kunden säger att på baksidan av detta ska det nu också göra Z.

Förstå problemdomänen

Många buggar uppstår av den enkla anledningen att problemdomänen var dåligt förstådd. Varje kund har sina egna affärsregler, jargong och sätt att göra saker på. Mycket av detta kommer inte att dokumenteras var som helst – det kommer bara att ligga i människors huvuden. Med den bästa viljan i världen kan du inte hoppas att fånga allt detta i ett steg.

Så … vad ska jag göra åt det?

Automatiserade enhetstester

Många buggar introduceras som en oväntad bieffekt av någon kodändring eller annat. Om du har automatiserade enhetstester, kan du avhjälpa många av dessa problem och producera bättre kod från början.

Testerna är bara lika bra som de levererade uppgifterna – så se till att du förstår problemdomänen fullt ut.

Kodtäckning

Detta går hand i hand med automatiserad enhetstestning. se till att så mycket kod testas som praktiskt.

Lär dig lektionerna

Galenskap gör samma sak om och om igen och igen och förväntar sig olika resultat

Förstår du orsakerna till det senaste misslyckandet? Gör du? Verkligen? Du kanske har slutat problemet förekommer men vad var den verkliga rotkällan? Dåliga data? Användarfel? Diskkorruption? Nätverksavbrott?

Ingenting irriterar klienter mer än att stöta på samma problem om och om igen utan framsteg mot någon form av upplösning.

Beror på vad du kallar en applikation.

Om du menar, ett interaktivt program där du måste vara säker på att realtidsbeteendet är exakt sådant och sådant under alla omständigheter, så är det i princip omöjligt att bevisa att det inte finns några buggar i det. Jag antar att det skulle vara möjligt om du kunde lösa stoppproblemet , men du kan inte ”t.

Men om du begränsar dig till ett uttalande om ”sådan och sådan inmatning kommer så småningom att ge ett sådant slutligt tillstånd”, då är dina chanser för ett ”bug-free proof” bättre, eftersom du kan använda invariants . Detta, och bara det, gör det möjligt att bryta ner korrekthetssäkerhet i delproblem, var och en kan relativt enkelt bevisas att fungera korrekt under alla omständigheter av det återstående programmet (även om du i allmänhet inte kan vara mycket exakt om hur mycket tid & minne det kan ta).

Sådana tekniker är i princip möjliga i alla programmeringsspråk (även om vissa esoteriska som Malbolge försöker motbevisa det !), men på alla tvingande språk blir det rörigt mycket snabbt, eftersom du måste noggrant hålla reda på en hel del implicit programtillstånd. På funktionella språk ¹ tenderar bevisen att se mycket trevligare ut ( rena språk , eller den rent funktionella delmängden av ett språk). I synnerhet, särskilt med dynamiska typer, måste du skriva ut många krav på vilka ingångar som är tillåtna. Det är naturligtvis en av de största fördelarna med starka system med statisk typ: kraven finns precis där i koden!
Tja, helst, det vill säga. I praktiken tenderar O ”Caml- eller till och med Haskell-program att innehålla icke-totala funktioner , dvs funktioner som kommer att krascha / hänga / kasta för vissa ingångar, trots rätt typ ² . För även om dessa språk har mycket flexibla system är det ibland inte möjligt att använda det för att helt begränsa något.

Ange beroende språk ! Dessa kan ”beräkna” typer exakt efter behov, så allt du definierar kan ha exakt den typsignatur som förespråkar allt du behöver. Och i själva verket lärs beroende språk skrivs mest ut som bevisa miljöer em Tyvärr tror jag att ingen av dem verkligen är upp till att skriva produktionsprogramvara. För praktiska tillämpningar tror jag att det närmaste du kan komma till helt bug-proof är att skriva i Haskell med så grundligt totala funktioner som möjligt. Det får dig ganska nära bug-proof – om än, bara med avseende på den funktionella beskrivningen. ”s unika sätt att hantera IO med monader ger också några mycket användbara bevis, men det berättar i allmänhet inte något om hur lång tid det tar att Avsluta. Troligtvis kan något ta exponentiell tid under särskilda omständigheter – från användarens POV, vilket sannolikt skulle vara lika allvarligt som om programmet helt hänger.