Leveled up: Auditability of AI and Machine Learning

Architects and many others remember the tightrope walk between flexibility/performance and testability/predictability/V&V in systems with many run-time parameters, or parallelism, or late binding time ranging from polymorphism to SOA-UDDI and ad-hoc computing. Now, it’s leveled up by ML (machine learning). Essentially the same tradeoff, but growing broader and trickier. 

Black box 

ML stirs up the fire; despite its roots (rule induction and mining) in the successful decryption of an unbreakable cipher, its near future looks encoded in weight values somewhere in deep neural networks. Whereas black-box flight recorders clarified the chain of events & decisions in past emergencies, more and more IT is now landing in black boxes that hide opaque logic.

Predictability wasn’t a big deal in consumer IT and entertainment (when Youtube or Spotify wrongly offered you a title you were avoiding like the plague, you rarely asked why)… If you just say “skis this wide apart look amusing”, I guess you’re in consumer IT, but if you insist on a layer-by-layer explanation why most artificial vision systems have a hard time in strong sunshine on white slopes, I bet you’re in corporate (image: Ski Robot Challenge, Korea). 

Tackle it one-way or two-way

Business apps are very different from apps for billions of consumers (see slides 9 to 15 in this talk by Oracle’s VP at SICS). Your enterprise or team can tackle the leveled-up tradeoff both top-down and bottom-up:

• assuring a framework of corporate values and procedures (particularly transparency, governance & compliance, accountability, and a security & safety culture)

• applying appropriate technologies and practices in IT to build in mechanisms upfront  for auditability, comprehensibility, predictability, traceability, testability/V&V (as well as fraud-prevention, such as restricted access to learning-data sets).       

On the latter (bottom-up) part, there’s ongoing AI research to “unpack” the opaque logic buried within deep learning systems, and to give them an ability to explain themselves. DARPA’s Explainable AI Program, XAI , aims at ML techniques (new or improved) that produce more explainable models, while maintaining a high level of prediction accuracy. New machine-learning systems will have the ability to explain their rationale, strengths, weaknesses, etc.

Hybrid-AI tech vendors often address organizations with more constrained schedules, budgets and levels of AI expertise. Hybrid learning systems combine “subsymbolic” ML with transparent symbolic computation (typically, wellknown knowledge-processing techniques). The combination lowers the total cost of entry into AI and ML, because it evolves from logic that domain experts already know (rules, decision trees, etc.)

From there, hybrid systems employ ML iteratively to fine-tune this explicit logic: for example, to narrow the IF-part of a rule to factors that prove most significant. That is, results of ML from big data decide about variables to be included (or omitted), about intervalization of a continuum of values, or about relevant threshold values of a particular variable.

Notably, a rule is still expressed as a rule yet with an ever-smarter and more accurate IF-part. This is transparent to humans, and paves the way to embedding AI and ML into daily IT-dev practice: devs and architects will gradually find thousands of decision points, enterprise-wide, suited for small AI apps in daily business. Those will generate valuable skills, know-how, and “tip feeling” as to where ML can work (or can’t).

Models, animations, transparency

Once the opaque logic is unpacked, or expressed as rules or trees, it’s time to revive your team’s modeling skills. Long story short, a decision tree (or an invocation path through a rule base) is an excellent input to animations or test executions of different scenarios, to make them transparent even to stakeholders and non-IT roles. That story is worth another blog post, later this spring.

by Milan Kratochvil

Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, and design. You can meet him at public Architecture courses in English or Swedish ( T1101, T1430) in April, May, and June, or Modeling courses in May ( T2715, T2716).

Läs mer

Det svenska testundret

Om man söker efter ”det svenska undret” i en känd sökmotor, kan man läsa om de perioder i svensk historia som kännetecknats av en snabb samhällelig och ekonomisk utveckling. Den första av dessa perioder inföll under 1800-talets senare decennier, då freden, vaccinet och potäterna banade vägen för stora framsteg inom industrin och vetenskapen. Den utvecklingen fortsatte sedan en bra bit in på 1900-talet. Det var under den här tiden som Alfa Laval, Asea, LKAB och LM Ericsson började växa sig stora och hjälpte till att sätta Sverige på världskartan som industrination.

Det svenska undret fortsatte under perioder under hela 1900-talet. Nyutvecklingar och innovationer på flera områden bidrog till att göra Sverige världskänt. När jag talar om det svenska undret tänker du kanske på

- musikundret (ABBA, Ace of Base, Robyn m fl),
- modeundret (Acne, Whyred, Filippa K, m fl),
- tennisundret (Björn Borg, Mats Wilander, Anders Järryd m fl),
- deckarundret (Sjöwall/Wahlöö, Henning Mankell, Stieg Larsson m fl),
- IT-undret (MySQL, Spotify, Skype m fl).

