10 bedste teststyringsværktøjer

Jeg har fundet denne oversigt over de 10 bedste teststyringsværktøjer - det er baseret på en undersøgelse/vurdering ud fra en række kriterier om, hvor godt det enkelte værktøjer understøtter teststyring, testplanlægning, testafvikling, rapportering, opgavestyring, herunder fejlhåndtering og øvrige features som import/export, integrationer m.m.

Listen er følgende:

1. TestRail
2. TestLink
3. JIRA + Zephyr
4. PractiTest
5. qTest
6. TestCollab
7. TestLodge
8. QACoverage
9. TestCaseLab
10. EasyQA

Kender du disse værktøjer og er du enig/uenig i vurderingen - så hører jeg gerne nærmere.

PSQT - Fredagens Workshop og Oplevelser

Så kom jeg til konference ugens sidste dag. En hård uge, men udbytterig. Fredagens indhold er workshops - og jeg havde tilmeldt mig 'Leading an Effective Test Organization with a High Performance Test Team' med Thomas Staab som instruktør. Denne workshop var også modul 4 i IIST's certificeringsprogram CTM (Certified Test Manager).

Thomas Staab indledte med at pointere, at der var nogle nøgleord i titlen på workshoppen: Team, High Performance og Lead. Derefter fulgte en diskussion om disse nøgleord, herunder forskellige typer af teams: Permanente, Virtuelle, Midlertidige.

Så diskuterede vi de forskellige stadier i teamets udvikling med udgangspunkt i FORM, STORM, NORM, PERFORM:

Instruktøren havde dog udvidet den til også at omfatte MOURN, som var en anderledes og spændende udvidelse - idet det ofte hænder når der sker ændringer i teamet.

Derefter diskuterede vi 'the ideal team player' - og han præsenterede tre typer The Pawn (Humble), The Bulldozer (Hungry) og The Charmer (People Smart), herunder forskellige kombinationer af disse. En spændende diskussion fulgte, og forsøgte at sætte os selv ind i typerne.

Så var det tid til at gennemgå Team Building, og der blev de 12 C'er gennemgået:

1. Clear Expectations
2. Context
3. Commitment
4. Competence
5. Charter
6. Control
7. Collaboration
8. Communications
9. Creative Innovation
10. Consequences
11. Coordination
12. Culture Change

Derefter fulgte en gennemgang af udfordringerne ved at lede virtuelle teams, og de er jo rimeligt velkendte - men altid interessant at kigge på i en mere og mere distribueret hverdag.

Så kom emnet 'Resource Management', og herunder emnet 'Multi-Generation Workforce'. Instruktøren præsenterede fire generationer: Traditionalists (Født 1909 - 1945), Baby Boomers (Født 1946 - 1964), Generation X (Født 1965 - 1980) og Generation Y (Født efter 1980). Herefter blev karakteristika for disse fire generationer præsenteret med tilhørende relevante billeder fra musikkens verden. Derefter en god drøftelse af udfordringerne med disse generationer, og deres styrker/svagheder, og selvfølgelig sat ind i kontekst af teamwork.

Så kom diskussion om 'Multi-Cultural Workforce', hvilket åbenbart er meget forskellige i USA i forhold til Danmark - så det vil jeg ikke behandle yderligere.

Så kom vi til 'High Performance Teams' og indledningen var:

1. Has defined what success looks like
2. Actions are guided by specific values
3. Made up of the right people
4. People in the right places
5. Identified barriers to success
6. Planned to eliminate or minimize barriers
7. Conduct periodic progress evaluations

Karakteristikken af et High Performance Team kan illustreres som følger:

Følgende 'trust model' blev også diskuteret, og sat ind i konteksten:

Nogle rigtige spændende drøftelser, og det har sat gang i nogle ideer og tanker hos mig, som jeg lige skal have 'efterbehandlet'.

Derefter diskuterede vi 'Leadership vs Management', 'Politics' og 'Ethics'.

En god og lang dag om teams, men absolut udbytterig.

PSQT - Torsdagens Oplevelser

Så nåede vi til den anden dag med track sessions, og dermed en række til- og fravalg. Men det viser også noget om både bredden og dybden inden for testområdet.

Dagen startede med et hot emne nemlig sikkerhed i form af key noten 'Best Practices for a Mature Application Security Program' med Kevin Poniatowki. Et spændende indlæg der klart viser, at dette område bør jeg nok sætte mig mere ind i - dette skal ses i lyset af tidligere kommentarer/indlæg på denne blog om IoT m.m.

Derefter fulgte track sessions, og den første jeg deltog i var 'Zero SAP Application Defects' med David Pickrell.

Han startede med et statement, som han ofte oplever hos forskellige kunder - 'Jamen, vi har da købt et standardsystem, og SAP laver vel al testen......' - et udsagn som er set og hørt før - både om SAP men også om alle andre leverandører af standardsystemer.

SAP ændres konstant - ABAP/Java ændringer, konfigurationsændringer, ændringer i roller og autorisationer og master data. Han viste et eksempel på en af de seneste opgraderinger fra SAP, som omfattede 948 service packs og 3.953.759 objects - dette viser klart,at effektanalysen af disse ændringer (impact analysis) er utrolig stor.

Så de store udfordringer er bl.a. effektanalysen, testdækning, testgaps, og hvad skal vi teste? Dette illustrerede han i følgende oversigt:

Derefter viste han et værktøj, som kunne hjælpe med disse udfordringer i forbindelse med opgradering af SAP, og som i nogle tilfælde havde fået testen til at blive reduceret med 85%. Dette værktøj kan også integreres med Solution Manager i SAP. Et interessant indlæg, som viste håndteringen af et helt praktisk problem.

Det næste indlæg jeg deltog i var 'An Enterprise Test Strategy for Success' med Susan Schanta. Hun havde et indlæg om en case, hvor hun skulle udarbejde en organisatorisk teststrategi, og i stedet for at tage et traditionelt udgangspunkt - så tog hun udgangspunkt i en mission om, at formålet skulle være at reducere virksomhedens kvalitetsomkostninger, og fokus skulle skifte fra test til kvalitet.

Hendes udgangspunkt var denne figur (Juran et al.), som viser noget om de forskellige kvalitetsomkostninger og det samlede minimum:

