Hur ser ni på testning?

Vilken typ av testning pratar vi om? Det kan vara bra att snäva av området något. Bara mjukvaruprogram?

Jobbar som programmerare. Tycker det är väldigt användbart med tester, speciellt integrations- och system- tester men de är oftast väldigt komplicerade att skriva. Enhetstester får bli på affärskritiska funktioner.

Svaret från mig är att jag by default inte skriver tester till grejer.

Jag tror det beror väldigt mycket på inom vilket område det rör sig om. Man kan tycka att det testning borde vara högt på prio-listan men någonstans kompromissas det och i vissa branscher ofta kring testning har jag erfarit.
Men pysslar man med programmering inom områden som kan sluta med katastrofala följder finns inte alternativet "man gör hellre fula hack...". Senaste lärdomen är Boeings fuskande av tester som slutade i dödsolyckor. Även om det inte var enbart mjukvaruproblem så belyser det riskerna med hur fel det kan bli med kompromisser.

Några av de produkter jag varit inblandad i har ca 3-4 år av testande innan det släpps för skarpt bruk. Senaste produkten jag arbetat med har nu drygt 2 år av testande hos kund och fortfarande rättas mjukvaran och mekanik för att minska risken av personskador ute i fält.

Vi skriver integrationstester och enhetstester själv. Tyvärr hamnar de ibland efter om projektet har en pressad tidsram. Men jag tycker det är viktigt med automatiserade tester, speciellt för en applikation som kommer användas av kunder.

Speciellt då kod behöver refaktoreras, då vet man att man inte pajjar något kritiskt.

Det är väldigt viktigt med enhetstest och regressionstest. Om man inte skriver test tidigt kommer det bli mycket svårare att göra senare då man med stor sannolikhet har byggt in en massa beroenden.

Jag anser att test och god kodkvalitet går hand i hand. Om du skriver enhetstest före implementationen, eller åtminstone i samband med implementationen, kommer du upptäcka när du håller på att göra något dumt. Då kan du tidigt se att det börjar bli komplicerat att testa och kan avstyra direkt.

Känner att jag instämmer lite i kören här.

Beror på hur kritiskt det man gör är.
Integrationstester är mest användbart för att slippa dåliga releaser.
Enhetstester nästan enbart på riktigt central affärslogik, säkerhetsrelaterade grejer och buggar.

Som @MattiasFestin säger så bestämmer ju arkitektur och stil hur (automatiskt) testbart något är. Vill kunden ha testbart får kunden betala för det, annars får kunden sämre villkor för åtgärd av regressioner.

Man får inte glömma att otroligt mycket mjukvara som skrivs inte bär upp ett värde som motiverar den "perfektion" många utvecklare fokuserar så på. Finns det risk för liv, stora ekonomiska värden, informationssäkerhet - gå loss.

Men det mesta är ju bara massa bös. Om risken är att en avdelning med 5 administratörer står halvstill en halvdag 2-4 gånger om året kanske det är billigare än att låta tre konsulter rigga upp en full testsvit, eh?

Tycker det är lika viktigt oavsett om det "bara" är ett affärssystem kontra något mer kritiskt. Det handlar om förvaltningsbarhet och utökningsbarhet.

Tester hjälper till att säkerställa att koden är enkel att arbeta med och resonera kring. Kodbaser utan tester, eller med tester som skrivits i efterhand löper stor risk att ruttna. Det gör att eventuella buggfixar mer troligt bara lappar ihop just det problemet men skapar nya problem. Nya features tar längre och längre tid att implementera.

Det kanske kostar lite mer up-front men betalar av sig ganska snabbt.

Du pratar om det som om det går att bestämma en nivå i förväg, som om det fanns rätt eller fel i frågan.
Läser du tidigare inlägg så ser du att jag tycker det är fullt försvarbart om det riskeras liv/hälsa/värden större än arbetsinsatsen med att skriva det.

I ett kommersiellt projekt som ett bokningssystem så finns det ju en betalare. Är du kapabel att översätta risken/kostnaden man balanserar för betalaren så är det ju den som avgör.

Om ställer krav på 100% coverage eller liknande i ett bokningssystem så är du ju bara en affärsförstörare. Startup efter startup får slut på pengar för att någon skitnödig kille med masters i bloggläsning tror att det inte går att skriva dålig mjukvara om man bara bränner hela budgeten på tester (och microservices).

