Gå till innehåll

Författare: Anders Sandström

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

Publicerat den

Med stor spänning sprättade jag upp den första bruna papplådan från tryckeriet i Borgå. Finnarna höll sitt löfte och skickade en extra sänding nytryckta böcker direkt till Bonnier konferensavdelning i god tid till SASTs kvartalsmöte. Det kändes både underbart och lite overkligt att äntligen hålla ett exemplar av boken "testdesign för programvara" i handen. Det hann bli många kvällar och helger framför datorn med oändliga korrekturläsningar, omstruktureringar och rättningar. Jag har haft förmånen att ha en granskningsgrupp med bra variation som gett mig konstruktiva kommentarer och del huvudbry. Ett stort tack till hela gänget, utan er hade det inte blivit så bra som jag tycker det blev.

Boken

För ovanlighetens skull fick jag stå på scenen och prata om test istället för att presentera andra talare. Ämnet var kanske inte helt oväntat testdesign. Jag ifrågasätter hur vi arbetar och om våra kunskaper om test verkligen är tillräckliga. Även om vi är duktiga finns det stora möjligheter att bli ännu bättre. Första steget är att lära sig mer om testdesign det andra är att ändra attityd och bli mer analyserande istället för att klaga över dåliga underlag. Jag säger inte att vi testare ska ansvara för att ta fram kraven men vi kan med analys och frågor hjälpa till att höja kvaliteten tidigt i projektet.

Boken fick ett varmt mottagande och inte mindre än 70 böcker såldes under dagen. Pablo på SolutionPoint slog till och köpte 20 böcker att delas ut till samtliga anställda plus plus ett par i reserv. Självklart hoppas den nyblivne författaren att fler följer hans exempel. Beställ idag på www.uppkopplat.se/butik

Dagen avslutades med ett besök i isbaren för att underhålla vår gäst Andy Redwood som ställde upp och talade utan avgift. Vi fortsatte sen till Winjas där vi festade loss på ost och charktallrik i sällskap med några spanska viner från Pablos eget förråd.

/Tobbe