Gå till innehåll

Månad: maj 2006

Publicerat den

Alla kan vi göra fel, eller inte riktigt orka ända fram eller helt enkelt så misslyckas något fast vi gjort allt vi kan. Det första jag tänker på är min egen bok. Det var ju inte så svårt att se att vissa av bilderna i boken är suddiga och knappt läsbara. Vad beror det nu på efter alla timmars korrekturläsning och granskning av experter. Vem är syndabocken? Att jag själv inte hade tillräckligt bra koll på hur bilder måste behandlas för att de ska se bra ut i en tryckt bok sa jag redan från början till min förläggare. det löser sig sa han, vi tar in ett proffs som sätter boken. Hon kommer att säga till om dina bilder inte duger, trodde han ja! Antingen visste hon inte vad som dög eller så visste hon inte att hon skulle berätta det för mig eller så antog hon att det hon fick var det slutliga som inte gick att ändra. Resultatet blev följande:

1- Jag skapade bilderna i Visio eller Powerpoint och sparade dem sen som GIF eller JPG på ett som jag tyckte likvärdigt sätt - uppenbarligen inte tillräckligt bra i vissa fall, men helt OK i andra - märkligt!

2 - Dessa bilder fanns i början i ett Worddokument som jag tyckte såg helt OK ut vid utskrift

3 - Nästa steg var att all text separerades från bilderna och boken sattes i ett speciellt redigeringsprogram.

4 - Vid sättningen försvann tabellformat, rubriknumrering, fotnoter, innehållsförteckning, figurtexter, index och annat kul autoformatterat.

5 - Resultatet blev ett antal granskningar innan alla dessa detaljer var på plats. Gransknngen skedde på en PDF-version där jag fick uttryckliga instruktioner om att bildkvaliteten i pdf-filen var lägre än den slutliga så bilderna uppfattade jag att jag skulle strunta i

6. Slutligen då, en dag före tryckning, meddelar tryckeriet att vissa bilder - inga specifika nämnda utom ett par som byttes ut - hade för låg kvalitet och skulle bli dåliga. Hmm, lite väl sent att göra om allting då.

Slutsats: Tråkigt men sant, jag tyckte att jag gjort vad jag kunde. Vad tänker jag på inför nästa gång, nästa version? Ja då plockar vi in ett nytt proffs men den här gången träffas vi och kommer överens om vad vi förväntar oss av varandra. Så att jag vet vad som krävs av mig och han vet vad vi vill ha. Sen kräver jag att få en slutlig version att granska som är av samma kvalitet som det slutliga trycket. Om det lyckas bättre då, det får vi hoppas. Hade inte förstått alla komplikationer det innebar att ge ut en bok. Vem syndabocken är spelar mindre roll, det är jag som får lida för det och ni som irriterar er på de (som tur är ganska få) - bilder som inte är av perfekt kvalitet.

Publicerat den

Först och främst gillar jag inte beteckningen icke-funktionell. Vadå icke-funktionell, vad är det som inte fungerar? prestanda och säkerhet är det icke-funktioner? Att man måste logga in, att man bara kan se vissa delar av ett system eller vissa delar av databasen är typiska behörighetsfrågor som jag räknar till "säkerhet". Är det icke-funktioner? Jag har läst en del försök till alternativa benämningar: kvalitetsfaktorer/egenskaper(inte så illa), para-funktionella delar(hmm, paralyserad, para-normal(utanför det normala enl SAOL), paraply..nja kanske inte), supplementary requirements (RUP) "kompletterande krav" - kompletterande till vadå? Jag fastnar nog för kvalitetskrav - det säger mest. Nån annan som har ett bättre förslag?

Och nu till frågan varför det är så svårt att testa dessa krav. Det första som slår mig är att det är för att de sällan eller aldrig finns nerskrivna. Om det nu skulle finnas något på pränt så är det oftast otillräckligt, tvetydigt, motsägesefullt eller kanske en blandning av allt ihop. Så vi får börja med att ta fram kraven genom att intervjua de olika intressenterna, som inte heller de vet vad de vill ha eller hur de ska fråga efter det de tycker om. Läste precis i boken "Exploring Requirements" (rekommenderas varmt - finns på bla Adlibris.se) att vårt mål är att ge kunden vad de behöver inte vad de tror att de vill ha - då blir de mest nöjda. Intressant vinkling på problemet. Lyssnade på en lysande föreläsning av Andreas Granqvist om tillgänglighet på NFI Testforum. han spetsade till det genom att påpeka att användares beteende kan studeras som man gör med djur men räkna inte med att få nåt vettigt ut av dem vad gäller vad de vill ha.