@noMad17 Jag förstår vart du vill komma i de första styckena, men jag håller med @jonasc i mycket av det han säger (om än tydligt att frustationen tränger igenom ) - det finns någon slags tro om att TDD och "bra testning" är en garant för bra lösningar, det är det inte. Det finns ingen testning i världen som hjälper mot dålig design, ologisk lösningar och ren idioti.

Det sista stycket vet jag inte vad du refererar till, men antar att det inte var en kommentar till mig?

Hur som helst: Jag har jobbat i/för både stora och små bolag, byggt mjukvarulösningar för slutkund, byggt testutrustning för produktionslinor osv, och det handlar hela tiden om värde kontra kostnad. Det finns liksom inget adderat värde i att spendera 4 manmånader på något om inte vinsten av det är >> än 4 manmånader, varesig det gäller tester eller något annat.

Den bästa tekniska lösningen är inte alltid den bästa lösningen på ett problem. Vad jag har landat i är just vad @jonasc nämner ovan; good enough är nästan alltid den bästa lösningen (men det kräver att man ser det från ett större perspektiv).

(Kan väl tilläggas också att ingen av oss skulle motsätta oss tester för medicinsk utrustning och liknande, men det är ju också det som är poängen; det är inte mycket som faktiskt är kritiskt. Inte ens buggar i produktionstestutrustningen spelar i det stora hela någon större roll: det finns alltid multipla uppsättningar.)

Jag, frustrerad? Av att försöka kombinera utvecklare med verkligheten i ett kommersiellt projekt? Aldrig!
Jag refererar till dig i fortsättningen, så går jag och lugnar mig på baksidan.

Det verkar finnas en viss frustration i denna tråden. Jag skulle vilja komma med några frågor.

Vilket ansvar har man som utvecklare för att man skriver fungerande kod? Och vems ansvar är det då att hitta felen i denna kod?
Allt för ofta så ser jag två läger. Ett gäng som utvecklar koden och ett annat gäng som testar den. Ofta klagar de sistnämnda på att de förstnämnda inte gör sitt jobb, och i många fall har de faktiskt rätt.

Jag tycker att den som skriver kod har ansvar för att den fungerar. Och hur ser man då till att den fungerar? Man använder de verktyg man har, dvs skriver kod.

Nästa fråga är då vad det innebär att koden fungerar? Jag har tex jobbat med e-handel. Jag skulle vilja säga att i e-handelsfallet fungerar koden om kunden kan välja ut ett valfritt antal varor betala för dem och få hem dem. Det behöver inte vara snyggt, det behöver inte vara lätt, bara det funkar. Människan har en unik förmåga att ta sig runt hinder. Det är inte skoj att behöva scrolla ner en sida för att hitta knappen, men vi brukar greja det. Djupare än så ska vi inte testa. Ju mer test vi skriver ju större risk att de ruttnar, är jobbiga att underhålla osv.
Nu kanske vårt koncept handlar om att vi har den bästa köpupplevelsen som går att få för pengar. Då är ju läget ett lite annat, men de flesta företag har inte det som koncept.

Man kan göra detta självreglerande. Om ett test hittar ett fel och vi kan tänka oss att bortse från det felet, släng testet. Ett fel som vi kan tänka oss att leva med är inte värt att testa.

Jag tar mig friheten att klippa ut några meningar som utgör själva kärnan i vad vi försöker förmedla.

Det gör jag alltid, men vad jag tycker är bra och vad kunden tycker är bra och värderar är inte alltid samma sak.

Du sätter huvudet på spiken här; Nej det är inte alltid lika mycket för dig och dina kollegors välbefinnande som att kunden ska få en bra produkt. Det beror på. Din stolthet är inget som kunden betalar för. Att du leverar 4 veckor senare för ditt eget bättre välbefinnande måste betala tillbaka sig i framtida tidsvinst.

Det finns givetvis projekt där arbete och utveckling sker kontinuerligt, där är det såklart viktigare att ha en stabil bas att stå på. I många fall ser verkligheten inte ut så i min erfarenhet.

