Gå till innehåll

Team Kirks Krew was formed as one of the first exercises in the PSL workshop day 1.  It consists of David (who likes biking), Bart (who likes to paint miniature armies), Tobbe (who likes fixing stuff at home), Ola Who likes floorball, Henrik who is a surfer and Rasmus who enjoys sailing. Well we did this exercise where we learned how to remember names by associating wth activity and gestures.

Kirk

It has been an interesting first day of problemsolving where some lessons learned are:

  • Ask for more information continuosly
  • You seldom understand what the problem is right away and maybe not even when you think you are done
  • We make bad decisions during stress
  • We need to stop and think waht we are doing once in a while
  • ...and of course much more

Sorry but I really need to sleep now.

Here is Bart pulling out cards from our tower, earning three points for every card withdrawn with the tower left standing. Esther watching closely and giving instructions of what card to remve next.

bart

Kursen med stort K har börjat. Jerry Weinberg, Esther Derby och Johanna Rothman har tagit sig från Obama-land till Krusenberg Herrgård utanför Uppsala för att i sex dagar drilla oss i ledarskap. Då Citerus är den arrangerande parten befinner jag mig omgiven av agilemänniskor. Något oväntat dök Bart Broekman från Sogeti Holland upp bland deltagarna. Vi skrattade lite när han konstaterade att han vanligen är på "andra sidan" jämfört med det agila tänket. Jag delade bord med Johanna Rothman ikväll och diskussionen var livlig över farliga djur, ledarskap, författarskap och funderingar över hur roliga och långa smarta människor dras till varann och motsatsen. Vi konstaterade att vi var fyra publicerade författare vid bordet - ämnena varieda från SCRUM och Ledarskap till Test och Delphi. Vilken spännande vecka det kommer att bli! Min förhoppning är att blogga dagligen om höjdpunkterna från kursen. Speciellt för att retas med Henrik, Petter och Herman som skulle velat vara här... Vi får snacka mer sen om hur det var.

Häromdagen besökte jag folktandvården. Ni vet de som inte borrar i onödan för att kunna köpa mer prylar som privattandläkarna gör. Pengar per hål - ungeför som att ge extra betalt om testarna hittar (registrerar) fler felrapporter. Det blir nog en hel del extra borrande hos många privatister.

Men det var inte det vi ska prata om nu utan det datasystem som man köpt in. Det har ju stått en hel del i tidningarna om misslyckade system hos folktandvården och hos försäkringskassan så jag tänkte undersöka det närmare när jag var på plats.

Först frågade jag min trevlige tandläkare Aramis hur systemet fungerade när han satt och försökte lägga in dagens behandling. Han suckade och sa att det var rätt krångligt och fortsatte välja fyrsiffriga behandlingskoder så att tabellen skulle bli komplett. Det blev många klick men till slut var han klar. Tack för mig och iväg till kassan. Å fyra tandbortar til barnen och fluor till pappa. Vänta lite sa receptionisten, jag måste fråga hur jag ska lägga in det extra. Enkelt sa hennes kollega, först så summerar du ihop det han ska ha på miniräknaren här, priset på varje sak står i papperslistan här, sen kollar du den andra listan för att få priset du ska lägga in i datorn (utan moms?), sen lägger du in en ny post på patienten. Till sist så tittar du på summan och skrive in den manuellt på betalterminalen så får kunden betala med sitt kort. Hmmm, är det jobbigt att jobba söndag frågar jag. Nej men systemet gör mig trött svarar hon.

Här ser vi åter ett exempel på att funktioner finns där men användaren glöms bort. Kanske har vi prickat av kraven i en lista, sett till att spårbarheten finns där, lagt upp testfall i ett verktyg och sett till att alla tester är godkända. Men var gör det när användaren är missnöjd! Det är dags att gå från diskussionerna om ett testfall är godkänd eller inte Pass or Fail till ett mer mänskligt perspektiv där vi funderar på om det sätt systemet fungerar eller inte fungerar bli ett problem för någon användare. Om det är ett problem så bör vi se till att åtgärda det. Det kan verka som en filosofisk fråga men visar på ett helt nytt sätt att se saker. Att pricka av testade krav i en lista eller räkna testfall är mer en terapeutisk verksamhet.Att vi bara kan och ska testa det som uttryckligen står i kraven är en inställning vi bör ta oss ifrån snarast. Visst måste vi använda de klassiska teknikerna för testdesign men glömmer vi bort användarna så är vi rökta.

Vikten av kontroll

Det finns ett antal olika skolor, inte bara inom test, som pratar om vikten av att styra upp arbetet med någon sorts riktlinjer. De mest rigida är av typen Six Sigma, CMM level 5 där allt ska styras in i minsta detalj. Många av de som jobbat med den typen av metodik säger att det ofta är mycket ineffektivt i systemutvecklingssammanhang. Fokus blir på att tillgodose kraven på dokumentation och inte att jobba så effektivt som möjligt. Som exempel kan nämnas den outsourcing som en del gör till Indien - det mest CMM 5 täta landet i världen. Problemet är att de tar fram PRECIS det vi har skrivit i kravspecen men eftersom det är omöjligt att skriva en perfekt specifikation så får vi inte det vi behöver eller egentligen vill ha.

Mindre styrning - bättre resultat?