Denne figur er faktisk god som dialog værktøj, og som jeg ofte selv bruger når jeg skal i dialog med en ledelse omkring begrebet kvalitetsomkostninger. Figuren viser den principielle sammenhæng mellem kvalitet og omkostninger. Prevention cost er omkostninger til forebyggelse og fejlfinding, og failure cost er omkostninger til interne og eksterne afvigelser. Ved stigende kvalitetsniveau vil failure cost falde og samtidig ved prevention cost stige - figuren viser også det optimale kvalitetsniveau - nemlig der hvor de samlede omkostninger har et minimum - helt traditionelt sund økonomisk tænkning.

Hendes udgangspunkt var spændende, og som hun sagde - dette 'change the conversation'. Strukturen af den organisatoriske teststrategi lignede meget den traditionelle (ISO 29119), men indholdet er helt sikkert anderledes.

Hun omtalte også noget anden spændende - nemlig en 'Productivity Loss Log' - hver gang der var forsinkelser, ændringer m.m. som påvirkede testen - så blev det noteret på denne log, herunder også hvad det kostede. Hun havde også etableret nogle 'Governance Councils' dækkende Automation, Performance, Test Data og Test Environments - med deltagere fra relevante interessenter, og der blev det løbende behandlet hvad der skulle til for at få disse ting til at fungere og være optimale i situationen. En spændende ide, som jeg har noteret mig.

Dagens tredje track session var over emnet 'Test Management by Entities' med Jim Trentadue. Jeg havde valgt dette emne forbi jeg ganske enkelt ikke forstod titlen. Indlægget var et forsøg på at strukturere test inden for nogle 'entiteter' som han kaldte det - altså kombinere roller, ansvar og aktiviteter. Det faglige indhold var ikke særlig stort, men hans form - med utrolig meget dialog og diskussion var til gengæld spændende, og det mestrerede han ganske godt. En af konklusionerne var, at der ikke inden for IT er en disciplin med så meget koordinering som test.

Den sidste track session var 'Driving Ambiguities Out of Requirements through Stronger Test Analysis Techniques' med Susan Schanta. Dette indlæg omhandlede i korte træk - brug vore kendte testteknikker allerede som en del af review. Dårlige krav koster, og derfor bør der være en stor interesse i at forretningsanalytikere og testere samarbejde - deres job er to sider af samme mønt.

Krav drejer sig om 'WHAT (WHO WHEN WHERE WHY), but NOT HOW'. WHAT er forretningen og HOW er IT. Hun kom med en række eksempler på 'dårlige krav' - og hvad konsekvensen havde været for projekterne.

Alt i alt et spændende indlæg, som klar viser at der bør være et højere grad af partnerskab mellem BA og QA, herunder ved udarbejdelsen af tjeklister m.m. Et af budskaberne var også, at kvalitetsomkostningerne kunne reduceres ved at tage krav alvorligt - man betaler altid, nu eller senere, men ved at betale nu kan det ofte være billigere i det lange løb.

Dagens sidste aktivitet var en key note over emnet 'Quality Challenges in the Internet of Things Era' med Phillip Lew. Dejligt med en afsluttende key note over et emne jeg har behandlet nogle gange - derfor henviser jeg bare til disse.

Det var så fjerde dagen af det samlede konferenceforløb. Fredagen venter med en workshop der varer hele dagen.

PSQT - Onsdagens Oplevelser

Så blev det onsdag her i San Diego på PSQT-Konferencen, og dermed den første dag med track sessions - i dette tilfælde 5 parallelle spor, som der skal vælges mellem. Dagen startede og sluttede med key notes, hvor der kun er den ene mulighed.

Dagen startede med åbningsseancen, som var relativ kort og ganske uformel, hvorefter ordet blev givet til Jennifer Bonine til key noten 'Testing Leadership in the Age of Digital Transformation - Are You Adapting?'.

Key noten var indledningsvis en sjov tur ned af 'memory lane', hvor der blev kigget på nogle af de teknologiske fremskridt der var sket de sidste 20 år, herunder også hvornår de skete - nogle gange oplever man jo at den-og-den ting 'altid' har været der, og så viser det sig, at den kun har været på markedet i 8, 9 eller 10 år, eller måske kortere tid.

Jeg fik også fastslået, at jeg er en uddøende race, idet jeg faktisk foretrækker 'fysiske' bøger frem for digitale - jeg bruger digitale versioner af mange af mine bøger, og kan da sagtens se fordelen - vægt, plads m.m. - men jeg foretrækker nu engang de fysiske.

Men ellers gik det over en karakteristik af den moderne 'connectede' menneske, som ikke kan være væk fra de sociale medier et kort øjeblik, herunder de udfordringer der kommer når den 'connectede' generation kommer fuldt ud på arbejdsmarkedet.

Derefter fortsatte key noten over i en drøftelse af IoT, og den påvirkning det giver, og vil give, på vores verden. Men nu skal det jo også handle om test - og der nåede Jennifer frem til at security er noget vi alle skal kende noget til i IoT-verdenen.

I en verden, hvor man 3D printer reservedele til fly - prøv at tænke på, hvis nogle 'onde' personer kunne ændre indstillingerne - så øges risikoen for ulykker. Eller pacemakeren, som kan indstilles via netværket - f.eks. af konen - så betyder det også at den 'sure' kone kan slukke den - så SECURITY er fremtidens fokusområde, sammen med alt det andet.

Men netop med sådanne udfordringer er læring og uddannelse vigtig - og det skal vi huske inden for test. Vi skal altid være villige til at lære nyt - nye teknologier, nye trusler, nye vinkler. Og specielt, hvis man er 'vant' til at teste funktionalitet, og ikke så meget de ikke-funktionelle kvalitetskarakteristikker - så skal man være vågen over for det nye. For disse må forventes at blive vigtigere og vigtigere i en connected verden.

Så begyndte track sessions, og den første jeg valgte var 'No DevOps without Continuous Testing' med Arthur Hicken. Han startede med at henvise til sin IoT-Hall-of-Shame (www.bit.ly/iotshame), hvor han opsamler eksempler inden for IoT til 'ikke-efterfølgelse'. Han startede også med den teknologiske udvikling, og introducerede Sneaker-Net - altså dengang man flyttede data på et fysisk medie og iført sine Sneakers gik til den person der skulle have filerne - en meget sjov indledning. Han fremførte at test må gen-opfinde sig selv. Tiden er, at 'straffen' for softwarefejl er stigende - det påvirker ens brand og mange brancher er udfordret i forbindelse med disse nye ting der kommer på markedet (disrupt eller dø). Vi går fra den traditionelle vinkel og spørgsmål: Er vi færdige med at teste? Til det nye: Har releasekandidaten et acceptabelt niveau af risiko? Men continuous testing kræver og forudsættter automatiseret test - men husk her: det er afviklingen af testen der tales om - selv analysen og designet kræver fortsat brain-ware. Hans synspunkt var også, at vi skal gå fra at være testere til QA'ere. Altså fra at finde fejl til at få et JA, og ellers er det tilbage til udviklerne. Vi skal i højere grad, som del af denne ændring, spørge: Hvorfor har dette nået QA? - Altså når der er fejl - og dermed skal vi også i meget højere grad måle kvaliteten af udviklertesten - tester de det rigtige - både positivt og negativt. Derefter gennemgik han en række cases fra bank, telecom, media, børsmægler.

