Gå till innehåll

Författare: Anders Sandström

Publicerat den

Håller på att läsa boken Fearless Change om hur man inför förändringar. Boken är uppbyggd runt ett antal mönster - patterns - med talande benämningar. Innehållet är förhållandevis lättläst och många mönster känns igen. detta är inte så konstigt då utgångspunkten har varit att samla tips från erfarna förändringsledare och göra dem tillgängliga för allmänheten. Jag kan lätt koppla olika mönster till mina egna erfarenheter och se var jag har lyckats och varför jag misslyckats med vissa saker.

En väldigt viktig del är avnittet om olika människors benägenhet att förändras. Här delas vi upp i grupperna

- Innovators  (2,5%) som tar till sig nya idéer snabbt, tycker det är spännande att prova nåt nytt men i gengäld tappar de intresset fort.

- Early adopters (13,5%) Som är öppna för nya idéer men vill först undersöka och utvärdera. Visionärer som andra ofta lyssnar på. Viktiga att få med på banan tidigt för att visa vägen.

- Early majority (33%) Följer gärna efter när andra har lyckats med någor nytt. Vill se resultat som gynnar dem. När dessa har tagit till sig förändringen börjar det hända saker.

- Late Majority (33%) Skeptiker som tar till sog nya saker först när alla tvivel är undanröjda och de får mer eller mindre direkta anvisningar från chefer att börja själv.

- Laggards (18%) De som sist tar till sig något nytt om de gör det alls. Vi har alltid gjort så här. Viktigt är att inte lägga all kraft på dessa men försöka hindra att de påverkar andra och förstör för dig.

Jag tycker det blir särskilt intressant att läsa om de mönster som jag kan använda i min strävan att kompetensutveckla strategiskt. Speciellt tänker jag då på min utbildning i testdesign - hur ska jag nå fram till alla, hur ska jag kunna underlätta vidareutveckling efter en kurs? Här är några av de mest användbara mönstren för kompetensutveckling:

  1. Big Jolt: Genom att bjuda in en auktoritet på ett område att tala för andra är det lättare att få gehör. det är spännande att se hur förståelsen och användandet av Exploratory Testing har ökat i Sverige sen James Bach började komma med regelbundna kurser och tala på konferenser.
  2. Do Food: Se till att fixa mat eller fika till ett möte och därmed göra det till ett speciellt tillfälle. Vi har den senaste tiden alltid fixat mat inför styrelsemöten i SAST och START-möten för att börja jobbet med full mage och den sociala biten avklarad. Det har hjälpt oss att svetsa ihop gruppen så mycket att många vill fortsätta mötet med en öl efter tre timmars möte!
  3. Guru Review: Låt en guru utvärdera din idé och berätta vad de tycker. Gärna till hela din grupp.Jag lät James Bach få ta del av upplägget av min bok och fick många värdefulla synpunkter.
  4. Hometown Story. Låt andra berätta om hur de harlyckats med din idé eller berätta hur du själv använt sakerna med lyckat resultat. Hela min bok är full av exempel från verkligheten, det tycker jag själv är väldigt viktigt då jag läser den typen av exempel med stort intresse. Skulle önska att fler personer som gått min kurs delar med sig av erfarenheterna efteråt - hör av dig!
  5. Just Do IT: använd din idé själv för att se för och nackdelarna. Läs och studera vad andra gjort med din idé.
  6. Just enough: Ge bara tillträckligt mycket information om komplexa idéer till de som lyssnar och visa var de kan lära sig mer. Jag har insett att vissa kursavsnitt jag hållit var alldeles för rakt på sak med ganska svåra teorier. Har därför tagit ner nivån så att alla ska kunna hänga med. detta är svårt för mig som hållit samma kurs eller föredrag femtio gånger då allt känns som gammal skåpmat...
  7. Location, location, location: Ha kurser och events UTANFÖR arbetsplatsen. detta för att poängtera attdet är viktigt och hindra att folk smiter iväg till mejlen och tappar fokus. Det finns alltid en risk med interna kurser på arbetsplatesn att fokus försvinner om man får chansen att göra sitt vanliga jobb i pauserna. Så av med mobilen och ta er till en kursgård eller lokal på annan plats.
  8. Mentor: Detta klassiska sätt att få stöd från en annan mer erfaren person i det dagliga arbetet tycker jag själv är fantastiskt bra och alldeles för lite utnyttjat. Jag har själv använt erfarna mentorer från mitt första testprojekt fram till idag. Har även jobbat som mentor men gott resultat, dock krävs det att adepten är intresserad av att lära sig något - annars är det kört.
  9. Next Steps. Vad gör jag efter kursen eller konferensen för att gå vidare? Detta ska jag prova på nästa kurs. Gjorde själv en plan efter att ha gått ISEB Practitioner kursen. Satte upp målet att använda de tekniker jag lärt mig i mitt aktuella projekt. Prickade sen av efter hand när jag testade flöden, tillståndsgrafer och data. Det var starten för mig och sen fortsatte det av bara farten.
  10. Plant the Seeds: se till att ha med material till intressaerade då du håller kurs eller föreläsning. Jag har alltid med mig böcker som jag säljer till rabatterat pris eller ger bort i samband med föreläsningar. Du kan själv skriva ett white-paper eller en artikel som du delar ut till kollegorna.
  11. Step by Step: ta ett litet steg i taget istället för att försöka göra allt på en gång. Och fira varje Small Success. Jag hade som mål i början att ta fram en entimmas kurs i testdesign. Detta blev checklistor och några enkla tekniker. Det fortsatte med fler tekniker - en i taget och blev en halv dag, sen en hel dag och till slut två dagar. Ett worddokument och en powerpoint blev en bok och en kommersiell kurs. Jag har hållit en dag intro til test på engelska och ska i december hålla en dag om testdeisgn på engelska och samtidigt ge ut boken i engelsk version. det viktiga för mig är att tänka långsiktigt ett steg i taget och det har varit svårt då jag vill se omedelbara resultat. Nu har jag haft trädgård i tre år och vet att det inte finns något som heter snabba förändringar - det måste liksom växa fram med tiden.
  12. Study Group: Effektivt, roligt och billigt är det att anordna en studiecirkel med kollegorna. Jag anordnade ett START-möte förra hösten över en helg där erfarna testare delade med si av sina erfarenheter och diskussionerna var intensiva. Vi har fortsatt med kvällsmöten och hoppas kunna hålla gruppen levande. Min kollega på handelsbanken Ann-Charlotte har startat samma sak internt med mycket gott resultat. Alla är engagerade och kostnaderna hålls nere.