Listan fortsätter med golf-, kör- och app-under och så vidare, men du förstår principen. För ett land med blygsamma 9,5 miljoner invånare kan Sverige skryta med anmärkningsvärt många framgångshistorier.
I dag vill jag lyfta fram ytterligare en: det svenska testundret.

Om du läser det här inlägget på en dator eller mobil enhet med internetuppkoppling, så vill jag be dig att gå till din favoritsökmotor och knappa in ”software testing in Sweden”. Du kommer att få en hel massa länkar till föreningar, företag, organisationer, utbildningar, kurser, konferenser, produkter och naturligtvis många professionalla yrkesutövare. Alla representerar de den stora bredden inom kravhantering och programvarutestning som finns i Sverige i dag.

Låt oss titta närmare på vad ”lilla Sverige” faktiskt har att erbjuda:

Föreningar och communities

- SAST (Swedish Association for Software Testing) grundades 1995 som ett forum för yrkesverksamma programvarutestare. Sedan dess har verksamheten vuxit år för år och utökats med lokala föreningar som anordnar föreläsningar och seminarier.

- TestZonen är ett obundet och ideellt forum för diskussion om test, krav, kvalitet och processer. De anordnar dessutom mingelträffar (meetups) och en årlig konferens.

- På LinkedIn finns flera svenska grupper för diskussioner om krav och test.         

Konferenser

- Let’s Test är en konferens som har fokus på context-driven testing.

- TestZonen anordnar varje år en konferens för sina skribenter. Den bygger i hög utsträckning på deltagarnas egna idéer och initiativ.

- EuroSTAR-konferensen med Europas största fackmässa kommer att hållas i Sverige i år, närmare bestämt i Göteborg, den 4 - 7 november 2013.

- NFI Testforum är en återkommande konferens om test och kvalitetssäkring.     

 Utbildningar

- Som läsare av Informator-bloggen känner du säkert redan till Informators utbud av kurser inom krav och test. I utbildningsstegen hittar du kurser som ger dig verktyg, metoder, processer och modeller för att arbeta smart med krav och test. Om du önskar kan du även certifiera dig inom ramen för REQB och ISTQB.

- Kommersiella utbildningar erbjuds också av en rad företag 

- Flera yrkeshögskolor erbjuder hela utbildningar inom programvarutestning i bland annat Karlstad, Kungsbacka, Göteborg och Stockholm. 

- Akademiska kurser inom programvarutestning finns bland annat vid högskolorna i Dalarna, Luleå och Växjö.

Litteratur

-   Test och kvalitetssäkring av IT-system, Ulf Eriksson
-   Kravhantering för IT-system, Ulf Eriksson
-   Testdesign för programvara, Torbjörn Ryber (finns även i engelsk utgåva)
-   Testledning, David Pers & Mikael Ölund
-   Tore Testledare, David Pers 

Listan skulle självfallet kunna göras mycket längre, men jag nöjer mig med detta. Jag tycker att de exempel som nämns är bra representanter för programvarutestning, så som den ser ut i Sverige i dag. Det som jag slås särskilt av är hur många engagerade testare som finns runt om i landet, och deras vilja att träffas, utbyta tankar och lära sig nya saker av varandra. Att utvecklas i sin yrkesroll – om det så innebär att man lägger några timmar av sin fritid – och att ha roligt samtidigt. Test är fest.  Inte många länder har en så aktiv och levande testarcommunity som den vi har.

Krav och test är områden som har utvecklats starkt de senaste tio – femton åren. Och framtiden ser fortsatt ljus ut. Allt fler företag har förstått att ett ordentligt krav- och testarbete är en förutsättning för att projekten ska lyckas. IT-systemen tenderar att bli alltmer komplexa, något som ställer högre krav på kompetens inom krav och test. Testarna hjälper till att tillföra nytta till sina verksamheter, och det hjälper i sin tur till att höja statusen på yrket.  Samtidigt blir det hela tiden bredare och mer specialiserade mot olika områden. Att arbeta med test kan till exempel innebära att vara testledare, teststrateg, testautomatiserare, testdesigner eller testmiljöansvarig. Valmöjligheterna är med andra ord goda för den som vill hitta sin egen nisch.

Vad brinner du för? Om svaret är krav eller test, så har du hamnat helt rätt. Hos Informator hittar du ett gäng kursledare som är stolta över att vara en del av det svenska testundret. Vi ger dig grunderna och hjälper dig att ta nästa steg i din testkarriär.

Freddy Gustavsson har arbetat med test och kvalitetssäkring av programvara sedan 2001.

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer

Architects beware: 60 years since Dartmouth

Many R&D-intensive industries experienced an initial period of teething troubles, about six decades between their seminal events and their commercial breakthrough, followed by exponential growth. Last summer, 60 years had passed since the 1956 Dartmouth Artificial Intelligence Conference. 

History…