Den næste track session var 'Metrics Drive Testing Strategy' med Jann Thomas. Efter sædvane blev jeg trigget af metrikker, og hun havde en meget god indledning 'begin with the end in mind' - altså find ud af hvad du skal rapportere - altså metrikker.

Hun introducerede det hun kaldte et 'Test Strategy Map' - se billedet:

Alle metrikkerne blev skaleret til denne oversigt, og alt blev relateret til hendes target, som i diagrammet var 3. Skalaen gik fra 0 til 6, og det initielle arbejde var selvfølgelig at fastlægge target og de andre værdier for alle metrikkerne. Test Strategy Map giver dermed et hurtigt over blik over hvad der er på target, over og under. En spændende tilgang, og en jeg på et tidspunkt må få prøvet af - enten selv eller via en kollega.

Så fulgte en lang pause til dels frokost og dels at besøge expo'et - det følger jo med - runden til de forskellige stande, herunder at modtage forskellige gadgets m.m.

Eftermiddagens første track session jeg gik til var 'Scaling Agile Testing using the TMMi' med Thomas M. Cagley Jr. Det der triggede mig her var selvfølgelig min store interesse for forbedring af testprocessen og brugen af de forskellige modeller til dette - i dette tilfælde TMMi. Det var en glimrende gennemgang af Agile og TMMi - men han nåede desværre ikke helt ud over rampen, og casen han præsenterede var desværre ikke helt forståelig - og det var ikke kun mig :-)

Den sidste track session var over emnet 'Best Practices for Delivering Quality Responsive Web Apps Across All Digital Platforms' med Svetlana Kostinsky. Hun startede med en meget pædagogisk og synlig gennemgang af RWD (Responsive Web Design), med flere gymnastiske præstationer - der måske kunne udvikles til en ny OL disciplin - men hun vækkede klar begejstring hos deltagerne. Men ellers fortalte hun om en undersøgelse af udbredelsen af disse mange devices og operativsystemer, og ikke mindst kombinationen af disse - og præsenterede deres koncept med en dækning ESSENTIAL (Top 10), ENHANCED (Top 25) og EXTENDED (Top 32). Jeg har medtaget undersøgelsen, og der er noget til de af mine kollegaer der arbejder med dette. Godt indlæg - og gode gymnastiske øvelser.

Onsdagen sluttede af med en key note 'Beyond Productivity and Toward Market Dominance - What's Next for Agile as the Great Disrupter' med Michael Mah. En meget levende præsentation med en masse indhold om sin egen person - ganske spændende, og en god afslutning på en lang dag.

En god onsdag med mange spændende input - en enkelt svipser - men nu er der lagt op til torsdagens oplevelser.

PSQT - Tirsdagens Workshop og Oplevelser

Så blev det tirsdag her i San Diego til Practical Software Quality & Testing konferencen. Her havde jeg tilmeldt mig en workshop over emnet 'Managing the Test Process in Agile and Semi-Agile Projects' med Mike Ennis. Igen en ret 'intim' oplevelse, idet der til denne kun var syv deltagere - men igen, det lave antal af deltagere er ikke nødvendigvis dårligt - nærmest tværtimod.

Vi syv deltagere repræsenterede meget forskellige brancher og roller: Bilproduktion, dyrefoderproduktion, offentlig administration, bank, forsvaret og konsulent. Dette gav en række forskellige vinkler og nuancer på emnet, og alle kom til orde med spørgsmål, kommentarer og erfaringer.

Efter en noget lang 'indflyvning' med gennemgang af agile, inkrementielle og iterative udviklingsmodeller, og sammenligning af (primært) vandfaldsmodellen med den agile metode, begyndte der at ske noget.

En af de interessante ting var 'udvidelsen' af det agile manifest - jeg har i hvert fald ikke set dette før. Vi kender selvfølgelig de fire første værdier i det agile manifest, men her blev præsenteret en femte:

'Thorough testing at each time-box over comprehensive effort at end of development'

og det blev kommenteret med følgende: 'An effective agile test strategy must identify the key user stories and test all scenarios as part of each sprint as opposed to waiting until the end to test end-to-end. An automated test suite will allow testers more time to test thoroughly during each iteration'.

En interessant 'udvidelse' af manifestet, som jeg ikke skal forholde mig til juridisk og moralsk her, men det kom til udtryk på workshoppen fra min side.

En anden god ting var, at de fire oprindelige værdier blev italesat i forhold til test.

De agile testing quadrants indgik også i workshoppen (Crispin og Gregory):

Denne model er god når test i agile projekter skal italesættes, men ligeså interessant er det faktisk - synes jeg - at præsentationen af testprocessen i forhold til det agile blev demonstreret ved hjælp af TMap tilgangen og synsvinklen.

Udover dette blev der præsenteret nogle case-eksempler med hensyn til sprintplanlægning, estimering, risikobaseret test og distribueret testorganisation i Scrum.

Det var en god workshop med god dialog med de øvrige deltagere, men den får ikke top-karakter fra min side. Der var ikke så meget 'managing the test process.......' i workshoppen, som titlen havde lagt op til.

Foran står onsdagen, hvor der er keynotes og track sessions. Det er her der typisk skal foretages en række valg..............

PSQT - Mandagens Workshop og Oplevelser

Så begyndte PSQT-testkonferencen her i San Diego, og mandag havde jeg tilmeldt mig en workshop i 'Risk-Based Testing - Analysis and Strategy Development' med Clyneice Chaney som instructor. En præsentator som jeg overhovedet ikke kendte noget til. Det var en lidt 'intim' oplevelse, idet vi kun var 10 deltagere i denne workshop, hvilket til gengæld havde den fordel, at ingen kunne 'gemme' sig.

Det viste sig, at workshoppen faktisk var modul 5 (Risk Management) af IIST's certificering for Test Managers (CTM - Certified Test Manager). En lidt interessant og anderledes model - at en konference faktisk indeholder undervisningsmoduler fra et kursus.