...Och det finns mycket mer att läsa.  köp boken och börja använda mönstren!

Publicerat den

Har precis utvärderat ett standardsystem för bank och eftersom jag just plöjt igenom första halvan av "The Design of Everyday Things" hittar jag snabbt det som är dåligt designat. Det är nästan för enkelt att hitta problem! Här är några av de mest uppenbara. 

  1. Det går inte att söka på delar av värdet i ett fält
  2. Dålig återkoppling när man sparat - skärmen töms på data men inget meddelande
  3. Dåliga felmeddelande - database error - när man fyllt i ett sökfält med ex blanksteg och det inte går att söka på blanksteg
  4. Online hjälp saknas helt
  5. Väldigt tabellstyrda bilder vilket gör det mer omständigt för en användare. All design av GUI styrt från databasen istället för ur användarsynvinkel
  6. Knappar gömda längst ner på en sida(delfunktion) som inte syns om man inte rullar tillräckligt långt ner men andra knappar för huvudfunktionen syns alltid - gör alltid fel första gången
  7. Svårt eller i princip omöjligt att inte använda musen för att lösa problem - går inte att bara använda tangentbordet.
  8. Ingen logisk visning av komplicerade kopplingar mellan delar - användaren måste ha ett papper bredvid och rita upp hur det egentligen ser ut. I princip beskrivs en graf i tabellform för att den ser ut så i databasen.
  9. Markören visar ibland timglas, ibland pil och ibland hand men det är inte riktigt konsekvent:
  10. Ibland betyder backspace stäng fönster och inte radera tecken
  11. Beräkningar som ALLTID ska ske i en viss ordning måste manuellt numreras med stor risk för felaktig konfiguration

Och det är bara början. TYvärr är den allmänna instaällningen att andra system är lika dåliga och att om man köper ett standardsystem för X mijoner så får man räkna med att det är dåligt designat - vilket resonemang!

Publicerat den

<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } A:link { so-language: zxx } -->Jag har tillbringat de senaste veckorna med att läsa om prototyping (Serious Play av Michael Schrage), användbarhet och interaktionsdesign. Alla som skriver är överens om problemet att få en kund/beställare att dels veta vad de vill ha, dels förmedla detta till den som ska bygga produkten. Ett sedan länge välkänt och effektivt sätt är att skapa prototyper av något slag och låta den tänkta användaren känna sig för under noggrann observation. Motiveringen är att först då man ser en sak vet man om det är det man vill ha och om det är något  som fattas. Jag kommer på mig själv att sitta och nicka hela tiden och säga för mig själv hur självklart det är att jobba på det här sättet. I mer vattenfallsliknande projekt  brukar man säga att det funkar bäst om beställaren är aktiv under hela projektet, med andra ord känner sig för och styr in utvecklingen på rätt spår - en sorts prototyping!

I agila projekt är ett av huvudmottona  "Welcome changed requirements, even late in development" . Nu har jag suttit med på ett  par testkonferenser och dessutom diskuterat livligt om fördelarna med agile och inte minst påverkan på test.  Pablo Garcia hävdar envist att metoder som SCRUM, XP etc är mest för utvecklarna så att de levererar stabila bra produkter. Test får vara med litegrann men ofta  verkar det ligga lite utanför - som vanligt. Frågan är inte om ett SCRUM-team testar eller inte - för de gör de mycket och ofta. Frågan är om alla nivåer av test kommer med tillräckligt mycket och det är en berättigad fråga.   Dessvärre har jag inga egna efarenheter - ännu - jag ser fram emot det första agila projektet jag får bita tag i. Så om ni har några på gång till hösten, hör av er!

Men åter till problemet att den som beställer inte vet vad de vill ha. Ofta är det först i  system- eller acceptanstest som en översiktlig genomgång av alla affärsprocesser i verklig användning görs. Då är det ju som alla testare vet alldeles för sent att göra några genomgripande förändringar i designen. Det jobb vi ofta gör med affärsprocesser och röda trådar genom hela systemet borde ha gjorts tidigare med tyngdpunkten i andra änden av projektet - innan kodningen börjar.

Som jag tolkar de agila principerna så är målet att leverera ofta och  alltid en körbar version.  Detta inte bara för att se att koden fungerar utan även för att kunden ska ha en chans att ge en återkoppling på funktionaliteten och lösningen i stort. På ett sätt är det motsatsen till prototyping då en viktig princip är att prototypen är "quick and dirty" och syftet är att få fram bra krav men kodningen är slarvig och prototypen bör därför kastas. Istället gör man refactoring och får på så sätt fram bra kod  - eller iallfall bättre än dålig. Läste ett stycke i Serious Play om ett experiment där Boehm hade låtit två grupper utveckla ett litet system. Den ena gruppen mer traditionellt sekventiellt med analys, design av det mesta innan kodningen började, den andra gruppen med agila metoder med täta leveranser. Det visade sig att den agila gruppens kod var sämre strukturerad och hade färre funktioner men mer nöjda användare.

Varför inte ta det bästa av alla världar och göra en bra prototyping i början för att få fram bra krav,  utveckla agilt om det nu passar utvecklarna bättre och sen göra ordentliga tester som komplement till det som göra i den agila gruppen? Fördelarna är att experter på interaktionsdesign och användbarhet  är BÄST på att skapa en användbar produkt, utvecklarna  BÄST på att lösa problemen kodmässigt och  testarna BÄST på att  testa. Samarbete är fantastiskt och ofta effektivt men hur  lätt  är det för en  interaktionsdesigner att komma med i  ett SCRUM-team eler för en testare att komma med över huvud taget?

Det borde funka  bäst att först ta fram de flesta kraven, funktionerna och gränssnittsdesignen  ot användaren. Sen får experterna på arkitektur och kodning göra sitt bästa att realisera lösningen.

Publicerat den

Jaha, nu gjorde jag vad jag lovade att inte göra. Rapporterade fel i tidrapporteringssystemet. man som jag är så vill jag inte stå mitt kast utan skyller helst ifrån mig på systemets uselhet. Enkelt beskrivet så funkar det så här:

1. Välj vecka att rapportera på

2. Välj kod att rapportera på i tre steg: projekt, aktivitet och arbetsuppgift

3. Mata in tid och spara

Det första problemet är att systemet inte minns vad jag rapporterade på förra veckan. Jag måste välja kod i tre steg istället för att bra välja samma som förra veckan. Om jag nu glömmer att välja kod, vad händer då? Man skulle kunna tro att jag får ett felmeddelande men icke. Istället väljs den första kod i bokstavsordningen som finns i listan och det råkar vara borta för vård av barn! Jaha så då sitter jag där med en stängd rapportperiod och en vecka med VAB istället för jobb. Synnerligen dålig användbarhet som enkelt skulle kunna ha rättats till genom att tvinga användaren att göra ett val och varna då detta inte görs. Då är det bara att rapportera den felaktiga tiden som minus och lägga till den för denna vecka istället. Snacka om att man jobbar utifrån de interna tabellerna och inte från användarens perspektiv. Mer jobb åt alla parter. Jag letar vidare och hittar en funktion som heter kopiera til nästa vecka - gissa vad som händer om jag använder den? Jodå, koden för VAB kopieras till nästa vecka men inte koden för normltid, suck.

Ett bra system hindrar användaren från att göra fel och hanterar det snyggt när han gör det. Inget av dessa kriterier uppfylls här. Möjligen finns en pedagogisk vinst i att jag kommer att kolla extra noga för nästa rapportering.  För att inte tala om att jag har ytterligare en anekdot att berätta när jag håller kurs.

Publicerat den

Jag har hört en hel del om agil testning och test toolsmiths och är sugen på att försöka på egen hand. Tillsammans med Anders Claesson tänkte jag dra ihop ett gäng testare med grundläggande utvecklarkunskaper för att fördjupa oss i Perl. Perl verkar vara mycket praktiskt för att analysera och skapa filer och datamängder av olika format. Jag inser att jag i många testprojekt skulle haft stor nytta av att kunna skapa testdata och analysera testresultat eller loggfiler. Nu har vi beställt böcker, nästa steg är att ladda hem PERL och sen är det bara att köra hårt. Förhoppningsvis kan vi arrangera nån sorts workshop en helg i vår eller till hösten. Vi söker andra som är intresserade av att delta aktivt. Är du testare eller utvecklare och har utvecklat i PERL är du extra välkommen.