In 1887, Ernst Mach, a physics professor at the Charles University in Prague, established the principles of supersonics and the Mach number relating velocity to the velocity of sound (thus inspiring his faculty successor Albert Einstein’s theory of relativity). Exactly 60 years after, test pilot Chuck Yeager reached the magical speed of Mach 1, breaking the soundbarrier, with the Bell X-1 rocket plane.

From there, Mach numbers skyrocketed to NASA’s Apollo missions, taking humans to the Moon and back. In aerospace, “the sky is the limit” applied to turnover figures as well.

Mach (source: Wikipedia.org)                         Mach 1 (source: Wikipedia.org)

In 1865, the scientific community (including Charles Darwin) missed the importance of Gregor Mendel’s research in Brno into inheritance in plants, but rediscovered Mendel’s Laws in the 20^th century. Mendelian genetics and Darwin's natural selection finally merged in the 1930s, as evolutionary biology. Six decades later (1990-2003) the Human Genome Project HGP, the world's largest collaborative biological project so far, sequenced 92% of the human genome.

Genetics became a fast-grower with applications in diagnostics, forensics, archaeology, and more.

…repeats itself…

In 2016 (well, guess how many years after the Dartmouth AI conference) , the accuracy of Machine Learning (ML) systems started to outperform humans in extreme tasks, previously regarded as “out of reach” for AI. Some recent milestones are the games of Go and Poker , the latter by Mach’s and Einstein’s faculty heirs in Prague, and the University of Alberta Computer Poker Research Group in Edmonton.

AI delivers, which attracts brains and funds into the field. With the usual 60 years of teething in mind, we might call this the end of the beginning. AI departments of large US corporations in a variety of industry sectors are hiring AI experts by hundreds.

Yet the technical progress looks less dramatic when compared to the pace of both corporate and social change it catalyzes. A Forrester prediction last fall said 16% of US jobs will be lost to intelligent systems in the near future, and only partly compensated by 9% new jobs created by them (notably, jobs rather different from those that are vanishing).

…with an impact on architectural roles & landscape:

1. Much more IT(A) in Enterprise Architecture

EA will benefit from a stronger technical background. EA roles, architecture groups, and entire corporations who are used to absorbing new technology and have a strong background in IT including AI, have a competitive edge.

2. More tech leadership in management

That’s what built industries such as Scania, ABB, Volvo AB, and their modular configure-to-order tradition (C2O). The current shift in IT is more manageable in cultures with a clear context and clear ideas of what they need forefront tech for. After decades of custom-tailored complex manufacturing, people in these organization can come up with tangible proposals about leveraging for example, BI and CI (customer insight) downstream: in bidding, sales, pricing, assembly planning, flexible automation solutions, or within the product itself, e.g. in autonomous vehicles.

3. Robotics outcompete offshoring

I argued ten years ago that robots and automation offered a more long-term profitable solution. Everybody continued to rush offshore anyway, although the underlying figures weren’t convincing. Now (guess how many years after the Dartmouth AI conference… ) , AI has triggered a U-turn in corporate sentiment. By 2018, the number of manufacturing jobs moving from Sweden is going to equal the number of jobs moving back. The driving force: robotics and automation.

4. Architecture business as usual…

Architects often work with fancy tech within nearly medieval organizations under nearly stone-age governments. AI 2.0 might therefore feel painstaking. Intelligent robots can result in perpetual reorganizations (process innovators Michael Hammer and B. E. Willoch likened them to reshuffling the deck chairs aboard Titanic), and governments in high-tech countries, socialist and conservative alike, can spend billions on “creating very simple jobs” which is like herding cats: the simpler the jobs, the faster they jump (offshore, as some Swedish trade-union economists point out). Not to mention creating not-so-simple robot taxes that can push offshore the industries of an entire country or continent.

Architects aren’t enthusiastic about the mismatch they had to live with for a long time: a surplus of complexity and information, but a shortage of cognition; in data as well as in society…

5. New flavors of Architecture Patterns

For example, the Layered pattern, typical of business systems (UI, business logic, Object-Relational mapping, and DB) has siblings in deep-learning systems with layers of artificial neural networks trained for a key task each: perception (input parsing), pattern recognition, reasoning (pattern classification and selection of steps to take), and either autonomous action (“vehicle brakes on”, for example) or interaction (e.g. voice generation, or calls to other systems).

6. Ever-bigger data versus custom-fit learning strategies

Accurate fast learning from small data has an architectural savings potential, rarely mentioned in the big-data buzz. Two routes can take you there:

a)  pre-trained neural networks off the shelf (nowadays, you find those even in Matlab) to solve a certain category of problems, and ready to be extra-trained just for the “delta” i.e. the specifics of yours. Largely 90+ percent of the precision, at a fraction of the training time and cost.

b) cross-breeds of several AI techniques, as indicated by Poker systems where an innovative adaptation of a well-proven algorithm made DeepStack run quite fast on a laptop, no longer requiring extreme searches running on supercomputers.