Workshoppen dækkede følgende seks områder - defineret i CTM BOK (Certified Test Manager - Book of Knowledge):

1. Risk Management & Testing
2. Risk Testing Process: Identification
3. Risk Testing Process: Analysis
4. Risk Testing Process: Response Planning
5. Risk Testing Process: Test Strategy Documentation
6. Risk Testing Process: Risk Based Reporting

Indledningsvis blev der gjort meget ud af, at få risici opdelt i tre kategorier: Process Risks, Project Risks og Product Risks. De to første risikokategorier håndteres i testplanlægningen, mens Product Risks håndteres i forbindelse med design og afvikling af testen. En fornuftig opdeling, som giver god mening.

Der blev gennemgået en række metoder og teknikker til identification af produktrisici, herunder involvering af interessenterne. Metoderne var bl.a. tjeklister (en med udgangspunkt i de forskellige kvalitetskarakteristika og en med udgangspunkt i nogle generiske produktrisici, som var opsamlet retrospektivt), product assessment med at stille en række spørgsmål til produktet - både ved nyudvikling og forvaltning. Brugen af interessenternes 'benefit' ved produktet blev også inddraget i vurderingen - spændende betragtning. Formuleringen af produktrisici blev også diskuteret, og der blev der taget udgangspunkt i et IF-statement: IF.....det og det sker THEN kan det få denne negative konsekvens eller resultat.

Så kom selve analysen, hvor der skulle sættes rating på konsekvens og sandsynlighed. Når dette skal ske er der selvfølgelig altid denne diskussion om det skal være kvalitativt eller kvantitativt. Jeg har i en årrække været fortaler for den kvalitative (f.eks. HØJ, MEDIUM, LAV) tilgang, idet jeg altid har syntes det var svært at sætte kroner på konsekvensen og en reel sandsynlighed i procent. Alt dette skal jo anvendes til at nå frem til risikoeksponeringen (exposure) - vi havde nogle gode diskussioner, og selvom jeg fik nogle gode eksempler med, så vil jeg nok fortsat hælde mest til den kvalitative vurdering. Men jeg er da blevet mere åben overfor den kvantitative metode - selvom jeg fastholder at det er ofte meget vanskeligt at fastlægge en ÆGTE kvantitativ værdi på konsekvens og sandsynlighed.

Der blev også præsenteret en anden model til prioritering af testen, hvor der blev inddraget kvalitetskarakteristikker og vigtigheden af disse, og så skulle der gives en rating og denne blev vægtet - dette resulterede så i en samlet risiko pr. område. En spændende metode, som jeg vil se om jeg kan få afprøvet fremover.

Så kom vi til 'Reponse Planning', og her blev der stated klart, at formålet med alt dette er 'find important problems early'. Det der blev behandlet her var beslutningen af teststrategien, hvilket overordnet skulle inkludere et 'statement of minimum level of testing for every area of the product' og en beskrivelse af testdybden: Mainstream (normal use), Guerilla testing, Formally planned testing og Planned regression testing. Her blev også omtalt testteknikkerne, og her kunne det godt mærkes, at det var testmanagere og ikke testanalytikere der var flest af i lokalet. Det udviklede sig til en spændende og noget anderledes del af workshoppen. Der kom, for mig, et nyt begreb ind - nemlig 'Incremental Testing'.

Så kom vi til dokumentationsdelen af strategien - og her kom der en række gode eksempler for 'letvægtsmodeller' og skabeloner. En anden god ting var disse ni punkter der skal huskes ved en god teststrategi:

1. Testing should be optimized to  find important problems fast, rather than finding all problems equal urgency
2. Test strategy should focus most effort areas of potential risks, with some effort on low risk areas
3. Test strategy should address test platform configuration, how the product will be operated and observed
4. Test strategy should be diversified in terms of test techniques and perspectives. Need multiple dimensions of coverage
5. Test strategy should specify how test data will be designed and generated
6. Test strategy should incorporate reasonable variations (exploratory), nog all pre-specified
7. The test schedule should be represented and justified to demonstrate dependencies on progress of development, testability of products, time to report problems and project teams risk assessment
8. Try to keep test process off critical path - extend possible parallel testing and finding problems worth fixing faster than developers fix them
9. Tight feedback loop with development

Afslutningsvis blev forskellige former og modeller for rapportering af produktrisici præsenteret. Der var et par spændende og nye imellem - og jeg glæder mig til at 'dyrke' dette noget mere, idet der til workshoppen og hører et bibliotek af skabeloner - herunder også til rapportering.

Samlet set en spændende første dag - meget intensivt med en workshop med kun 10 deltagere, men dette har selvfølgelig også den fordel, at man kommer tættere på emnet og diskussionerne.

PSQT - Testkonferencen - Starter om få timer

PSQT Testkonferencen i San Diego starter om få timer, og varer hele ugen. PSQT står for Practical Software Quality & Testing. Og det er netop ordet 'Practical' der har trigget min deltagelse i denne konference. Jeg har aldrig deltaget i denne konference før, og mine forventninger er derfor store.

De to første dage er der workshops: Mandag deltager jeg i 'Risk-Based Testing: Analysis and Strategy Development', tirsdag i 'Managing the Test Process in Agile and Semi-Agile Projects'. Onsdag og torsdag er der keynotes og concurrent track presentations. Fredag er der igen workshop, hvor jeg deltager i 'Leading an Effective Test Organization With a High Performance Test Team'.

Jeg glæder mig til at opleve hvad denne konference kan give os, og ikke mindst om der er en forskel i forhold til STAR-konferencerne.

PSQT arrangeres af IIST - International Institute for Software Testing (www.testinginstitute.com). Udover træning og konferencer har de faktisk også deres eget certificeringsprogram.

Traditionen tro 'rapporterer' jeg mindst en gang om dagen i ugens løb fra konferencen - og husk: Der er 9 timers forskel.

STAReast 2016 - The Testing & Quality Leadership Summit

Fredag deltog jeg i 'The Testing & Quality Leadership Summit', hvor årets tema var 'Leading the Change within Your Organization'.

Der var et par spændende indlæg om 'Creative Leadership for Creative Teams' og 'Leading through Change' - og det er altid spændende at få lidt input, som er baseret på egne oplevelser og synspunkter.

Derefter var der en række rundbords-diskussioner om emnerne. Diskussioner som typisk bærer præg af, at deltagerne kommer fra vidt forskellige kulturer. Danmark med en meget lav magtdistance, modsat USA med en meget høj.

