Gå till innehåll

Blogg

Publicerat den

Läste precis föreläsningsmaterial och en artikel av Lloyd Roden där han går igenom tekniken parvis testing. Principen är att de fel som finns vanligen är enkla fel - dvs ett visst värde på en viss parameter ger ett fel oavsett värdena på övriga variabler, eller duala där en kombination av två värden för två olika variabler i kombination gör att felet uppträder. Fel som kräver fler kombinationer är betydligt förre och att testa alla kombinationer av värden för alla variabler är sällan möjligt. 

Som många andra, ex Lee Copeland, ägnar han stor möda åt att förklara fenomenet ortogonala arrayer och hur dessa kan användas för att lösa problemen. O Arrayer är matematiska och manuellt framtagna och har egenskapen att de innehåller alla par av värden för vilka två kolumner som helst dvs i vårt falla för alla variabler och alla värden, jag ska inte förklara detta närmare här. Läs artikeln om du vill veta mer. problemet som jag ser det är att det finns en mängd begränsingar med arrayerna och det finns inga (?) bevisade fördelar med den ena eller andra metoden vad gäller felupptäckning för mjukvara. Däremot finns ett exempel för hårdvara 

The index is important when you want to make sure not only that each combination is tested, but that each combination is tested the same number of times. That's important in manufacturing and product safety tests, because it allows us to account for wear or friction between components. When we test combinations of components using orthogonal arrays, we find not only which combination of components will break, but also which combination will break first.  Michael Bolton

 Det Lloydutelämnar i artikeln är alla de fördelar som finns med ett verktyg som ex PICT nämligen följande:

a) det går att ha variabel täckning för olika variabler dvs du kan ha enkel täckning för vissa, parvis för andra och ännu högre för resten. Med andra ord högre risk - bättre täckning! Ortogonala arrayer för högre kombinationer är mycket stora och svåra att hantera.

b) det går att lägga in begränsingar för vissa kombinationer av variabler vilket är praktiskt då det ofta finns kombinationer som ej är tillåtna

c) det går att markera vissa värden som ogiltiga vilket gör att verktyget endast har med ett ogiltigt värde i varje testfall. detta är rekommendationen att ha då annars ett felaktigt värde kan hindra att nästa felaktiga vrde testas - dvs felhantering gör att vi hoppar ur loopen innan värdet avläses

d) när, inte OM men NÄR, du kommer på att det finns fler värden för en viss variabel. Då är det bara att lägga in de nya värdena och köra om filen. Använder du en array så är risken stor att du måste leta upp en ny vilket är tidsödande.

e) eftersom det inte finns arrayer för alla kombinationer av parameterantal och värden så är risken större att det blir fler testfall med arrayerna. Självklart finns det exempel på fall där motsaten gäller då du lyclas hitta en perfekt array för dina variabler.

Jag har diskuterat arrayer med Mats Grindal på ENEA som skrivit en doktorsavhandling i ämnet och med Peter Zimmerer som hade en tutorial på EuroSTAR förra veckan. Deras svar är entydliga - använd verktyg! 

Någon som har en avvikande mening är välkommen att argumentera för den här.

Publicerat den

Med jämna mellanrum dyker det upp nya utvecklingsmetoder. De senaste jag känner till är Unified Process och Agile. Det är därför något förvånande att utvecklingen inom test verkar stå relativt stilla. Vi har standarder som IEEE-829 som har 24 år på nacken och numera ISTQB-syllabus som bygger på IEEE 829 och redan när den kommer ut känns gammaldags. Medan utvecklarna och kravskrivarna fokuserar på att dokumentera allt mindre så fortsätter test att köra i samma gamla hjulspår. Jag brukar fråga de som har gått ISTQB-foundation kursen och certifierat sig om de har någon nytta av det de lärt sig. Svaret blir att tentan är mest ordförståelse men att kursen i sig var delvis intressant. Frågan är då om det är bra att gå en grundkurs eller om det är skadligt att bli itutad att det här är det som gäller? Det jag själv blir mest trött på är att det är så svårt att försöka få andra att börja fundera i mer kreativa banor som att använda utforskande testning eller testverktyg på annat sätt än plug-and-play som bevisligen misslyckats betydligt oftare än det lyckats. Vi borde ju använda det som fungerar bäst istället för det någon annan säger till oss att göra. Jag är inte alls säker på att en certifiering är ett bra sätt att höja statusen på testarna. Mitt råd till alla er är att fundera på : Är det jag gör nu effektivt? Vad kan jag göra för att det ska bli bättre? Är det roligt att följa detaljerade instruktioner eller att jobba mer kreativt? Är det ibland betydligt mer effektivt att testa friare än att bestämma allt i förväg? Hela iden bakom agile är ju att vi inte vet allt från början. Lägger vi alldeles för mycket tid på att producera text då vi istället kunde köra tester eller analysera krav? Utan att ifrågasätta kommer vi inte framåt. Bli en testrebell!