7. Auditability, comprehensibility, V&V, reviews by humans

This category of ML challenges would be worth an entire blogsite. The tradeoff between quality (accuracy of output) and auditability (comprehensibility of machine-made internal logic) grew trickier generation by generation of ML technologies.

To cut a long story short, it’s easier to test that the “sub-symbolic” logic works accurately, than to see why or how.

   

Summing up

Neither Enterprise nor IT Architecture is exempt from AI’s impact on business processes and technology. Machine learning affects systems, organizations, and society, from the way an architect can tweak a plain pattern, and up to the way policymakers can get things plain wrong…

by Milan Kratochvil

Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com,

main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).

Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, analysis and design. In the next couple of months, you can meet him at Architecture ( T1101 , T1430, in English or Swedish) or Modeling courses ( T2715, T2716 , mostly in Swedish).

x

Läs mer

Auditability and V&V in the era of Machine Learning are worth a close review…

Developers, more often than architects, tend to get frustrated by declarative programming, because it boosts expressive power at the cost of less testability. Yet both the boost and the drop are a mild breeze compared to self-modifying and sub-symbolic Machine Learning (ML).

Reviews by humans

You can hardly get away without ML in today’s AI. It would be like a mainstream relational DB without SQL, or like a rule engine without declarative rules. And, you’ll run into auditability issues in all three, but they tend to be an order of magnitude bigger in “sub-symbolic” ML. It’s much easier to check whether the learning works accurately (a black-box test of a “black organism” ), than to see why or how. A clear-box view relates to the generated logic almost as loosely as an MRI-scan relates to what a patient is thinking.

Japanese industry robots started to assemble robots back in 2001. Today, robotics vendors offer complete lights-out manufacturing systems (in other sectors referred to as “no man in the loop” earlier). So, needless to say, auditability and reviews by humans are a key architectural issue. Be discrete precision manufacturing, avionics, automotive, power generation, medical equipment, or any other application where approval criteria (ISO etc.) are strict.

Decision-tree induction from data

 When the work of professor DonaldMichie (a distinguished codebreaker ahead of D-day) resulted in the first ML algorithms for rule mining and decision-tree induction from data, those were able to show the learnt-in logic as diagrams or rules, and even to generate conditional constructs in a mainstream programming language. This became particularly useful in the elicitation and processing of tacit knowledge (the implicit “knowwhy” underlying the explicit knowhow of a human).

Many IT roles are quite familiar with declarative rules, although in narrower contexts: In DB schemas (or UML models), the rules are typically about referential integrity along the lines of “on Delete cascade” in SQL DDL (see also the exclusive-or, {xor} , in the UML diagram). In design, rules are often invariants and preconditions/postconditions. In modeling, a UML state diagram defines visually the rules that govern event handling and state transitions. Etc.

A role model, UML pun intended, with an either-or referential integrity.

From Informator course AvanceradModellering, T2716 (structure-models chapter). 

Case Bases

The technology that followed in inductive ML (after decision-tree induction), Case Based Reasoning (CBR), was instance-based and used lazy generalization which expressed the induced commonalities (between cases in the learning-data set) only later, at test time. Although less explicit than decision trees or rules, this was still fairly comprehensible for humans to review.

Sub-symbolic “representation” of knowledge

However, the commercial breakthrough of self-modifying technologies, mainly neural networks and evolutionary algorithms, made audits both hot and tricky. In a neural network, the logic learnt during training is sub-symbolic, “packed” into weight values on connections and artificial neurons. Roughly speaking, a clear-box view relates to the generated logic almost as loosely as an EEG record relates to what a patient is thinking.

Therefore, many researchers argue that audit-related abilities of a subsymbolic-ML system, like reasoning about itself and meaningfully visualizing/animating/explaining its logic or its conclusions, improve greatly when its ML is combined with other (likely symbolic) AI techniques. If so, this is one of the rare cases in architecture where complexity and testability actually enhance each other rather than restrict.

     

Summing up

Architecture is not exempt from ML’s impact on AI, IT, and business processes. Although auditability was brought to the table already when robots started to assemble other robots, it is crucial today in all kinds of ML systems in a vast variety of applications and industry sectors.

by Milan Kratochvil

Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, Advanced UML2 Professional (OCUP cert level 3/3). Main author: UML Extra Light (Cambridge University Press) and Growing Modular (Springer).

Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, analysis and design. In the next couple of months, you can meet him at Architecture ( T1101 , T1430, in English or Swedish) or Modeling courses ( T2715, T2716 , mostly in Swedish).

Läs mer

Krav är som miljön och IREB är som miljöskyddslagen

Visst kan man till viss mån värna om miljön utan att det ska behöva finnas lagar, förordningar och regler. Alla människor tycker ju om ren luft och rent vatten och vill hellre se grönska än grå betong utanför sina fönster. Inte heller finns det några miljöpsykopater, som blir glada när det förorenar och skräpas ned med flit. Utan dessa besvärliga och ganska tråkiga lagar (försök exempelvis lusläsa ”Svensk författningssamling 1969:387”!) blir det dock lätt helt fel och miljön förstörs utan att någon egentligen vill det.