Men det blev en glimrende afslutning på en fantastisk uge på STAReast.

STAReast 2016 - Torsdagens Oplevelser

Så nåede jeg frem til afslutningen på selve konferencedelen af STAReast 2016.

Torsdagen startede med en keynote af Isabel Evans over emnet 'Telling Our Testing Stories'. Hun lagde ud med en historie om, hvornår og hvordan hun mødte Lee Copeland (program chair for STAReast) i Barcelona for mange år siden. Et godt eksempel på, at vi alle er historiefortællere - og ofte i mange forskellige roller; forældre, søskende, undervisere, venner og kollegaer. Når vi fortæller historier er det ofte fordi vi ønsker at opnå noget, og det påvirker den måde den fortælles på. Denne keynote var en god start på torsdagens øvrige program.

Den første track session jeg deltog i var under temaet metrikker, og mere specifikt emnet 'Quality Metrics - The Dirty Word in the Room' af Annette Ash. Hun havde en ganske god introduktion til emnet med udgangspunkt i de mere traditionelle testmetrikker som testcases og defects, men havde lidt erfaring med, at de ofte blev brugt til at skabe en kile mellem udvikling og test, hvor de måske skulle være til at skabe et partnerskab. Hendes oplevelse var også, at ledelsen typisk elsker metrikker - det er tal.

Metrikkerne ender ofte med at være for kompliceret, en fordel kun for ledelsen, og det fik testerne til at gå efter opfyldelse af tal, og dermed reelt til at straffe og belønne - nok ikke det bedste udgangspunkt. Hendes nye tilgang til metrikker var, at de skulle være lette at forstå, være teamorienteret, nemme at indsamle og være handlingsorienteret. Faktisk var de gået fra at kalde det metrikker til mål (goals).

Forud for værktøjs introduktionen havde alle i teamet læst bogen 'Clean Code', og haft møder hvor emnerne i bogen blev diskuteret og drøftet i forhold til implementering hos dem. Det endte så med værktøjet SonarQube - som bl.a. kan måle dækningen af komponenttest, beregne kompleksitetstal m.m.

Det anvendte værktøj var SonarQube - statisk analyse værktøj - www.sonarqube.org

Den anden track session jeg deltog i var også over temaet metrikker, og med emnet 'Defect Metrics for Organization and Project Health' med David Bialek. Spændende indlæg om en situation, hvor indlægsholderen var ny i en virksomhed uden nogen form for formaliseret fejlhåndtering med tilhørende rapportering og metrikker. Efter han begyndte at formalisere det er der sket et løft i modenheden hos virksomheden, og specielt de betalende interessenter (forretningen og brugerne) har haft stor glæde af dette - og basalt set er de jo også mere interesseret i resultatet end i selve teknologien. Det første skridt han tog var at etablere en 'bug list' - simpelt, men stærkt, derefter kigge på Root Causes - er typisk noget der kan tage lang tid, men også med en stor effekt, og så til sidst fokus på løsninger. Rapporteringen af ganske traditionel, men når der er tale om en virksomhed uden nogen form for historik, så kan det også være ganske virkningsfuldt.

Den tredje track session jeg deltog i var over emnet 'Evolve or Die - What Testers Need to Do to Survive and Thrive' med Michael Cooper. Der sker ændringer konstant inden for test og QA, og alene de teknologiske ændringer giver hele tiden behov for, at vi som testere ændrer os (tilpasser). De seneste teknologiske ændringer er eksempelvis digital og IoT, cloud, big data og mobil. Hans budskab var meget tydeligt - den der overlever er den der er villig til ændringer. Han talte også om at sætte sig nogle karrieremål, og finde ud af, hvilke færdigheder man skal have for at opnås disse. Karrieremålene kunne jo være både som generalist og specialist - budskabet var igen - foretag et valg.

Et spændende indlæg, og det giver altid stof til eftertanke, men der var måske lidt for meget fokus på penge - altså sætte sig et mål for, hvad vil jeg tjene om X år - og så gå efter det. Men det er jo altid en smags sag.

Så kom konferencens sidste keynote med Dawn Haynes over emnet 'The Evolution of a Software Tester - From Novice to Practitioner'. Et mere personligt præget indlæg om hendes 'rejse' inden for softwaretest. Måske en god afslutning på nogle hektiske dag.

Torsdag sidst på eftermiddagen er der kick-off på 'Testing & Quality Leadership Summit', som foregår fredag med indlæg, behandling af 'concerns' fra kick-off, 'think tanks' og rundbordssamtaler.

STAReast 2016 - Det Fysiske Udbytte

STAReast 2016 - Onsdagens Oplevelser

Så blev det tredje dagen på STAReast-konferencen, og dermed en dag med mange flere forskellige indtryk og oplevelser. Hvor mandagen og tirsdagen har været fyldt med halvdags tutorials, så er det om onsdagen, at der er track sessions. Ved track sesions kører der 6 parallelle faglige præsentationer og 3 tekniske præsentationer (sponsorerne) - så der skal tilvælges og fravælges. Udover dette kører der også nogle generelle sessioner kaldet Keynotes.

Morgenen startede med, at Lee Copeland officielt åbnede konferencen, og introducerede den første keynote.

Den første keynote var over emnet 'Lessons Learned in (Selling) Software Testing' med Keith Klain. Han havde skiftet fra 'køber' til 'sælger' siden, og det var spændende (og underholdende) at høre hans syn og oplevelser fra den vinkel. Han havde et par gode budskaber: Fokuser på den forretningsmæssige værdi af test over for ledelsen, og ikke om selve test. Tal ikke om test, men om hvad det giver - altså resultatet, men i forretningsmæssige termer. Han havde også et lille indspark til testmanagere - i skal være 80% 'hands on' med hensyn til testen, gem jer ikke bag skærmen og møder - vær synlige og aktive. Og hvis man lægger op til fri diskussion, så accepter at der kan (og vil) være forskellige synspunkter, og tag dette seriøst (var det et lille indspark i forhold til enkelte individer i den context drevne verden - hvad ved jeg?). Totalt set en god start på morgenen.