Säg att vi nu skulle ha riktigt bra krav nedskrivna, hur bra skulle vi då kunna testa dem? Svaret blir nog att vi som icke-specialister inte skulle göra ett specielt bra jobb. Om vi tar exempelvis användbarhet, visst kan vi med hjälp av diverse checklistor kolla att knappar och texter stämmer med standard men användbarheten i sig - det blir nog mest våra egna åsikter om vad vi tycker är bra snarare än vad som är rätt eller fel. Och vad är våra åsikter som amatörer värde mot designproffsen som byggt systemet, nej det går inte. Här behöver vi specialister och kanske ett användbarhetslabb. Kolla in FunkaNu Säkerhet, prestanda eller robusthet då? Då krävs det verktyg, teknisk kunskap och säkerligen en bättre testmiljö än den vi testar på just nu. Vad ska vi då göra? Nu spånar jag fritt, har inte gjort någon djupare analys men tänkt en hel del.

1. Steg ett är att vi måste veta vad vi behöver för krav på kvalitetsfaktorerna. Vilket underlag krävs i vårt projekt? Jag kan tänka mig en prioriteringslista där beställaren säger att tex prestanda är viktigt men säkerhet inte är lika viktigt. Sen får de då beskriva vad de menar med prestanda: Det ska inte uppfattas som långsamt för en normalkund att öppna förstasidan på vår websajt. Definiera normalkund, PC-typ, uppkoppling, under vilka förhållanden - högtrafik, normal...Långsamt : typ mer än tre sekunder. Även om vi inte kan få exakta svar kan vi om vi skriver kraven i dess sammanhang med syfte och mål få en bra bild. Det är dock tveksamt om vi som testare ska ta fram kraven, då överskrider vi våra arbetsuppgifter. Men visst händer det att vi gör så, eller hur?

2. Steg två är att utifrån kraven kunna göra en bedömning om det är något vi kan hantera själv, om vi behöver mer information, om vi behöver viss miljö, eller om vi ska kalla in experter - eller rättare sagt meddela projektledaren att vi rekommenderar att man tar in experter. Ska dessa då både ta fram kraven och sen testa dem? Det är väl oftast det som sker. Är det bra då?

3. Steg tre är att vi eller specialisterna utför tester och rapporterar resultatet. När det gäller prestandatester sker det ofta en "tuning" under testerna så att systemet uppnår den prestanda som begärts. Redan här inser jag mina begränsingar och skulle aldrig ta på mig ansvaret för att utföra prestandatesterna i ett projekt.

Har letat med ljus och lykta efter böcker, artiklar om detta och hittat vissa delar om prestanda och användbarhet. Kanske dags att skriva en bok till tillsammans med de bästa inom varja område. Finns det någon som har en riktigt bra mall för "icke-funktionella2 krav. Skicka den gärna till mig på torbjorn at ryber.se

//Tobbe

Publicerat den

Nya styrelsen hade sitt första möte ikväll och delade ut ansvar till nya och gamla styrelsemedlemar. Intresset att delta i styrelsen var större än någonsin och vi fick utöka antalet medlemmar på projektplasen för att skulle få vara med. Vårt möte rullade på i bra takt och mycket är rutin för oss gamlingar. Det blev mer intressant efter mötets slut. Vår trogne matansvarige Pablo hade med sikte på stjärnorna bokat in styrelsemiddag på Kaknästornet. Vår taxichaffis hade problem att hitta dit vilket föranledde kommentarer som att det gick att se från flera kilometers håll. Men det är klart att det är svårt att hitta till alla udda mindre kända ställen i stan...speciellt om man bara har har en GPS i bilen.

Nåja, redan efter det första glaset vin och Toast Skagen började idéerna flöda. Allt från dansbandskväll till lära känna varandra träff föreslogs. Att starta dagen med champagnefrukost antogs öka viljan att nätverka. Förslag på pub efter mötet mottgs med viss skepsis av gamlingarna då vi försökt men våra kära medlemmar försvinner så fort gratisölet är slut. Motattacken var att skrapa ihop tillräcklig med stålar så att hela kvällen har fri bar. Kort sagt - vi gör allt för att ni alla ska börja prata med varandra! På riktigt alltså, helst utan att blanda in alkohol som fördunklar sinnet! Kanske ska vi ha grupparbeten eller minisessioner i framtiden? Är ni trötta på föreläsningar, ni säger inget! Som tur var kunde Jörgen inte hålla tyst utan föreslog en ny enkät till SAST-medlemmarna. Något som han raskt fick ansvaret för att genomföra.

Speciellt kul att få mothugg under diskussionerna. Jag ser fram emot ett nytt år med nya fräscha idéer från våra nya katalysatorer. Sen hoppas jag att flera av dem börjar kommentera mina bloggar så att jag inte skriver utan bollplank.

PÃ¥ grund av halsinfektion och penicillinkur valde jag att inte följa med pÃ¥ Winjas ikväll vilket möjligen lede till ytterligare ett samtalsämne, men det bjuder jag pÃ¥ 😉