Samma sak gäller krav, både affärskrav och systemkrav. Man kan till viss mån lyckas att fatta bra affärsbeslut och bygga bra IT-system utan att det måste finnas utpräglade projektaktiviteter som heter kravinsamling, kravanalys och kravvalidering. Alla tycker bättre om smidiga arbetsflöden och lyckade satsningar, och vill hellre se fina IT-tjänster än https://javlaskitsystem.se/. Det finns inte heller så många projektpsykopater som trivs bra förrän det råder riktigt kaos och system sjösätts under dramatiska former i sista minuten. Utan dessa besvärliga och ganska tråkiga normer (försök till exempel lusläsa ISO/IEC/IEEE 29148:2011 ”Requirements Engineering Standard”!) blir det lätt helt fel i projekt trots att alla gör sitt bästa för att det ska bli bra.

Vi människor är duktiga på att dölja sanningen bakom fasader – alla kulturer baseras på denna kunskap. Samma sak händer ofta med kravhantering. Ju mer man tror sig veta att man minsann inte behöver någon specialaktivitet för att ta hand om sådana självklarheter som projektmål, systemfunktionalitet eller produktbacklogg desto mer säker blir jag på att mycket kravarbete faktiskt pågår, fast under ett annat namn.. En gång fick jag höra att kraven var ”arkaiska” när man kör med kontinuerlig integration och leverans, och motsatsen är ett faktum: för att uppnå hög leveranstakt och en värdedriven releaseplanering krävs mycket smidigt kravfotarbete.

Kravarbete går under många olika öknamn som ”förfining av produktbackloggen”, ”specification by example” eller BDD i den agila världen. Det försvinner i projektledningens avgrund inne i PMBOK, eller ges kraftig mindervärdeskomplex i BABOK som en lillebror av det stora och prestigefyllda verksamhetsanalysen; sist men icke desto minst, uteblivna eller bortglömda krav tar man hand om som sista åtgärd av testare, speciellt inom ramar för utforskande testning.

Det är inget självändamål att lyfta fram kravarbete och systemkrav till en mera prominent plats, det är inte fråga om prestige utan det handlar främst om effektivitet och lönsamhet. Det helt enkelt lönar sig att ta hand om krav på ett ordentligt sätt och att använda de rätta begreppen som främjar raka budskap.

För drygt tjugo år sedan insåg man samma princip vad gällde testning. ISEB, och sedan ISTQB testcertifieringar startades. De har blivit så populära att idag har fler än en halv miljon människor skaffat sig sådana. Man har lärt sig att visst går det bra ibland att uppnå bra kvalitet med testning inbyggt i andra aktiviteter, men det går mycket bättre när testningen betraktas som delvis separat, självständig disciplin och kunskap. Det är dags att uppnå samma mognadsnivå vad gäller krav och kravarbete.

IREB certifieringsschema kan hjälpa oss ordentligt på vägen dit. Personligen, har jag ingen överdriven entusiasm för certifieringar som sådana, men vissa självklara fördelar har de: de skapar ordning och reda, alstrar referensramar, gör ordning på terminologin, och framför allt, skapar en solid, heltäckande bas för alla. Först när du behärskat den, blir det fritt fram att kritiskt granska och komma med bättre idéer.

IREB schema är dessutom riktigt bra skapat av både industrispecialister och akademiker, erfarna människor som vet vilka kunskaper deras och andras projekt behöver.

I mitt nästa blogginlägg tänker jag beskriva IREB huvudpelare i detalj: idag får en ritning räcka till 😊. Hej då!

Bogdan Bereza

Programmerare, testare, psykolog, kvalitolog, verksamhetsanalytiker, traditionsälskare, agil-entusiast och utforskare. Pragmatisk, drömmare och visionär, allt i en och samma person. Han blandar gärna testning med kravarbete, mixar agila och utforskande metoder med försiktig förebyggande planering och kopplar ihop praktiskt projektarbete med bokskrivandet och undervisning. Hans elever tycker om honom för hans förmåga att göra svåra ämnen lättbegripliga. 

Bogdan undervisar i kurser inom Kravhantering som IREBCPRE Foundation, IREBcertifierad agil kravspecialist, IREBCertifierad Kravspecialist - Avancerad - Kravmodellering, IREBcertifierad kravspecialist - avancerad - kravanskaffning och konsolidering, IREBCertifierad Kravspecialist - Avancerad - Hantering av Krav, IREB CPRE Advanced Requirements Management och REQB- IREB

Läs mer

Så hittar du flow i jobbet