Onsdagens anden keynote var 'Open Source Test Automation - Riding the Second Wave' med David Dang. Det lykkedes ham at gøre et måske lidt nørdet emne spændende - ved hjælp af lidt selvironi og humor. Den første bølge af open source test automation omfattede værktøjer som Fitnesse, Ruby/Watir og Selenium RC, og han viste nogle eksempler på, hvorfor det kun var en delvis succes, og så lavede han et flot skifte over mod den anden bølge, som omfattede: Selenium WebDriver, Cucumber (BDD), Robot Framework med key-word driven automatisering, som nogle af dem han nævnte. Han omtalte følgende årsager til, at disse blev mere populære: Bedre support (også fra store veletablerede virksomheder og organisationer), bedre API, bedre integrationer, mindre instrumentering kræves, support af populære metoder som f.eks. BDD. Samlet set - et nørdet emne gjort spændende.

Han henviste til følgende hjemmeside: www.opensourcetesting.org

Så begyndte de forskellige track sessions, og som før nævnt, dermed også en masse valg - til og fra.

Den første track session jeg valgte var 'Helpful Practices in Agile Testing' med Jeroen Mengerink. Hans udgangspunkt var det aktuelle for mange organisationer - et skifte fra de sekventielle udviklingsmodeller til agil udvikling. Han havde mange guldkorn, og her kommer et af dem: 'Hvis man vil arbejde struktureret med agile, må man lære den strukturerede teknikker, herunder testteknikkerne'.

Grundlæggende var hans tese, at agil test drejer sig også om mere bløde værdier i form af tættere samarbejde, tekniske emner som drivere og stubbe og vidensdeling indenfor test på tværs af teams og indenfor teamet på tværs af roller. Han lagde meget vægt på de bløde værdier og teamudvikling.

Han brugte bl.a. den efterhånden kendte model: FORMING - STORMING - NORMING - PERFORMING. En god referencemodel til illustration af, hvad der sker i teamet ved ændring i sammensætningen:

• Forming: lærer om hinanden
• Storming: udfordrer hinanden
• Norming: arbejder med hinanden
• Performing: arbejder som EN.

Det der er ideen her er, at man principielt starter forfra ved en ændring af teamets sammensætning - så pas på. Han omtalte også en visualisering af målet som en god ide - uden at visualisere dette yderligere!  Men når vi som testere deltager i et agilt team, hvad vi så bidrage med - udover at teste. Vi kan introducere testteknikker til udviklerne, vi kan udfordre designet og forretningsanalysen med WHAT-IF scenarier og udfordre Product Owner på, hvilke test der skal udføres.

Jeroens udgangspunkt var også, at mange at de discipliner der ellers anvendes, og bør anvendes ved agil udvikling og test. På området teststrategi/testfremgangsmåden var det emner som HVAD og HVORNÅR vi tester, få test integreret som del af udviklingen, der testes i alle sprints, og ikke mindst: tillad afvigelser til strategien - få defineret den tilladte båndbredde. Den tilladte båndbredde kunne typisk påvirkes af risikoen, modenheden, færdigheder, produktet/systemet, størrelsen, tid og kulturen. Dette var en rigtig spændende betragtning, og viser noget om den ønskede fleksibilitet som man ofte ønsker sig. Hans budskab var klart - tag stilling på forhånd. Jeroen gjorde sig også til talsmand for brug af forskellige testniveauer - men med respekt for noget af det grundlæggende i agil udvikling - vi stoler på hinanden - så vi skal ikke gentage en test, hvis det er gennemført før.

Anvendelsen af PRA (ProduktRisikoAnalyse) blev også omtalt, og gerne på flere niveauer: End-2-end, release og user story. Han sluttede af med at pointere, at omkring end-2-end test er det vigtigt at huske, at det er bredere end sprintet og, sandsynligvis også, teamet. Et godt indlæg, som klart 'skar ud' af den store agile kage, hvad der er vigtigt.

Den anden track session jeg deltog i var 'Ensuring Maximum Quality in the Era of IoT and Wearables' af Gauri Arondekar. Mit udgangspunkt var, at emnet er spændende - også set i lyset af en af de tutorials jeg deltog i tidligere på ugen. Gauri startede med en hurtig opsummering af, hvad IoT drejer sig om, men kom desværre hurtigt til at dreje sig om et konkret værktøj (som hendes virksomhed pudsigt nok også havde udviklet og solgte - stor overraskelse, og stor skuffelse).

Men der var dog enkelte generelle guldkort i forhold til test af IoT og Wearables. Hun kom ind på en række udfordringer der typisk er for test på dette område: testinfrastrukturen (miljø, stubbe, drivere, data m.m. - som alt sammen er en forudsætningen for teste), prioritering af testen (anvendelse af risikobaseret test eller anden form for udvælgelse af test, integrationer (seamless integration mellem ofte meget forskellige teknologier) og skalering (løsningerne er forskellige og load kan være meget forskellig).

Hun sluttede af med et godt statement ved test af IoT og Wearables - opbyg en kultur hvor der testes 'as a user'. Nok en meget god pointe.

Dagens tredje track session for mig var 'The Road to DevOps - Data, Environment and Test Automation' med Tanya Kravtsov. Hun startede med at definere DevOps som:

• Culture
• Automation
• Monitoring
• Sharing.

Ordet automatisering indgik ekstremt meget i indlægget, og hun sluttede af med at sige, at med DevOps kunne man opnå 50 builds om dagen, fuldt testet og produktionsklar. Det var spændende og lærerigt, MEN jeg er nok lidt skeptisk over hendes generelle tilgang til al ting - som tester er man nok lidt skeptisk når det ser for godt ud.

MEN hun lagde ud med nogle gode tanker om 'identify bottlenecks' i relation til miljøer, testcyklusser og de manuelle processer. Hun omtalte de kendte teknikker til det: brainstorming, mind maps, interviews og retrospectives, men omtalte også Speed Boat Game, hvor der man forsøger at identificere de ankre der holder os tilbage - spændende betragtning, og jeg kan ikke lige huske, at jeg har set den tidligere præsenteret på den måde og med det navn. Og da jeg elsker at sejle, er det nok en jeg vil afprøve fremover.

Onsdagen sluttede af med 'Lightning Strikes the Keynotes' - hvor der kommer en række indlægsholdere op i 5 minutter, og præsenterer et emne - som sædvanligt både sjovt og interessant.

STAReast 2016 - Tirsdagens Oplevelser

Så er jeg kommet igennem anden dagen af STAReast 2016, og dermed også de sidste 2 tutorials i denne omgang. Generelt vil jeg sige, at niveauet er højt, og dermed er der også et klart udbytte.

Tirsdagens program for mig var de 2 halvdags tutorials jeg valgte forud for konferencen - om formiddagen 'Test Attacks to Break Mobile and Embedded Software' og om eftermiddagen 'What DevOps Means for Testers - Tips for Getting Testers Involved'.

Oplægsholderen til formiddagens tutorial 'Test Attacks to Break Mobile and Embedded Software' - Jon Hagar - lagde ud med at det var en AKTIV tutorial, hvor der skulle fremlægges testmetoder og diskuteres disse, men der skulle også TESTES. Selv lagde han ud med en App på sin mobil der styrede PC'en - og dermed også slideshowet. Så vi overværede testen af denne, og det blev klart at der var både funktionelle og performance issues. Det var en oplevelse, og jeg tror nok, at hvis det havde været mig havde jeg hurtigt gået over til fall-back proceduren, og taget min Logitech Presenter i anvendelse.

Hans udgangspunkt var risiko-baseret test, og det fremgik klart, at han havde forstået konceptet, og opdelingen i de forskellige risikotyper, og han var også en fortaler for den 'nye' internationale teststandard ISO 29119 - det er ikke ofte jeg hører nogen omtale den positivt.

Han lagde ud med en hurtig til området, herunder de forskellige typer af Mobile Apps: Native Apps, Web Apps og Hybrid Apps. Det virkede som en god ting i forhold til forståelsen af nogle af de efterfølgende områder og emner. Native Apps fungerer lokalt på Devicen. Web Apps fungerer alene ved interaktioner via nettet. Hybrid Apps er så både-og.

Det testmæssige udgangspunkt var Exploratory Testing, Attacks og Taxonomy. Det var ikke så meget et enten-eller, men mere et både-og. Det blev også nævnt anvendelsen af de formelle testteknikker som en integreret del at Exploratory Testing og Attacks.

Jon Hagar har opstillet følgende Attacks - jeg har valgt ikke at oversætte disse for at sikre, at der ikke går noget tabt:

1. Static Code Analysis
2. Finding White-Box Data Computation Bugs
3. White-Box Structural Logic Flow Coverage
4. Finding Hardware-System Unhandled Uses in Software
5. HW-SW and SW-HW Signal Interface Bugs
6. Long Duration Control Attack Runs
7. Breaking Software Logic and/or Control Laws
8. Forcing the Unusual Bug Cases
9. Breaking Software with Hardware and System Operations, including Breaking Battery Power
10. Finding Bugs in Hardware-Software Communications
11. Breaking Software Error Recovery
12. Interface and Integration Testing, including Configuration Integration Evaluation
13. Finding Problems in Software-System Fault Tolerance
14. Breaking Digital Software Communications
15. Finding Bugs in the Data
16. Bugs in System-Software Computation
17. Using Simulation and Stimulation to Drive Software Attacks
18. Bugs in Timing Interrupts and Priority Inversion
19. Finding Time Related Bugs
20. Time Related Scenarios, Stories and Tours
21. Performance Testing Introduction
22. Finding Supporting (User) Documentation Problems, including Confirming Installability
23. Finding Missing or Wrong Alarms
24. Finding Bugs in Help Files
25. Finding Bugs in Apps
26. Testing Mobile and Embedded Games
27. Attacking App-Cloud Dependencies
28. Penetration Attack Test, including Authentication and Password Attack and Attack Fuzz Test
29. Information Theft - Stealing Device Data, including Identity Social Engineering
30. Spoofing Attacks, including Location and/or User Profile Spoof Attack and GPS Spoof Attack
31. Attacking Viruses on the Run in Factories
32. Using Combinatorial Tests
33. Attacking Functional Bugs

En utrolig spændende og anvendelig oplistning af mulige Attacks. De fleste af disse Attacks skal selvfølgelig altid tænkes ind i den konkrete kontekst, herunder også det fokus som den risiko-baserede testtilgang viser.

Tirsdagens anden tutorial var 'What DevOps Means for Testers - Tips for Getting Testers Involved' - med Jeffery Payne - og mit mål var bl.a. at prøve at få en dybere indsigt i begrebet DevOps.

Indledningsvis blev der opstillet en generel definition af DevOps - har valgt at beholde det skrevne uden oversættelse:

• DevOps is a software development method that stresses communication, collaboration and integration between software developers, QA and information technology professionals
• DevOps it not a tool
• DevOps is not a methodology
• DevOps is a philosophy for how people interact within the software development supply chain

Når jeg kigger på denne definition kommer jeg umiddelbart til at tænke på 'accelereret agil'. Hele ideen med DevOps synes jeg er spændende, idet man her forsøger at komme den klassiske konflikt til livs. Med den klassiske konflikt mener jeg de forskellige synspunkter der er mellem UDVIKLING og DRIFT, hvor udvikling hele tiden har behov for at implementere ændringer og driften er bange for ændringer, da det kan udfordre deres mål - stabilitet, tilgængelighed, oppetid m.m.

Det var en god tutorial i forhold til at forstå konceptet DevOps med begreber som Build Automation, Continuous Integration, Check-In Builds, Nightly Builds, Continuous Delivery and Continuous Deployment - men det kneb lidt med tips til at få testerne involveret.

Men igen - alt i alt - en god dag her i Orlando til STAReast-konferencen. 

STAReast 2016 - Mandagens Oplevelser

Så gik starten på årets STAReast 2016 i Orlando (Florida). Mandagens program bestod af 2 heldags tutorials og 12 halvdags tutorials - typisk udfordring for en tester - vil gerne det hele, men der er det problem, at man jo kun kan være et sted af gangen. Så der skal foretages et valg - og det sker typisk ved tilmeldingen - en heldags tutorial eller to halvdags - og emnet skal også vælges på forhånd. Mine valg for mandagen var om emnerne 'Testing the Internet of Things' og 'Successful Test Automation - A Managers View'.

Forventningerne til dagens to store emner var tilsvarende også store.

Formiddagen foregik i selskab med en mindre skare af testere - ikke alle er åbenbart interesseret i dette emne: 'Testing the Internet of Things'. Oplægsholderen var Jon Hagar, og han havde en lille robot med, som skulle testes, og dette indgik i øvelserne til denne tutorial.

Jon Hagar indledte med en gennemgang af principper/arkitekturen for IoT (Internet of Things), og hvad er en IoT Device: Software som er en del af et stykke specialiseret hardware, mobile devices, netværk, cloud og it - ELLER lettere omskrevet: IoT er traditionelle og nye devices med software og kommunikationskanaler tilknyttet.

Aspekterne ved IoT er spændende, og måske også lidt skræmmende. Forestillingen om, at 'alt' er forbundet. Perspektiverne er helt klart spændende rent forretningsmæssigt, og brancher som transport kan helt sikkert se store muligheder, men også inden for sundhed og sikkerhed er der ganske klart muligheder og perspektiv.

Men man kunne godt mærke på indlægsholderen og spørgsmål og kommentarer fra deltagerne, at sikkerhed er et emne der præger billedet.

Det testmæssige var naturligvis i fokus, og et ofte anvendt begreb var 'field test' - det skal prøves af i praksis.

Det første område der behandlet testmæssigt var anvendelsen af angreb (attack), som en vigtig teknik til brug ved test af IoT, og der blev opstillet 33 'attack pattern examples' - for her at komme med eksempler kan jeg nævne: Udfør statisk analyse af koden, bekræft installerbarhed, tidsrelaterede scenarier og 'testing tours' m.m. En oplistning som kan give en række ideer til testen.

En anden teknik var anvendelse af taksonomier (klassifikationer af data), og hvor de fejl der findes over tid klassificeres i henhold til taksonomien. Denne viden anvendes så ved de angrebs-test der skal udføres. En taksonomi anvendes netop til at opnå forståelse og viden om området. Det var lidt spændende, at der blev anvende Mind Map til etablering af taksonomierne, hvilket var interessant at se.

Der blev nævnt et par forskellige kvalitetskarakteristikker, men sikkerhed (security) blev nævnt meget ofte, og ikke mindst i forhold til personfølsomme oplysninger (Privacy), hvor vi normalt jo ikke ønsker at få disse lagt til offentlig beskuelse.

Begrebet modelbaseret-test blev også nævnt et par gange, hvorfor det nok skal dyrkes lidt mere i fremtiden. Men nyt er det også for mange, at med IoT er det ikke kun softwaretest, men også hardwaretest, og interaktionen mellem disse der er i scope, og målet med testen.

Jeg vil her henvise til det blogindlæg jeg skrev for nogle uger siden om emnet i forhold til den bog Sogeti netop har udgivet.

Der er ingen tvivl om, at test af IoT er stort, og kompliceret. På TestExpo i januar talte jeg om bl.a. dette emne, og min konklusion var klar på det tidspunkt. Vi er der endnu ikke - som testere. Vi har endnu ikke alle teknikkerne, værktøjerne, teknisk viden og miljøerne, viden om dataanalyse m.m.

Dagens anden tutorial var 'Successful Test Automation - A Managers View' med Dorothy Graham. Jeg citerer hende ofte for udtalelsen 'A Fool with a Tool is still a Fool'. Det er nogle år siden jeg sidst har hørt et indlæg fra hende, og det var også denne gang en god oplevelse.

Jeg faldt lidt for denne tutorial grundet det ikke-tekniske - altså alt det andet der omkranser testautomatisering som værktøjer, script-sprog m.m.

Der blev indledt med en drøftelse af målet med testautomatisering, og hvad der bør automatiseres. Udgangspunktet var, at det var vigtigt, at det der blev automatiseret var den 'gode' test. Hvis man automatiserer en dårlig test får man jo alene en hurtigere dårlig test. Hvis startpunktet er en dårlig manuel test er det vigtigt først at gøre den manuelle test god, og derefter automatisere den. En rigtig interessant udlægning, og jeg fik nogle nye perspektiver på dette tema, som jeg klart kan anvende i min hverdag.

Men den gode målsætning for testautomatisering er:

• Realistisk og opnåelig
• Både kortsigtet og langsigtet
• Løbende opdateret
• Målbar.

Der blev opstillet en række pattern som var hendes udgangspunkt for en succesfuld testautomatisering:

• Set Clear Goals
• Sell the Benefits
• Automate the Metrics
• Do a Pilot
• Automate Good Tests
• Testware Architecture.

Hun talte også om ROI (Return On Investment) i forhold til testautomatisering, og opstillede også den generelle formel. Men jeg syntes der manglede lidt kød her. Det er heller ikke et nemt område, men det er vigtigt. Vigtigt fordi vi som testere skal have 'funding' af et eventuelt testautomatiseringsprojekt hos ledelsen - og ROI er typisk ledelsessprog.

Hun talte en del om hvad der skal automatiseres og hvad der ikke skal, herunder hvad hun kaldte 'what can be lost in automation'. Her tænkte hun på forhold som awareness, brugerperspektivet, intuition, variationer og fleksibilitet.

Dot Graham havde også nogle synspunkter omkring begrebet dækning, og det glædede mig, at vi er helt på bølgelængde der.

Alt i alt en god mandag her på STAReast. Jeg håber og tror på, at resten af konferencen bliver lige så spændende og udbytterig.

STAReast 2016 - Starten går om 3 timer

Så skal vi til det igen - en uge med en masse nye indtryk, oplevelser og ny lærdom.

Stedet er Orlando i Florida, emnet er softwaretest, konferencen er STAReast, året er 2016.

Konceptet følger de andre års - mandag og tirsdag er der hel- eller halvdags tutorials, onsdag og torsdag keynotes og de kortere konferenceindlæg, og fredag sluttes af med en heldags session om ledelse i test og kvalitet.

Jeg vil på denne blog skrive indlæg hele ugen om de forskellige præsentationer, indlæg og indtryk. Mandag deltager jeg i 2 halvdags tutorials, og det samme tirsdag. De er valgt på forhånd, og heldigvis var jeg i lidt god tid med reservationen, da de godt kan være 'udsolgt'.

 

De to tutorials mandag er 'Testing the Internet of Things' og 'Successful Test Automation - A Manager's View'. Tirsdag deltager jeg i 'Test Attacks to Break Mobile and Embedded Software' og 'What DevOps Means for Testers - Tips for Getting Testers Involved'.

 

Jeg har store forventninger til ugen, og glæder mig.

Fra SMAC til SMACT

Jeg har i et par indlæg både på denne blog og ved forskellige konferencer omtalt begrebet SMAC (Social - Mobile - Analytics - Cloud), men må nu sande, at det det nye begreb er SMACT (Social - Mobile - Analytics - Cloud - Internet of Things) - så nu er er SMAC og IoT blevet integreret i èt - SMACT - hvilket også giver mening.

Men spørgsmålet er fortsat - er vi klar til disse nye teknologiske udfordringer rent testmæssigt - på TestEXPO i slutningen af januar 2016 forsøgte jeg at svare på dele af spørgsmålet, og min konklusion var, at på områderne Mobile og Cloud var vi der faktisk, men på Internet of Things - der er vi ikke endnu. Der er masser af udfordringer rent testmæssigt, hvilket jeg vil addressere i løbet af foråret.