Kunden bryr sig inte det minsta om snygg kod, kunden vill ha sitt problem löst. Back to basics, simpla smarta lösningar och good enough är det vinnande konceptet, IMO. Visst suger det att veta att "det hade kunnat vara mycket snyggare/bättre", men när man ställer det till sin spets så är det väldigt sällan det går att motivera.

Fast dålig kod kommer i slutändan att ge en dålig produkt. Om det tar längre och längre tid att implementera en ny feature eller fixa en bugg kommer det kosta kunden mer och mer pengar.

Visst, har du en produkt som inte kommer vidareutvecklas kanske det är mindre viktigt. I den agila världen skulle jag påstå att det är viktigt att koden är lättarbetad.

För mig är dålig kod och visuellt mindre snygg kod inte samma sak. Om man satsar på att hitta enkla, smarta och genomtänkta lösningar där koden gör det man har tänkt så är det inte dålig kod även om den är visuellt ful.

Jo precis, det beror på som jag skrev ovan. Det finns många aspekter att ta in, inte allt för sällan handlar det om deadlines när produkter _måste_ ut på marknaden för att hinna före konkurrenter eller hinna i tid till en mässa och liknande. Om vi får som vi vill och kan designa något "riktigt snyggt" rakt igenom så tar det nästan alltid betydligt längre tid än om man tar genvägar och gör en "good enough"-lösning. Ha då i åtanke att du måste vinna tillbaka tidsskillnaden i utvecklingstid för dessa nya features eller buggfixar. Det är inte ofta jag kan säga att det hade sparat varken tid eller pengar att göra den "perfekta" lösningen från början.

Det finns ju också ett spann mellan total katastrof och perfektion Jag skriver sällan min kod mer än en gång. "Den agila världen" ser nog lite annorlunda ut beroende på var man är någonstans som @jonasc var inne på tidigare. Ska man ranta lite så är det väl bara titta hur det ser ut högre upp (web/cloud osv), det är nya "rekommendationer" och hittepå var och varannan dag. Lika stabilt som bantningskurer i Aftonbladet.

Visst, man får ha i åtanke att vi drar saker till sin spets här. Det är klart att om ett företags primära produkt är en mjukvarulösning så finns det egenintresse i att hålla hög standard.

Så är det absolut.

Jag har mycket negativ bild av testning hur det utförs rent byråkratisk.

Jag har flera gånger fått skriva ut runt 30 sidor från excel där man för varje kolumn ska skriva sina Ok på 3 ställen, sina initialer och sedan årtal med dagens datum. Detta för det är superviktigt att precis allt är testat. Och att kund i efterhand ska kunna säga att exakt den grejen påstod du fungerade fungerar ej. Och att vi har anlitat ett annat företag som har granskat lösningen och de kom fram till att det aldrig har fungerat och det kommer nu bli en civilrättslig process med vite för skadan som har skett.

Iden med mycket manuell dokumentation är bra, men man blir rätt så slut att skriva all denna text manuellt hela tiden. Detta arbete med att manuellt skriva mycket text gör att man tappar koncentrationen och det lätt kan bli fel för bara detta.

Ett annat jobb och det ska dokumenteras på flera ställen att man har gjort något, det är så viktigt att det inte blir fel och om man skriver in exakt samma information om ett jobb på helt olika sätt på olika ställen så blir det bra testat eller?

Jag själv har börjat automattester för en sak, jag hittade fel som jag har gjort, men även som andra företag har gjort. Och detta är väldigt känsligt att upptäcka andras fel. För säg att jag hittar ett fel som kostar 500 000kr att åtgärda som ett annat företag har gjort. Och om jag mailar kund eller företaget om detta så får jag aggressivitet tillbaka från det företaget som får detta garantiärende.
Detta då det inte på något sätt är min uppgift att granska deras arbete, det är bara det att mina automattester hittar allas fel. Ett sätt är då att skita i detta och låta felen finnas och alla är nöjda och glada.
*edit*
Tur jag inte jobbar i bilbranschen. hitta ett fel och de får återkalla alla bilar i 10år kostar lite pengar. Men det hör mer till. Hos oss vanliga utvecklare så ska vi egentligen bara granska det som ingår i vårt arbete och berör det, inte köra automattester som kontrollerar annat.