Har du någonsin upplevt att hur något du gör fångar just din totala uppmärksamhet, att du känner flyt? Du glömmer både tid och rum - du är i din bubbla. Du har full kontroll över vad som händer och du skulle kunna hålla på hur länge som helst. Om ja, då har du fått uppleva det som inom psykologin kallas  flow.

Flow i arbetet är något som många av oss önskar kunde ske bara vi knäppte med fingrarna. Riktigt så enkelt är det inte. Men vad är det då som triggar fram flow i jobbet?

För dig som inte är bekant med flow så är det ett begrepp som används mest inom psykologin. Det är ett tillstånd som sker när människan sjunker helt in i en aktivitet och går bortom sin reflekterande självmedvetenhet samtidigt som den får en djup känsla av kontroll.

Första gången jag hörde ordet flow var under en presentation på mitt första jobb där jag jobbade som testare. Presentationen hölls av en kille som gång på gång upprepa ordet flow och berättade om hur flow kan uppstå i arbeten. Efter hans presentation bestämde jag mig för att få till ”flowet” i mitt arbete och började jobba effektivt med rätt fokus på de testfall som då skulle testas… Det gick sådär!

Nu, några år senare och några projekt mer erfaren har jag annan uppfattning av begreppet än vad jag hade som en nyexaminerad testare. För mig handlar det mest om att ha de rätta kunskaperna. Vi kan uppleva flow när vi får möjlighet att använda en hög grad av våra färdigheter i utmanande situationer. Balansen måste finnas där och det spelar ingen roll vilket yrke det handlar om.

Utmanande uppgifter där man inte har tillräckliga färdigheter kan ge stress och ångest samtidigt som det kan leda till tristess och minskat engagemang när du har färdigheterna, men inte tillräckligt utmanande arbetsuppgifter. Därför krävs det balans.

Så, vad krävs för att få  flow i arbetet då?

Svaret är enkelt: Ha den rätta kompetensen och färdigheten och att låta de komma till användning i arbetet. Det krävs även ett gott socialt klimat, det vill säga tillit i arbetsgruppen samt möjligheter till samarbete och nytänkande. Flowet uppstår egentligen av den starka drift vi människor har, att med egen förmåga kunna ta oss an en utmanande uppgift. Vi vill uppleva den eufori som flow kan ge oss och vi kan inte uppnå samma eufori genom att bara upprepa något. Vi behöver större utmaningar. Vi drivs av att få lära oss nya saker och just därför är det väldigt viktigt att vi får utbildning och kunskap. När vi sedan får använda dem – då upplever vi flow!

Parinaz Sabzikar,

Test Engineer

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer

Testaren som agil coach – från kval till kvalitet

Det agila projekttåget är i rullning. Men det går för långsamt. Något i projektet har sannolikt gått snett, men ingen verkar veta vad som behöver göras. Det är nu vi agila testare måste ta plats som coacher - i förarsätet. Här kommer argumenten till varför.

Du sitter som ensam testare i ett anonymt mötesrum med ledningen. Du kan svagt höra ljudet från det agila projekttåget strax utanför rummet. Det rullar redan. Ledningen förklarar för dig att projektet överväger att ta in en testare. På frågan om vilken utvecklingsprocess som används händer plötsligt något märkligt. Ledningens annars så självsäkra attityd förbytts till flackande ögon, obekvämt skruvande på stolen, och svaret blir: "Vi arbetar, hm, agilt, ungefär", eller kanske "Vi jobbar scrum-ish". Känner du igen dig? Du är inte ensam.

Om projektet hade gått enligt plan hade antagligen självsäkerheten varit i topp, men nu är det inte så. Något skaver på självförtroendet. Något i projektet har högst sannolikt gått snett. Tåget rullar långsamt. Det är här du som erfaren agil testare måste marknadsföra dig inte bara som testare, utan även som agil coach!

Varför är då en erfaren agil testare bra på coachning i ett stormigt projekt frågar man sig, kanske rentav lika bra som en renodlad projektcoach? Svaret är enkelt. Testdesign och exekvering kommer ofta in som aktiviteter i slutet av en lång process. Alla problem på vägen, från otydliga önskemål hörda på en kundträff till trasslig kod, ansamlas och synliggörs likt en perfekt storm hos testaren. Stormen avtar inte, utan blir allt värre i takt med att den tekniska skulden och berget av buggar ökar. De flesta agila testare är frispråkiga, envisa och ryggar inte för en kamp i motvind. En testare i denna situation ger inte upp sin kamp för förbättringar i  första taget. Är problem självupplevda och dagliga kommer i alla fall inte testaren att låta dem sopas under mattan i första taget!

Den som varit mitt i stormen ett flertal gånger är en person värd att lyssna på. Sannolikt har testaren erfarenhet sedan tidigare, och kan träffsäkert identifiera både orsaker och beprövade förslag att coacha projektet med för att rida ut stormen även denna gång!

Låt oss ta några exempel på vanliga orsaker till stormiga projekt :