Hälsar SAST-Ordföranden
Torbjörn - Styrelse och medlemmar

Publicerat den

Acceptanskriterier och acceptanstestkriterier - vi reder ut begreppen
Fick en fråga på mejlen om vad som skiljer de båda begreppen åt och känner igen frågeställningen från egna projekt. Det verkar finnas en stor osäkerhet om vem som ansvarar för att godkänna leverans av en beställd produkt. Något jag tycker är lite märkligt. Jag har en egen uppfattning om vad som gäller, men kan inte på rak arm berätta om något ställe man kan hitta mer information på. det finns säkert men jag har inte tid att leta just nu. Kanske någon av de som läser bloggen har tips?

Min egen uppfattning är att vi som testare har som uppgift att genom vårt arbete ta fram så mycket information som möjligt om det vi testar. Denna information presenterar vi sedan till projekt eller liknande eventuellt med vår åsikt om hur det ska tolkas. var försiktig med rekommendationer då du kan få skulden om något inte fungerar som det ska. Testerna bygger ju på det VI vet och vi vet sällan allt. Ofta får jag som testledare frågan - rekommenderar du produktionssätning. Jag försöker då beskriva att det enda jag vet är hur bra mina egna tester har gått och vilka öppna fel som finns kvar. beslut om produktionssättning är däremot ett AFFÄRSBESLUT. Det behöver inte alls bygga på hur testerna har gått utan kan ha helt andra kriterier. Nya modeller/versioner av exempelvis telefoner och websajter produktionssätts ofta med ganska mycket kvarvarande fel och bristade tester då det viktigaste inte är att ha noll fel utan att vara först ute på marknaden.

Acceptanstestkriterierna är det vi i testgruppen sätter upp för oss själva för att säga att - "Nu är vi färdiga med testerna till den grad att vi kan ge er en bra bild av situationen" Det är altså vårt interna arbetssätt som de gäller. På samma sätt kan vi ha kriterier för de andra nivåerna som system och integrationstest, dessa kriterier ansvarar testledaren för.

Acceptanskriterierna är det som en beställare sätter upp för att godkänna att de fått levererat vad som beställts. Det är ofta en del av eller en bilaga ett skrivet kontrakt. Dessa ska tas fram av den som beställer och som ska godkänna leveransen. Sen kan det mycket väl vara så att godkännandet i praktiken innebär att vi utför en acceptanstest och resultatet från denna ligger till grund för acceptans av leveransen.

Men det är viktigt att skilja mellan testarnas roll och beställaren/mottagarens roll. Vi måste lära beställaren att ta sitt ansvar! Har skrivit mer om detta i min bok "testdesign för programvara". (kap 5 angreppssätt och kap 24 när är vi klara med testerna.)

//Tobbe

Publicerat den

Jag fick i förra veckan förmånen att delta på ett seminarie med testgurun James Bach anordnat av ENEA. Som vanligt körde han hårt med publiken och ifrågasatte det mesta. Grundtanken är att vi inte ska tro på allt som sägs utan kritiskt ifrågasätta och försöka förstå innebörden. Han tar upp "gamla sanningar" och dissekerar dem så att deltagarna själva kan ha möjlighet att ta ställning till vad som är rätt och fel. Han är en man med starka åsikter och ett väldigt direkt sätt att uttrycka dem. Detta har gjort att många gamlingar i tesbranschen har reagerat med att totalt såga hans tankar om exempelvis utforskande testning. Själv anser jag honom som en lysande talare och en man med stor integritet. Det är av James och hans kollegor i "The context-driven school" jag lärt mig det lilla extra inom test. Jag håller med om att väldigt många testböcker fokuserar mest på procedurer och dokument och innehåller väldigt lite information om vad test egentligen innebär. det finns en drös böcker som handlöar om testning i allmänhet men endast ett fåtal om testdesign som jag anser är kärnan i bra testarbete. Förutom Lee Copelands bok "Test design for the practitioner" finns det ytterst lite skrivet. Jag har försökt ta mig igenom Boris Beizers "Black-Box testing Techniques" men gett upp flera gånger då boken är fruktansvärt omständig och känns mer som en historiebok över test än en en handbok för ambtiösa testare. Kolla in Boktips för fler bokrecensioner. Det är sällan man träffar en så engagerad och intressant person som James att prata med. Jag fick nöjet av att på tu man hand ta med honom på Edsbackas Bistro och njuta av deras svenska specialiteter. Han hoppas att de idéer han har kan spridas i Sverige och jag har lovat att göra mitt bästa för att missionera om test med inspiration från hans många alster. Jag rekommenderar verkligen ett besök på www.satisfice.com. Och du, vill du gå en riktigt bra kurs inom test - kolla på ENEAs kursprogram för nästa kurs.

//Torbjörn