Åt det andra hållet finns de lättrörliga metoderna där man fokuserar på att producera fungerande kod och att använda allas kompetens och skicklighet maximalt. Ledaren låter här de som jobbar själv planera och styra sitt arbete till mycket hög grad. Nu är det inte alla som klarar av eller gillar att joba på det sättet.

Frågan just nu

Hur som helst så är mitt senaste uppdrag att införa en testmodell på ett stort företag. Test var till för något år sedan relativt okänt här, men har under senaste tiden blivit mer aktuellt då de börjar bygga större och mer komplicerade system. Jag som suttit på två storbanker och jobbat med rätt så omfattande processer för test funderar på vilken nivå som lämpar sig just här. Min erfarenhet av styrning är att att ju mindre detaljerad den är, desto fler kan tänkas acceptera den. En alltför detaljerad styrning av arbetssätt, eller testfall för den skull, kväver både arbetslusten och det egna tänkandet. En övergripande styrning med STOR PRAKTISK inriktning är mycket mer effektiv. Jag sitter just nu och läser Dale Carnegies klassiker Hur du vinner vänner och påverkar din omgivning. Det står många visa ord där. Bland annat pratar han om att ett effektivt ledarskap innebär att du får andra att själv VILJA göra det du vill att de ska göra. I annat fall kommer många att göra allt för att slippa och säkerligen göra ett jobb som är sämre än deras kapacitet. Så det är viktigt att de som ska använda processen känner stor egen motivation. Det gör man sällan om man är hårt styrd.

Vårt angreppssätt

Valet vi har gjort är att med en relativt liten insats -ca 300 timmar- jämfört med tidigare uppdrag, ta fram en enkel testprocess . Det ingår självklart mallar och exempel för de viktigaste dokumenten som strategier och rapporter. Men målet är att skriva så LITE som möjligt, vilket är betydligt svårare än att skriva mycket! Vi har utgått fran existerande mallar och exempel från både mig själv och kollegor. Hellre enkelt och snabbt är stort och detaljerat. Vi är inne på att antingen skaffa en freewareprodukt för felhantering eller en billigare variant av testfall och felhantering som ReQTEst. Vi ser inte att den kommerciella giganten Quality Center är värd den höga kostnaden. Det bästa exemplet på väl fungerande freeware är Linux som jag tror kommer att ta över efter Windows inom tio år. Införandet är som alltid en större utmaning. Jag tänker mig en 2-3 timmars intro till alla om test på företaget och test i allmänhet, sen en grundkurs på två dagar och en testdesignkurs på två dagar för de som ska bli testare. Ytterligare påbyggnad för testledare en dag plus mentorskap i samband med projekt. Vi vill ha två personer som är experter på programtest och förslagsvis N-Unit. Vi får väl se hur det går. det beror helt på viljan att satsa den tid som det kommer att kosta.

 

 

 

Det farliga med en standard är att det som står i den ska räknas som det som gäller. Det är därför viktigt att informationen stämmer överens med resten av världen. Då jag just nu sitter och arbetar med test i Unified Process undersökte jag vad som står i Syllabusen om Use-Cases. Väljer att studera den internationella version som övriga länders översättning bygger på.

4.3.5 Use case testing (K2)

Tests can be specified from use cases or business scenarios. A use case describes interactions between actors, including users and the system, which produce a result of value to a system user. Each use case has preconditions, which need to be met for a use case to work successfully. Each use case terminates with post-conditions, which are the observable results and final state of the system after the use case has been completed. A use case usually has a mainstream (i.e. most likely) scenario, and sometimes alternative branches.

Use cases describe the “process flows” through a system based on its actual likely use, so the test cases derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system. Use cases, often referred to as scenarios, are very useful for designing acceptance tests with customer/user participation. They also help uncover integration defects caused by the interaction and interference of different components, which individual component testing would not see.

Som metodare reagerar jag på de ord och förklaringar man använder sig av.

1) Mainstream Scenario: detta betecknas vanligen primary flow, basic flow eller happy flow. Mainstream är en helt ny beteckning.

2) Alternative branches: flow eller path är OK men branch är också en ny beteckning.

3) Sen står det att Use-Cases är mest effektiva för att hitta Real-World problem och därmed bäst för acceptanstest. Nu finns det ju en business modeling disciplin och där kan det finnas business use cases men ofta är det business processes, information och rules som beskrivs och dessa testas främst i acceptanstest. Use-Cases är ju kraven på SYSTEMET och testas främst i systemtest.

4) Sen säger man att ett Use-Case vanligen kallas scenarios vilket också är fel då ett scenario är EN väg genom ett use-case. Oftast finns det ett flertal scenarios som ska testas - detta är också tekniken för test av Use-Cases. Ta fram aktivitetsdigrammet och testa alla (om det går) scenarios.

5) Till sist blandar man in component testing och integration mellan komponenter där man blandar ihop component, component -integration och system testing. Det är som att skriva att use-case testing - som är en black-box teknik är bättre än komponenttest för att testa helheten. Ja det är ju rätt i princip men jämföra en en specifik teknik med en testnivå är väl knappast logiskt.

Helt uppenbart har den som skrivit texten inte rådfrågat en UP/Use-Case expert eftersom till och med de vanligaste begreppen och huvudsyftena är felaktiga.

Lite mer än så borde vi kunna förvänta oss av en internationell standard tycker jag.