·     Otydliga krav. Den erfarna agila testaren bemöter ofta detta med önskemål att plocka följande verktyg ur den agila verktygslådan:  Grooming-sessioner, placering nära utvecklarna, samt krav på godkända acceptanskriterier före testning.

·     Dålig kvalitet. Testare tröttnar snabbt på blockeringar och ständiga regressionstester (samma testfallskörningar om och om igen!) för att testa att de ideliga buggfixarna inte haft någon skadlig inverkan. Du som testare driver i en sådan situation antagligen på för att refaktorisering inplaneras, att Definition of Done (DoD) stramas åt, och att projektet avsätter resurser för analys och eliminerande av huvudorsakerna så att din och dina kollegers uthållighet, humör och självkänsla förbättras.

·     Dålig kommunikation. Agila testare kan inte göra sitt jobb utan bra informella kontakter med utvecklare i en atmosfär av ömsesidigt förtroende. Sådan kommunikation kan vara en bristvara i projektet. Den stressade agila testaren som ofta står utan skriftlig relevant information har dock inget val utan måste driva på för att skapa sådana informella kontaktytor. Detta sätter ofta tonen för resten av projektet som därefter på allvar börjar anamma ett mer agilt sätt att arbeta och kommunicera.

·     Riskhantering. En del tror att riskhantering kan man bortse ifrån i agila projekt då den genom någon form av magi ändå görs. Tyvärr är sanningen att magi endast existerar i sagoböckerna och att denna inställning kommer att straffa sig. I verkligheten är testaren en vital del i agil riskhantering. Testaren genomför varje dag riskanalys genom att fråga utvecklarna om risker - allt för att göra kommande tester i rätt ordning och med rätt omfång (i den oftast riskbaserade testningen). Genom att identifiera och testa områden med risk, lär man känna riskerna bättre och kan göra en mer korrekt bedömning av dessa, vilket gagnar hela projektet. Detta risktänk smittar av sig till övriga i projektet.

Detta var bara några exempel på hur den agila testaren ofta per automatik och utan att reflektera djupare hjälper till att coacha och få det agila projekttåget på banan igen. Varför pratas det då inte mer om detta? Jag tror att vi testare helt enkelt är för dåliga på att marknadsföra oss själva. Handen på hjärtat, vet de som håller i pengarna om att vi gör så mycket mer än att bara skriva felrapporter? Gör de inte det har vi faktiskt hittat ett nytt fel - hos oss själva.

Varför inte sätta upp en mognadsstege liknade CMMI på den agila projekttavlan eller bifoga den till ledningen i din månatliga testrapport och visa på de stegvisa förbättringar test tillför projektet? Gör du det rätt, så sitter ni nog mångdubbelt fler testare i det där anonyma mötesrummet nästa gång. Ledningen kommer att få en insikt och ett helt annat förtroende för utvecklingsprocessen då test öppnat och visat på innehållet i den agila verktygslådan genom sina förbättringsinitiativ.

Kan då något gå fel då med agil coachning som bedrivs av testare?

Ja, så klart. I retrospektivmöten kan problem som identifierats av testare konsekvent röstas ned i demokratisk anda (ofta är utvecklarna i majoritet och röstar kanske enbart på ”sina” isolerade problem). Risken är att viktiga processförbättringar därmed fördröjs "tills dess att snöbollen blivit en lavin".

Hm, detta låter ju inte enkelt att lösa, men låt oss återgå till att tänka på tåget. De flesta tåg har faktiskt passagerarna indelade i olika klasser, kan vi kanske klassa oss testare som lite högre stående och tillåta oss förmånen att alltid få igenom åtminstone en av våra käpphästar på varje retrospektivmöte? Är vi inte värda det?

Svaret på det, kära läsare, tar vi en annan gång i en diskussion om testarens demokratiska värdegrund och om verkligen alla är jämlika eller om testare faktiskt är lite mer jämlika än andra. Ni får gissa er till svaret än så länge.

/Björn Rux,

Test Engineer

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer

Bör ”IT-avdelningar” ens finnas?

”Allt är IT” är en fras som dyker upp allt oftare. Om detta nu är sant, är uppdelningen mellan den så kallade kärnverksamheten och IT-avdelningen då verkligen relevant? Och om den är det, hur kan vi förbättra kommunikationen? År 2016 borde det finnas effektivare metoder än röksignaler och stelbenta ärendehanteringssystem.

I ett av mina första uppdrag som testare - för vad som nu är ganska många år sedan - fanns det ett 

enda sätt att kommunicera med de utvecklare som skrev koden för produkten vi testade: ett felrapporteringssystem. Det säger sig självt att kommunikationen blir ganska bristfällig om det är den enda kommunikationsvägen och ledtiderna var extrema, det tog dagar och ibland veckor att få svar på en fråga eller att få tillbaka den för testare så bekanta frasen ”cannot reproduce”.