Det pågår en diskussion på Yahoo om den nya versionen av standard IEEE 829.  Här ett par inlägg av Cem Kaner: Citat

"My own opinion of the latest revision is strongly negative. I think that 829 has encouraged people, for 24 years, to overdocument their projects and that this problem could and should be mitigated by guidance within the standard on some of the tradeoffs / decisions that might be made if we were willing to consider the project's context.

I am also unaware of any empirical evidence that following this standard does improve quality or project success. For a standard that has been around since 1983, with the number of people who teach it as a best practice, I think the time is well overdue for scientifically sound demonstration of value (to the extent that it exists) that Standard 829 actually provides substantial enough value to  justify adoption as a standard engineering practice."

"What failed to get into the standard is the idea of context. It is important to tailor what you do to the circumstances. A document that is good for one situation is a waste of effort for another and should be substantially modified for a third. What failed to get more than lipservice was the idea that we spend a fortune on test documentation and so we should think carefully about requirements for that documentation, spending the minimum needed to satisfy the needs of the project. Somehow, it seems that software engineering standards should take seriously the idea that it is good to have requirements in mind when you design, budget and execute a significantly expensive task. This document fails utterly to provide guidance for doing the requirements analysis.

We still have a document that pushes the notion that the bigger the bloat in paperwork, the better. We still have a document that claims to present an engineering standard that cannot (or at least does not) reference any scientific studies, after 24 years, that heavyweight test documentation does less harm than good. Or even--not much more harm than good. We have a document that demands more bloat for safety-critical systems (the only context mentioned is that critical systems need to max out on the bloat) but without evidence that max bloat improves rather than detracts from safety.

It is one thing to deal with a standard in place and say, drat, this has done a lot of harm, and is the excuse for a huge zone of braindeadness in testing education, but it's what it is. It is a different thing entirely to say, gosh, this is what we should embrace going forward. Let's use this opportunity to reaffirm the status quo.

In practical terms, we have a document that:

1.      pushes to maximize the income to consulting firms and outsourcers for low-skill clerical work while minimizing the time left for actually assessing the quality of the product.

2.      simplifies the documentation-related judgments in ways that will make teaching easy, mainly because no one will have to do any critical thinking as part of the teaching or the (I hate to call it) learning

If testing is about critical thinking, why shoot ourselves in the head?"

-- Cem Kaner

 

  

Publicerat den

Vi som läser hans blogg regelbundet har sedan ett par veckor tillbaka sett att James på grund av personliga skäl väljer att inte resa mer i år. Hade sett fram mot att lyssna på hans inledande keynote mot certifiering och att engagera mig i diskussioner med vår guru. Har inte sett någon information om detta på EuroSTAR-sidan förutom att de diskret tagit bort hans tutorial. Det ska bli spännande att lyssna på Michael Bolton leverera samma salva då han och James jobbar mycket ihop. Modigt och roligt ändå av Stuart Reid - vår certifierings och standards guru att bjuda in en person med så starka ståndpunkter mot det han själv arbetar med nämligen ISTQB och IEEE. Har själv insett att IEEE inte vill att vi vanliga människor ska kunna komma åt deras alster utan att betala en rejäl slant. En sann standard borde ju vara öppen för alla att komma åt. Dessutom måste man köpa loss deras artiklar för att få läsa dem till hutlösa priser. Tittade på vad det skulle kosta att ladda hem lite olika forskningsartiklar från våra svenska testdoktorer - det var nästan lka dyrt att ladda hem en enda artikel som att köpa en bok! Ja inte riktigt men det lät bra att säga det. 19 dollar för en artikel är ju rena rama rånet! Mycket tråkigt eftersom det är här de flesta stora forskare publicerar sina alster. Snacka om att hindra informationsspridningen!

Publicerat den

Jaha, då var det klart nu. Till jul flyttar vi till Närkeslättens metropol Örebro. Lite sorgligt att flytta från arbetskamrater och vänner i storstan. Inte minst alla intressanta testentusiaster jag träffar mer eller mindre regelbundet. Inser att jag inte känner en enda testare i Örebro - ännu! Kanske är det dags att starta upp SAST Mälardalen med Örebro, Västerås och Eskilstuna i fokus? Målet är förstås att fortsätta mitt arbete som egen konsult och jag letar därför efter intressanta uppdrag främst i Örebro med omnejd. Någon som känner till eller själv behöver en resurs som kan arbeta med testledning, företagsstrategi inom test, testdesign eller utbildning och föreläsningar? Hör av er till mig.

Finns det testare i Örebro, är ni organiserade, vill ni vara med i ett kompetensutvecklingsnätverk? Något kul måste vi väl ändå hitta på.

Eftersom jag efter 12 Ã¥r i Stockholm fortfarande har kvar min smÃ¥ländska dialekt kommer jag att arbeta hÃ¥rt pÃ¥ att inte ryckas med av Peter Flack o co. 🙂

Publicerat den

Det viktigaste med en Peer Conference är ju själva förkortningen! Denna gång var temat SBTM - Session Based Test Management mer exakt Exploratory Testing med användning av Charters. Jag bjöd in Herman Afzelius och Petter Mattsson från UIQ som på otroligt kort tid med framgång infört arbetssättet för sina testingenjörer. Deras uppgift är att på kort tid ta hand om nya versioner av Symbian OS som används i SonyEricssons telefoner. De har en situation där kraven ändras mycket snabbt och testcyklerna är väldigt korta, ett par veckor är den tid de har att spela på. Det ursprungliga sättet att arbeta på innebar att testarna körde stora mängder av detaljbeskrivna testfall mer eller mindre mekaniskt. Detta upplevdes som tråkigt och ineffektivt av de flesta. Det nya sättet att arbeta på innebör att ett antal övergripande beskrivningar i form av test-charters har tagits fram och testarna väljer nästa charter slumpmässigt. Ett exempel är att testa SMS-funktionaliteten. Den enda instruktion som finns är att testa SMS skicka, ta emot, forward, kopplade stora meddelanden etc. Resten är upp till testarna.

Reflektionerna på det gamla sättet att arbeta var att 90% passed test cases gav en falsk känsla av trygghet då det egentligen inte sade så mycket. Ungefär som att vi resenärer tvingas kasta vattenflaskorna i säkerhetskontrollen på flyget och därmed är terroristerna stoppade. Argumenten för att använda ET är att det i dagsläget är en extra krydda på de skriptade tester som finns kvar för att verifiera basfunktionaliteten, det går snabbt och billigt att hitta fel, testingenjörerna tvingas tänka själva och får använda mer av sin kompetens. De tycker alla att det är roligare att jobba och är samtidigt mer effektiva. Mindre tid läggs på förvalting av testfall och mer på att verkligen testa. Varianter som parvis testning och bug-bash har använts med lyckat resultat.

Förutom inbjudna talare var övriga deltagare: Mia Sköld, Anders Claesson, Peter Ohlsson, Pablo Garcia (tack för ordnande av lokal och mineralvatten), Johan Åtting (som lovar att föra conceptet Peer Conference till Linköping) samt undertecknad som var moderator och stod för inköp av Pizza.

Vi höll på fram till 21 och lovade att fortsätta med fler möten inom SWET. Anders Claesson paratar gärna och mycket om sina erfarenheter av ET på Stort svenskt telekomföretag.

Vi konstaterar att det fortfarande är lika kul och givande med denna typ av sammankomster. En idé är att fortsätta diskussionerna på min blogg där alla får göra inlägg och ställa frågor.