Som tur är förändras saker och ting, och kommunikationen är kanske en av de saker som förändrats mest. Jag minns att vi var överlyckliga när vi fick möjlighet att maila direkt till utvecklarna och diskutera den vägen, och senare dök också ett chatprogram upp som ytterligare minskade gapet och tröskeln att ta kontakt. Var de satt hade vi fortfarande ingen aning om, men telefonen tog oss förstås ännu ett steg närmare.

Förändringarna har fortsatt och idag arbetar väldigt många i agila utvecklingsteam där man ofta sitter tillsammans och har ett väldigt tätt samarbete mellan de olika rollerna i gruppen. Vissa har tagit det ännu längre och börjat lösa upp rollerna som sådana – vi är alla utvecklare där vissa kanske har mer fokus på till exempel test, eller så skriver vi kod en dag och testar nästa. Oavsett upplägg så finns det förstås stora fördelar med att arbeta så tätt, inte minst så ökar kunskapen och förståelsen för alla i gruppen avsevärt.

När vi nu brutit ner många av de barriärer som i många fall funnits inom mjukvaruutveckling, så har testarna bättre insikt i koden vilket kan göra det lättare att förstå hur och vad som behöver testas. Utvecklarna i sin tur har en bättre förståelse för testarnas behov, och inte minst så har alla förhoppningsvis god tillgång till kraven och en kravansvarig som kan berätta vad det är kunden behöver.

Här finns det dock enligt min erfarenhet en extremt tydlig gräns: kunden, det vill säga kärnverksamheten, och IT-avdelningen, där nyutveckling och modifiering sker av det IT-stöd som verksamheten behöver.

Är detta verkligen en relevant uppdelning? IT är ju idag en så stor och viktig del av många arbetsprocesser som finns inom ett större företag – ”allt är IT” är en fras som hörs ibland. Om vi nu har sådan närhet i utvecklingsprocessen, varför måste just kraven och verksamhetsförståelsen gå via den ibland trånga tratt som kravanalytikern kan vara?

Den närhet, direkta kommunikation och förståelse för varandra som kommer av att vara ett gemensamt team och gärna arbeta nära varandra rent fysiskt, det är något som skulle kunna gynna både IT och verksamhet.

Testare med god insikt i verksamheten (eller som faktiskt är en del i verksamheten) har en större förståelse för vad som är viktigt att testa, hur tester kan ske och hur de bör prioriteras. De kan förstås också på ett bättre sätt bedöma lämpligheten i en IT-lösning och dessutom göra bedömningar av användbarheten hos systemet.

För en utvecklare är fördelarna likartade, för oavsett hur bra och väl specificerade kraven och designen är, så måste det fattas en mängd beslut under utvecklingsprocessen. Med en god insikt om användarna och användandet blir det lättare att fatta beslut som i slutändan leder till en bättre produkt.

Även verksamheten skulle ha mycket att vinna, till exempel är min erfarenhet att de som ställer krav och kommer med önskemål kan ha svårt att tänka utanför boxen och verkligen tänka nytt. En del i detta är att man inte har någon uppfattning om vilka möjligheter som finns, eller hur svårt respektive lätt det är att genomför vissa idéer. Kanske vågar man inte ställa vissa krav eller så behöver man helt enkelt inspiration utifrån för att tänka om.

Jag säger inte att man behöver eller över huvud taget ska ta över varandras arbetsuppgifter, men bara något så enkelt som att sitta i samma kontorslandskap skulle göra otroligt stor skillnad. Förutom den informella kommunikationen i att ha personer lätt till hands för att ställa frågor, stämma av saker med, snabbt visa eller demonstrera något, så är det mycket information som flyger genom luften som går att snappa upp. Det är denna informationsmängd sammantaget som bygger upp kunskapen, medvetet eller omedvetet.

Som en bonus kan man tänka sig att de som arbetar främst med IT-utveckling kan känna en större tillhörighet till bolaget i stort, när man är närmare bolagets kärnverksamhet, det bolaget ”egentligen gör”.

IT kommer framöver troligtvis bli en allt större del av de flestas arbeten, och med det en förhoppning hos mig att den traditionella IT-avdelningen är dödsdömd. Jag vill uppmana alla som jobbar inom IT att sträva efter en tätare kommunikation med verksamheten, inte bara för att komma närmare detta mål utan för att jag tror det hjälper oss i våra arbeten. Låt oss bara hoppas att vi slipper kommunicera via runstenar eller röksignaler – eller för den delen ett stelbent ärendehanteringsprogram.

/Gabriel Johansson

Kravanalytiker, test manager och lärare

Gabriel Johansson är utbildad interaktionsdesigner på Malmö Högskola och har idag mer än tio års erfarenhet inom test och kravhantering i agila projekt, testautomatisering och usability testing. Erfarenheten sträcker sig över en rad branscher som telekom, logistik, industri, bank och finans samt detaljhandel. 

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer