I maj 2007 planterades fröet till det träd som ska bära frukt för första gången omkring september månad. Då bildades en arbetsgrupp med uppgift att ta fram en samling nya standarder för mjukvarutestning och som nu kommer att publiceras om någon månad. Som en av de två personer som utgör den svenska arbetsgruppen vill jag därför göra er uppmärksamma på vad som väntar, så att ni inte blir tagna på sängen när saker väl börjar hända.
Gamla klassiker
Det finns en mängd domänspecifika standarder som till exempel DO-178-B för flygindustrin, MISRA för fordonsindustrin och EN 50128 för järnvägsindustrin. Med andra ord är de flesta relaterade till säkerhetskritiska system. Problemet är dock att en del av dessa standarder har besynnerliga krav för hur saker ska testas. I några av dem finns det specificerat att test ska utföras, vissa tekniker ska användas och specifika kodtäckningsnivåer ska uppnås, men då saknas definitioner för processer, tekniker och hur man ska mäta täckningsnivån.
Om man lyfter blicken och tittar på mer generella standarder hittar vi ”klassiska” standarder som IEEE 829 för dokumentation och BS-7925-2, som innehåller en testprocess för enhetstestning, men i huvudsak definierar olika tekniker för att designa testfall. Problemet med dessa är att de har några år på nacken. IEEE 829 reviderades senast 2008 och BS 7925-2 har inte reviderats sedan den publicerades 1998.
ISO/IEC/IEEE 29119 – Den nya standarden
Målet med ISO/IEC/IEEE 29119 är att den ska vara en heltäckande internationell standard som täcker in områden som tidigare varit förbisedda eller motstridiga. Målet är också att den ska kunna appliceras på både traditionell och agil utveckling. För att undvika att uppfinna hjulet på nytt har man därför ärvt in både IEEE 829 och BS 7925-2 då IEEE inte avser att fortsätta underhålla denna och ett antal andra standarder.
I dagsläget består standarden av fem delar plus en utvärderingsmodell. Denna modell är under utveckling och kommer heta ISO 33063. De fem delarna och deras status är följande:
- Concepts & Vocabulary (ligger ute för slutomröstning)
- Processes (ligger ute för slutomröstning)
- Documentation (ligger ute för slutomröstning)
- Testing Techniques (kommer att genomgå slutomröstning i slutet av året)
- Keyword-Driven Testing (under utveckling)
En intressant resa
I januari 2011 anslöt jag mig själv till arbetsgruppen för att få bättre inblick i vad standarden innehöll och framför allt kunna påverka innehållet. Vid den tidpunkten var Ola Perman från Tieto i Karlstad den enda aktiva svenska delegaten.
Under mina aktiva år har vår stora stötesten varit att få fram en standard som verkligen ska passa både traditionella och agila utvecklingsprojekt, samt att det ska vara enkelt att finna alla ”shall” krav för att organisationer och företag i slutändan ska kunna certifiera sig. Eftersom projektet snurrat sedan 2007 har det inte varit helt enkelt att i efterhand förstå alla besluten och den politik som omger framtagandet av en standard. Men efterhand har vi fått mer och mer gehör för våra synpunkter.
I slutet av maj fick jag omsider själv möjlighet att deltaga på arbetsmötet som ägde rum i Montreal. Planen var att framföra ytterligare synpunkter på hur man skulle kunna förbättra standarden. Tyvärr gick detta om intet då tre av delarna låg ute för slutomröstning (som nämnts ovan). Istället kom arbetet att handla om vad som hade gått bra och mindre bra under framtagande av dessa delar samt vad som behöver göras framöver.
Med spåkulan i handen
Vad kommer då framtiden och ISO/IEC/IEEE 29119 erbjuda, en inrutad vardag eller nya möjligheter? Många företag och organisationer försöker idag arbeta agilt medan andra är mer eller mindre tvingade att följa uppsatta processer. Men även om man arbetar agilt finns det i grund och botten någon form av process. Utöver detta ska man även basera sitt arbete på ”sunda tekniska principer”. Man kan också se det som att även den mest erfarne personen behöver en ledstång att hålla sig i ibland. Vidare finns det organisationer som inte utvecklar systemen själva utan beställer och integrerar dem med sina befintliga och vissa har, eller funderar på att ha, utlokaliserade testavdelningar. Dessa organisationer behöver försäkra sig om att leverantörerna tar testningen seriöst.
Oavsett vilken situation eller roll organisationen eller företagen befinner sig i kan standarden, eller delar av den, vara till stort stöd vid upphandlingar, processförbättring och en rad andra aktiviteter. Exakt vilken påverkan standarden kommer att få på din organisation går inte att förutspå idag. En möjlighet är att det kommer som ett krav, i upphandlingar eller val av partners, att man ska vara certifierad enligt ISO/IEC/IEEE 29119. Självklart finns många frågor kvar att besvara. Det som arbetsgruppen diskuterade var att ta fram ett antal tekniska rapporter för att belysa och hjälpa till att applicera dem inom olika områden, som till exempel agil utveckling, outsourcing samt dess förhållande till förbättringsramverk som TPI Next.
Det primära är att redan nu börja fördjupa sig i innehållet för att förbereda sig och skapa affärsmöjligheter istället för att få en inrutad vardag när det blir ett krav att följa standarden. Det är nu det finns utrymme att komma med åsikter, inte när kraven på att följa standarden trillar in som ett brev på posten.
Intressant! Hittade följande på nätet: http://sqa.stackexchange.com/questions/750/will-the-new-iso-iec-29119-software-testing-standard-work-with-agile-methodologi
Lite äldre post, men kul läsning.
Oj oj oj då var första dagen på semestern förstörd, jäkla internet!
Jag ska försöka att hålla detta skapligt kort.
hmm, men var ska jag börja någonstans.
Låt oss börja från början och slänga ett öga på http://www.softwaretestingstandard.org och se vad det står där. Vi kan ju börja med första stycket:
“The aim of ISO/IEC 29119 Software Testing is to provide one definitive standard for software testing that defines vocabulary, processes, documentation, techniques and a process assessment model for software testing that can be used within any software development life cycle.”
Är det någon mer än jag som får ont i magen av att läsa detta?
“to provide one definitive standard for software testing”
Så vi släpper inte illusionen av att det finns endast ett bra sätt att göra testning på. Till råga på allt så är den definitiv vilket jag tolkar som att den inte kommer att uppdateras för vi kommer aldrig lära oss något nytt utan vi kan allt redan så den är från början perfekt.
“can be used within any software development life cycle.”
Och detta sättet fungerar i ALLA tänkbara och otänkbara sätt att utveckla mjukvara.
Låter detta rimligt? Är det någon som skulle känner sig bekväm med att de personer som är involverade i framtagande av denna standard faktiskt kommer uppnå vad dom lovar?
Min fråga till dig Magnus är känner du dig kvalificerad och tillräckligt kunnig för att skapa det ni lovar?
Fan, jag skulle skita i brallan om någon förväntade sig detta av mig!
Nu kan man kontra med att jag men denna standard är så flexibelt skriven så att den innehåller “allt” och den går att anpassa till oändligheten. Om så nu är fallet så undrar jag vilken nytta men har av en sådan standard?
Sen har vi problemet att väldigt många tror jag inte kommer att läsa, tolka och applicera denna standard på det sättet utan man kommer missbruka innehållet som ett regelverk. Mangus skriver själv det som en möjlighet att det kommer som ett krav i upphandlingar av partners att man ska var ISO29119 certifierad. Detta skulle vara förödande och om så blir fallet vilken nytta har vi då av en sådan standard?
Vad ni gör är att ni ger de som inte vet något om testning en giltig ursäkt att inte lära sig yrket utan kan bara peka på att man följer en iso standard. Vilken nytta har vi av en sådan standard?
En annan fundering jag har är nu när ni skapar en definitiv standard, alla vi som inte håller med om innehåller eller utför testning på annat sätt, gör vi då i era ögon inte testning?
Jag skulle nu kunna gå in på vad det är för smörja som den här standarden faktiskt innehåller men då kommer jag inte kunna hålla mig kort som jag lovade ovan. Jag ber er istället kika på detta och litar på att ni känner lukten av dynga.
http://www.softwaretestingstandard.org/part2.php
Har ni någon livsgnista kvar som ni vill släcka så kika gärna vidare på de övriga delarna av standarden och fundera på om ni verkligen vill att detta ska vara eran “definitive standard for software testing”.
Men jag måste medge att Magnus verkligen lyckas fånga essensen av syftet med den nya standarden när han skriver “för att förbereda sig och skapa affärsmöjligheter”. Ni är ju i alla fall ärliga med era intentioner. ***************Här har redaktionen på testzonen som ansvariga utgivare tagit bort 2 meningar av innehållet som kan uppfattas som personangrepp ***************
Mina sista två meningar togs bort då det av någon anledning kan tolkas som personangrepp.
Nä men sluta nu, det var väl inget personangrepp?
Men ok, jag omformulerar mig då det inte var en enskild person jag avser att gå till angrepp mot utan mot en hel hög personer och företag.
Det är viktigt att förstå vad drivkraften bakom att ta fram denna standarden kommer ifrån. Detta gör vi när vi ser bakom de fina löftena som dom slänger sig med och börjar läsa vad dom verkligen säger.
Syfte med att skapa denna ISO standard som Magnus väljer att lyfta fram är att “hitta nya affärsmöjligheter”. Man kan skriva detta med lite tydligare språk, “att tjäna pengar på den nya ISO/IEC 29119 standarden”. Man skapar en ny guldgruva för oseriösa konsultföretag som med hjälp av denna ISO standard kommer späda på illusionen av att företag måste anpassa sig till den nya standarden för att kunna visa att testing sker på ett bra sätt.
Denna standard kommer legitimera att inkompetenta konsulter och konsultföretag som inte kan någonting om testning kan fortsätta sälja sina tjänster genom att skrämma upp sina kunder.
Vi har sett detta mönster förut med ISTQB och i denna nya standard är det till mångt och mycket samma människor som står bakom så det är samma mönster som kommer att upprepas då man uttryckligen gör detta för att skapa affärsmöjligheter.
Så återigen undrar jag vilken nytta men har av en sådan standard?
För att undvika att bli censurerad vill jag verkligen understryka att jag ovan inte riktar mig mot en specifik person eller företag utan det mönster som främjar en oseriös verksamhet som finns i våran bransch.
Jag hoppas att du hade en trevlig semester fram tills du läste artikeln, i alla fall. Ser att ditt svar kom mitt i natten, så… kanske kvällen var kul? 😉
Alltså jodå… jag får faktiskt också lite ont i magen av detta. Det här med standarder är inte MITT sätt att tänka. Men å andra sidan kan alla inte tänka likadant som mig, precis på samma sätt som vi anser att det inte går att testa all programvara på ETT sätt. Att det faktiskt bara är i sagorna som det finns “en ring att sämja dem, en ring att främja dem, en ring att djupt i mörkrets vida riken tämja dem”.
Det kommer alltid att finnas testare som håller till på ena sidan standardiseringsskalan och sedan sådana som står på den andra sidan av denna. Det kommer alltid att dyka upp nya saker som vi, på vår planhalva, anser mest bara är till för att göda de som vill roffa åt sig pengar från oroliga och okunniga (genom att dra igång 2-dagars certifieringskurser och ta 23000 kr för dessa). Liksom det alltid kommer att finnas människor som tycker att det finns en riktig nytta med dessa standarder. De ser dem som en måttstock på hur mycket de kan om test/kvalitetssäkring så att deras kunder känner att de kan förvänta sig åtminstone en godtagbar lägstanivå på de konsulter de anlitar.
Då finns det också de som kommer at tjäna pengar på att utfärda de certifikat som visar att man följer den nya ISO/IEC 29119 standarden.
Vilken av dessa approacher som är mest seriös – kan inte jag bestämma. Men min personliga åsikt är att båda egentligen är seriösa, precis på samma sätt som att det på en dejtingsite finns de som “söker ett seriöst förhållande” och de som bara vill ligga. 😉 De… är ju båda seriösa, på sitt sätt. En del vill känna säkerhet genom att gå, och att även lära ut, ringens väg – medan andra vill ha lite mer frihet och rock’n’roll.
Men nä. Jag ser nog, personligen, inte heller den riktiga nyttan man kan ha av en sådan standard.
Jag är för standarder som handlar om att definiera interface, mätvärden och dylikt. Exempel kan vara RFC2544, som ett hjälpmedel i Ethernet kommunikation. Men även sådana standarder kan vara problematiska.
När vi har standarder på hur vi jobbar eller hur vi som människor kommunicerar begränsar vi oss och hämmar utveckling.
Jag arbetar inte på en institution på universitetet, men jag forskar och filosoferar på egen hand. Jag försöker hjälpa testvärlden genom att dela med mig av mina idéer. Jag försöker, efter bästa förmåga, följa vetenskapliga metoder där jag för ett bra resonemang och argumentation i det jag gör. Jag vill känna friheten i att kunna gå bortom vad någon satt upp som en standard eller gräns, inom tänkande och hur man arbetar.
Här är lite exempel på situationer som är relaterade till standarder, kanske lite extremt dock:
* Lyssna på episod 9 av Rupert Sheldrake – http://www.cbc.ca/ideas/episodes/2009/01/02/how-to-think-about-science-part-1—24-listen/
* Fundera över de standarder som kyrkan satte upp, men som Galileo Galilei trotsade – http://sv.wikipedia.org/wiki/Galileo_Galilei
Intention med denna artikel var att informera om att en ny standard är på väg och inte att få någon att sätta kaffet i fel strupe.
Jag har under mina år stött på processer som varit allt för rigida men jag har även sett situationer där det inte funnits någon styrning alls. Vissa organisationer är behjälpta av processer medan andra har väldigt erfarna medarbetare att luta sig mot. Jag vill dock påpeka att standarden bara inte bara täcker in processer utan även t.ex. dokumentation. Oavsett om man tycker standarder är av godo eller ej så är det för många branscher ett faktum då de är väldigt styrda av processer och standarder. Många av dessa branscher kommer säkert att ha ett intresse i att titta på ISO/IEC 29119.
När det gäller standarder behöver man inte använda allt som står i dem, dvs. man behöver inte ha “Full Compliance” utan kan även vara “Partly Compliant”. Tycker man inte att det som är specificerat i standarden passar det sätt man arbetar på så behöver man inte använda den eller så använder man bara vissa delar.
Oavsett detta så ligger “affärsmöjligheterna” i att företagen internt kan använda dessa för att skapa bättre förutsättningar för att effektivisera sitt arbete, ta fram rätt avstämningspunkter, harmonisera arbetet eller vad man nu kan tänkas ha för mål. Det viktiga är innehållet i standarden och därför har arbetsgruppen fokuserat detta och inte vad som står på en webbsida vilket återspeglas i att den inte uppdaterats sedan februari 2012.
Avslutningsvis är det upp till varje organisation, oavsett om man är leverantör eller beställare, att avgöra om man önskar arbeta enligt ISO/IEC 29119.
Intressant att du skriver att vi inte ska bry oss om det mål, syften och löften som ni publicerat. Kan du klargöra för oss vilka andra löften som ni skriver eller säger det är som vi andra också ska ignorerar. Tänker mest så att vi inte får fel bild av vad det är ni försöker uppnå, vi vill ju inte ha fel förväntningar på er!
Jag är inte emot processer, alla företag, projekt, team, individer har processer för att utföra våra sysslor (dokumenterade eller odokumenterade). Det är inget konstigt eller fel i det. Det som däremot riskerar att bli väldigt fel är när en grupp människor tar på sig uppgiften att skapa regler för hur vi ska utföra vårt arbete, detta helt utan att känna till eller ta hänsyn till varken miljön eller förutsättningarna som reglerna ska verka i.
Du skriver att ni inte bara inkluderar processer utan även dokumentation. Under mina verksamma år är det väldigt få gånger jag kunnat använda mig av exakt samma typ av dokumentation två gånger. Hur ska ni kunna skapa regler för dokumentation som ska vara optimal för alla under alla olika omständigheter. Detta känns för mig helt orimligt.
Vad ni gör är att ni häller sirap i systemet genom att ni förser organisationer med era färdiga lösningar så att personer slipper att själva tänka och komma fram till vad som egentligen är bäst under deras förutsättningar. För så länge dom följer ISO29119 så är det ju i er mening en garanti för väl utförd testning.
Ni kommer genom detta att få organisationer att leva i tron om att dom har en effektiv testning så länge som dom är certifierade. Ni bygger på detta sättet bort motivationen för viktiga element som viljan att experimentera, inovation, att självkritiskt granska sitt arbete, att utvecklas vidare, att ta in nya intryck som ligger utanför det som står i standarden. Är man certifierad så är viljan att våga gå emot standarden och på så sätt riskera bli av med sin certifiering väldigt låg.
Igen, ni kommer att få människorna i organisationer att sluta tänka och utvecklas genom rädslan av att mista sin certifiering då den är beviset för väl utförd testning eller tjänsteföretag som inte kommer få uppdrag om dom inte är certifierade (detta skriver du själv som ett önskvärt scenario).
Igen, här kommer erat favorit argument upp: Man kan som organisation själv välja att följa en standard eller ej eller bara delar av den. Ok det är ju nobelt av er men om det nu verkligen är så ni ser på det innehåll ni tar fram. Varför gör ni det då till en standard och till råga på allt slänger på en certifiering på detta?
Det rimmar väldigt illa mer att ni vill att alla ska få välja fritt!
För är man certifierad så skriver du ju själv att det signum för att “man tar testning seriöst”
Så hur vill ni egentligen har det?
1.Det ni skriver på er sida ska vi inte lägga något värde i!
2.Ni pratar om flexibilitet och valmöjligheter!
3.Ert agerande följer ett mönster som ska får företag att följa och certifiera sig efter er standard.
Inget av dessa tre hänger ihop!
Jag tror definitivt att det finns ett värde av certifieringar (enligt Cem Kaners argument ) och standardiseringar i framtiden.
Det vi har idag är inte tillräckligt bra, och utnyttjas ibland av företag och arbetsgivare på ett oönskvärt sätt.
Därför tror jag det är viktigt att så många som möjligt engagerar sig i dessa arbeten på sikt. De krävs nog testvärldens skarpaste hjärnor (som t.ex. Hendrik och Magnus) för att få det på plats, och många, många iterationer.
Det behövs standarder som är tillräckligt abstrakta för att ge testexperter fritt spelrum att använda sin erfarenhet, och för att de ska vara applicerbara inom olika branscher, men ändå detaljerad nog att ge något stöd åt noviser och ha någon som helst mening. Vet inte hur relevant Dreyfus modellen () är nu för tiden när det gäller lärande och skicklighet, men mina tankar baserar sig lite på den. Är detaljnivån för låg blir den meningslös, och är den för hög så är den inte kontextoberoende och lämnar inget rum för erfarenhet och skicklighet.
Kommer ISO/IEC/IEEE 29119 att lösa alla våra standard-problem? Jag gissar på nej. Kan det vara den första av många iterationer för att få fram något bra som alla (många?) kan enas om? Det får framtiden besvara.
Tycker det är ett spännande ämne definitivt, men ett väldigt svårt problem att lösa. Omöjligt? Kanske. Man kanske ska fundera på standarder kring olika sub-områden om det inte går att ta fram någon universell standard? Standard för medicinsk testning, standard för inbyggda system testining, standard för applikationstestning, standard för back-end system, etc. Vem vet.
Sen finns det alltid personer eller företag som försöker tjäna pengar på detta arbete genom att ge ut olika certifieringar/standarder som inte är av något värde, och det är så klart tråkigt, men samtidigt borde det sporra testvärlden till att gemensamt försöka lösa problemet själva istället för att låta andra göra certifieringar och standarder åt oss.
Sen måste det också vara klart att en standard inte är en stämpel på att tillräcklig testning har utförts, eller att testningen har hög kvalitet, som Hendrik säger. En sådan standard kommer aldrig att finnas. Däremot kanske uppfyllnad av standard säger något om utvecklings/test organisationen beroende på kontexten. Tror detta måste utvecklas mer – vad är syftet med standarden från ett företagsperspektiv (varför vill jag uppfylla den som företag – är det skillnad i motivation mellan små och stora företag?), och vad säger det att en organisation uppfyller den? Så att man inte ger fel signaler till beslutsfattare. Kanske finns det redan.
Sen vill jag inte tänka på arbetet som krävs för att upprätthålla en universell standard och en tillhörande certifiering, för att det hela tiden ska vara relevant. Och varje uppdatering kräver flera iterationer för att det ska bli bra.
Har varit en intressant diskussion att ta del av Hendrik och Magnus. Tack för att jag får något att läsa och tänka på under semestern 🙂
Jag reserverar mig rätten att ändra mig i framtiden angående allt jag har skrivit om jag skulle ändra uppfattning 🙂
/Johan
Länk till Kaners tankar kring certifieringar:
http://kaner.com/?p=317
Länk till Dreyfusmodellen:
http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition
Intressant ämne och diskussion som jag inte riktigt kan hålla mig utanför då jag vill ifrågasätta och belysa kundnyttan lite mer.
“Målet med ISO/IEC/IEEE 29119 är att den ska vara en heltäckande internationell standard som täcker in områden som tidigare varit förbisedda eller motstridiga. Målet är också att den ska kunna appliceras på både traditionell och agil utveckling.”
Ojojoj, det var inga dåliga mål. Jag gillar iofs att sätta upp höga mål, “Aim for the stars and reach the skies!” men dessa målformuleringar sätter i mina ögon tyvärr hycklar-stämpel på arbetet. Det är synd då grundtanken att hjälpa företag med tips och tricks för hur man kan utföra testning är god, men snälla försök inte att påstå att det finns ett universellt sätt att utföra testning på, det faller på sin egen orimlighet.
Jag har alltför många gånger sett problem för företag som förlitat sig på sk experter som lurat kunden att anta en viss process eller verktygssvit och med våld gör allt för att anpassa företagets projekt för denna process/verktygssvit. På detta sätt riskerar kunden även bli inlåst och tvingas använda “experternas” arbetssätt och/eller verktygssvit under en längre tid. Detta är helt bakvänt enligt mig då man först måste se till projektets och organisationens uppbyggnad för att kunna förstå lämpliga angreppssätt och hjälpmedel för att uppnå maximal kundnytta i det specifika projektet.
“Vidare finns det organisationer som inte utvecklar systemen själva utan beställer och integrerar dem med sina befintliga och vissa har, eller funderar på att ha, utlokaliserade testavdelningar. Dessa organisationer behöver försäkra sig om att leverantörerna tar testningen seriöst.”
Ett företag ska självklart försäkra sig om att de jobbar med seriösa leverantörer men att denna standard ska hjälpa till med detta ser jag som en riktigt stor och farlig risk. Om en person på ett företag med låg kunskapsnivå inom test läser detta skulle han/hon kunna förlita sig på att det enda som krävs av en leverantör för att få seriös testning är att denne uppföljer standarden vilket som nämnts ovan är befängt. Det är att grymt försök att sänka anseendet för testning som profession men framförallt lurar man kunden att förlita sig på en standard istället för att göra det jobb som krävs för att hitta rätt leverantör för det specifika projektet.
Detta fenomen kan vi se redan idag då företag inom vissa branscher ställer liknande krav och förlitar sig på viss standard/certifieringsuppfyllnad. Detta är inte nödvändigtvis fel i sig men ofta blir resultatet utdragna upphandlingsprocesser, extra jobb för att checka av standard-kriterierna (som i många fall inte är relevanta för projektet) vilket leder till ökade kostnader för kunden utan att nödvändigtvis ha bidragit till bättre testning eller högre kvalitet.
Så jag ställer mig frågande igen, på vilket sätt hjälper detta verkligen kunden som funderar på att lägga ut testansvaret på en leverantör?
Svaret skulle kunna vara att kunden då stolt kan säga att “vårt nya system uppfyller ISOXXX” och därför kunna sova bättre om natten eller skylla ifrån sig om projektet skiter sig. Dock är detta en falsk trygghet då det som sagt inte kan garanterar en seriös leverantör utan snarare underlättar för lata oseriösa bolag som letar genvägar istället för att göra grovjobbet att lära sig testyrket på riktigt.
“Det primära är att redan nu börja fördjupa sig i innehållet för att förbereda sig och skapa affärsmöjligheter istället för att få en inrutad vardag när det blir ett krav att följa standarden.”
Jag gillar verkligen affärsmöjligheter men föredrar att skapa dem utifrån rätt förutsättningar dvs att hjälpa kunden att skapa bestående resultat. Inte genom att slänga sig med ISO nummer eller obegripliga förkortningar på certifieringar för att intala någon (vare sig utövare eller beställare) att tro att det är några viktiga kriterier som ger skottsäkert skydd för bra testning.
Jag ser fram emot att framöver besvara kundens påstående; “Men ni är ju inte ISOXXX certifierade.” med “Det är precis därför som ni behöver mig!”.
/Håkan
Här kan man läsa vad Michael Bolton, James Bach, Cem Kaner mfl tycker i frågan: http://www.uploads.pnsqc.org/2011/slides/Bolton_StandardsAndDeviations_slides.pdf
Jag tror att problemställningen är otroligt viktig om man ska skapa en standard. Vilket problem är det vi försöker lösa, och varför är en standard en bra lösning för.
Sen är nog definition av vad man menar med en standard också viktig. Alla vet ungefär vad man menar, men ser säkert olika på detaljerna. Också vilken abstrationsnivå som är lämplig för standarden och varför.
Och allt detta måste man förklara på ett enkelt, konkret och förståligt sätt så att folk inte tror att man bara försöker sälja certifieringar, ge folk en falsk trygghet i att uppfyllande av en standard löser alla problem, eller tvinga folk att jobba efter detaljerade steg-för-steg instruktioner oberoende av kontext. Är förklaringen alltför komplicerad är det lätt att folk inte orkar sätta sig in i det.
Men detta kanske redan är klart för alla, och kanske redan finns beskrivet – jag är trots allt inte väldigt insatt i ämnet.
/Johan
Det som finns att läsa i Håkan Rambergs länk ovan säger väl det mesta om hur pass illa standarder och test rimmar med varandra.
Riktlinjer och checklistor – gratis tillgängliga för de intresserade – är en bra idé.
Standarder och certifieringar – för dyra pengar tillgängliga för de okunniga – är en dålig idé.
Kul att se att den här frågan diskuteras flitigt. Tack Magnus för artikeln. Jag tror diskussionen om ISO/IEC/IEEE 29119 är viktig, även om jag tyvärr inte har mycket gott att säga om vad som presenteras.
“En möjlighet är att det kommer som ett krav, i upphandlingar eller val av partners, att man ska vara certifierad enligt ISO/IEC/IEEE 29119.”
Ja, det är en av riskerna (inte möjligheterna) jag ser med den här standarden. Inte nog med att upphandlare och köpare att testtjänster redan idag kastar in en massa skall-krav som de inte har en aning om vilket egentligt värde (eller kostnad) det har för deras egen organisation i slutändan, nu kommer det även troligtvis tvingas in ytterligare skräp som vi som arbetar med test måste spendera tid och pengar på att certifiera oss inom. Måste? Ja, antingen det eller välja att hålla på våra principer och då bli diskvalificerade hos köpare som inte har en aning om vad de köper, eller hos välmenande men farligt oinformerade projektägare och affärsfolk som inte “har tid” att sätta sig in i problematiken och som ser best practices och silver bullets vart de än går, och gärna tar en genväg om den här ISO eller IEEE i namnet. (Vad kostar den “tidsvinsten” deras aktieägare i slutändan…?)
Men är det då inte bra att det skapas en standard så att köpare kan känna sig mer trygga i vad de köper kanske något då tänker? Nej, inte när det handlar om något så pass kontext-beroende som mjukvaruutveckling. Att det finns en standard innebär inte att köpare helt plötsligt kommer att bli mer informerade om vad det innebär att testa mjukvara. Istället kommer det vara ytterligare en möjlighet att strunta i att förstå någonting om vad det innbär att testa mjukvara och fortsätta att köpa grisen i säcken i ännu större utsträckning än idag. Jag ser inte hur det kommer att vara möjligt att säga: “Vi följer ISO/IEC/IEEE 29119, alltså leverar vi värdefull testning och meningsfull information.” Men det är tyvärr vad många oinformerade stakeholders kommer att tro att det innebär.
Vad som behövs är fortsatt utbildning och dialog med våra stakeholders, i syfte att skapa förståelse för att vi som sysslar med mjukvaruutveckling är involverande i ett kreativ, undersökande och prövande arbete. Vi behöver fortsätta förklara att vi arbetar oss fram mot lösningar på problemen vi fått förklarade för oss, vägledda av principer och tidigare erfarenheter, men väldigt sällan av “standarder”. Och vi kan naturligtvis prata om dessa principer och förklara och försvara dom, och ta dessa till hjälp när vi ombeds estimera eller rapportera progress och status. Men att standardisera det praktiska användandet av en princip är lika otänkbart för mig som att säga till en boxare att han eller hon kommer att vinna mot alla motståndare, så länge som en viss exakt slagkombination används, oavsett vad som händer. Däremot så är /principerna/ att boxaren bör hålla upp garden och inte stå stilla generellt sett två goda råd.
Våra principer och heuristiska metoder har dock väldigt lite att göra med de stadardiserade, abstrakta och nätinstill intetsägande processer liknande vad jag exempelvis ser här: http://softwaretestingstandard.org/part2.php. Efter att en kort studie av diagrammen på den sidan (som jag innerligt hoppas att ni i arbetsgruppen vid det här laget har kastat i papperskorgen) kan jag lite våghalsigt prova att sia om framtiden och säga att vi i bästa fall snart får bevittna födelsen av en alternativ version av RUP… Och eftersom den här standarden kommer att ha bokstäverna ISO och IEEE så kommer det innebära ännu en välmenande men alltför stor, komplex och preskriberande process som sväljs med hull och hår av branschen och där fokus kommer hamna på att vara “compliant” snarare än på att göra ett gott arbete. Med andra ord… vi är tillbaka i ett träsk av arbete som utförs och dokument som upprättas, för att processen säger att det ska utföras, och all tänka på nytta och värde är som bortblåst. Igen.
@Magnus, du skriver att en av era stötestenar har varit att komma fram till något som även ska passa i agila projekt. Baserat på det lilla jag sett på organisationens hemsida kan jag verkligen tänka mig att så är fallet, och jag kan applådera att ni lyfter den frågan till dagordningen. Men en del arbetsdokument ligger ut för slutomröstning nu som du säger, så, kommer dessa delar av processen hjälpa även organisationer som arbetar agilt? Om inte, varför inte arbeta för rösta ner dessa förslag och gå tillbaka till ritbordet om nu målet är “en standard för alla”?
Jag upprepar vad många redan har sagt: Vad är nyttan och värdet med denna standard? Vem hjälper den egentligen? Jag får känslan att den försöker vara lösningen på ett problem som inte finns!
Jag ser inte en inrutad vardag i min framtid, för jag tror inte att det går att arbeta såhär pass “inrutat” oavsett vad standarder säger. Vad jag ser är möjligtvis en svårare vardag, med ännu en nytillkommen, meningslös och felanvänd förkortning som kommer att slås i mitt huvud om och om igen i olika upphandlingar och projektplaner.
Hade det varit möjligt att sätta upp en wiki-sida där man jobbade med en teststandard, där alla fick vara med och hjälpa till, och där olika förslag röstades fram av community:n?
Där abstraktionsnivån, målet, och alla detaljer bestämdes av alla testare gemensamt på något slags demokratiskt sätt? Där allas röster gjordes hörda, men någon slags konsensus ändå nåddes?
Där alla kunde hjälpa till så mycket de kunde, ville och hade tid över.
Där uppdateringar kunde föreslås av vem som helst så fort nya idéer och innovationer togs fram.
Där all vår gemensamma erfarenhet och kunskap kodifierades i den mån något sådant är möjligt.
Är något sådant möjligt? Hade det varit önskvärt att ha en sådan wiki? Vilka problem hade en sådan wiki skapat?
/Johan
De potentiella problemen är tyvärr många.
Man kan säkert få en demokratisk process i rullning, men det garanterar långt ifrån konsensus. Mer troligt är att åtminstone någon kommer att vara oenig med vilken abstraktionsnivå man bör lägga arbetet på och vips så försvinner den personen från projektet och därmed även blir “bredded” av överenskommelsen lidande. Till slut kanske man kommer fram till ett demokratiskt beslut, men om man inte har konsensus så kommer den ändå troligtvis inte adopteras annat än av skaparna, och då är vi tillbaka i samma läge vi har idag med olika “skolor”. (Oavsett om man vill kalla dom skolor eller ej. Jag själv bryr mig föga om stämpeln.)
Jag tror att motsatsen är mer effektivt. Det vill säga att vem som helst kan beskriva ett sätt att utföra någon viss typ av testning, till exempel “automatiserad integrationstestning med hjälp av Java” och kan sedan till exempel (men inte nödvändigtvis) se om andra testare som har behov av det verktyget vill hjälpa till att utveckla den metoden. Andra testare väljer att använda sig av den eller inte och med tiden så blir det antingen en de facto-standard som merparten av testare utgår ifrån, eller så förkastas den och faller i glömska, helt organiskt.
Ett exempel som ligger ganska nära till hands är sessions-baserad testning. Finns ett grundläggande ramverk som är väldefinerat och testkört av ett fåtal personer som sedan publicerat det för omvärlden att ta del av. Många använder det idag och många utgår ifrån just det grundläggande ramverket och bygger vidare på det för att få det att passa sin kontext. Försök skriva om historien och få 10-20 personer att sätta sig när och diskutera: “Hur ska vi skapa ett ramverk som ger bättre spårbarhet (m.m.) till utforskande testning?”. Chans att lyckas ~=0. (Design by committee-problematiken)
Vad är då rimligt? Jo, kanske en wiki där man gemensamt, utan att nödvändigtvis har konsensus, skapar en “ordlista” där man med samma organiska process kan skapa en form av standardiserat språk. Förutom att det troligtvis aldrig kommer bli helt standardiserat då just konsensus är den svåra biten. Men, det spelar mindre roll i min mening om det finns 3 eller 4 definitioner på vad “systemtestning” är. Jag tror ändå det kan finnas en nytta i att hitta just dom 3-4 oliak sätten att se på saken på ett och samma ställe.
Sen är ju detta något som i och för sig man har försökt sig på förr utan särskilt stor framgång -> (länk), vilket även det kanske talar för hur stört omöjligt det vore att designa en allomfattande standard för all testning i en kommitté, eller via en wiki.
Men allt är inte negativt! Att kodifera vår gemensamma kunskap står jag helt och hållet bakom i princip! Kodifiera och dela med er! Jag bara tror inte att kunskapen ska/kan kodifieras av en kommitté, och jag tror inte att den ska vara tvingande att användas. Och bara för att ett wikiprojekt har fallerat en gång betyder inte det att det inte kan lyckas nästa gång, och det bara drivs med energi, positivt tänkande och ett accepterande av att konsensus inte behöver uppnås för att andra ska kunna dra nytta av arbetet.
Mer open source-tänk i kunskapsutbytet och mindre auktoritärt “detta är vad du ska använda, punkt slut”-trams.
Gemensamt kommer vi hitta bra verktygslådor i slutändan, och dessa kan kanske till och med bli så bra att man kan lockas att kalla dom för standarder. Men dagen vi slutar ifrågasätta och lära oss ifrån våra egna och varandras erfarenheter är dagen vi se över våra testare-mindset på allvar och fråga oss vad vi egentligen håller på med som får oss att tro att vi kan gå på autopilot från kontext till kontext.
Bra kommentarer. Håller med dig i mycket. Hade tyckt det var awesome om man hade lyckats ska en framgångsrik test-wiki sida. Tråkigt att det misslyckats tidigare.
Det här verkar ju vara helt fantastiskt. Tänk när denna gyllene “best practice” som så många allt för länge har sökt, utan att finna, är färdig. Ett litet, smidigt, lätthanterligt dokument som talar om exakt hur man ska hantera varje uppkomling situation. Efter det borde det vara en enkel match att skriva ihop ett litet program som automatiskt sköter all testning av alla produkter i hela världen. Fatta vad företagen kommer spara pengar!
Vi “oseriösa testare”, som vägrar certifiera oss men som arbetat länge med att förfina vår testteknik samt bredda och dela med oss av våra erfarenheter, får helt enkelt ta oss i kragen och skaffa oss “riktiga” jobb istället. Verkar som om vi inte kommer behövas länge till.
En observation:
Alla utom Magnus själv som har kommenterat här är väldigt kritiska till denna ISO standard.
Om man nu har lagt kraft och energi på att göra en ISO standard för testning så hade jag förväntat mig att det skulle finnas en klar majoritet med JA-sägare som applåderar ankomsten av denna ISO standard.
Men var är ni alla JA-Sägare? Varför lyser ni med er frånvaro?
I Sverige finns det rimligtvis två stycken, Magnus C. Ohlsson och Ola Perman.
Kan ni inte bemöta den kritik, oro, frågeställningar och skepticism som framkommer av de kommentarer som har postats här.
Jag tänker att ni måste ju veta någonting som inte vi andra vet som gör att ni inte ser de farhågor och problem som vi gör.
Kan ni inte dela med er av er kunskap och upplys oss så att även vi får en möjlighet att ställa oss i JA-sägar ledet.
Arbetet med att ta fram denna standard har pågått sedan 2007 och resultatet kommer att presenteras i september i år skriver Magnus ovan. Det är med andra ord försent att försöka hindra publikationen; ISO/IEC/IEEE 29119 kommer att bli en del av vår verklighet oavsett om vi gillar det eller ej.
Jag är en ganska ny testare. Jag bestämde mig för att skola om mig mitt i livet och kom in på Nackademins yrkeshögskoleutbildning hösten 2011. Strax efter nyår 2013 var jag och mina kursare i den första årskullen testare från Nackademin klara. Vissa av mina förväntningar på utbildningen och yrket har infriats, andra har det inte.
I början av utbildningen hade jag den djupaste respekt för allt jag fick lära mig och när ISTQB presenterades utgick jag ifrån att det var en accepterad branschstandard. Idag skäms jag över att ISTQB foundations var examensprovet efter 1,5 års studier.
Min farhåga är att ISO/IEC/IEEE 29119 kommer att presenteras som en självklarhet för intet ont anande studenter på testutbildningar framöver och på så vis kommer nya generationer av testare stöpas i denna mall. Det vore olyckligt och till och med potentiellt farligt om det blev så.
Så jag hoppas att ni erfarna testare som kommenterar här mot den nya standarden gör det till er uppgift att bry er om vad som bestäms i de ledningsgrupper som sammanställer kursplaner för testare på olika lärosäten runt om i landet!
Sedan är det ju förstås upp till var och en att ta diskussionen på sin arbetsplats. Om det nu inte går att hindra ISO/IEC/IEEE 29119 från att publiceras så får man hindra implementationen av den istället.
Jag älskar standarder!
Speciellt när jag ska beställa brädor eller skruv och muttrar…
Jag tycker nästan att det räcker med att konstatera att om det har tagit över 6 år att ena de som ens är intresserade av att ha en standard, hur långt ifrån verkligheten befinner man sig då?
De kompromisser som har gjorts under dessa år är ju avsteg från hur några människor anser att testning ska bedrivas. Och då representerar ju den här gruppen bara en delmängd av den totala gruppen testare som också har åsikter/erfarenheter/resultat om hur testning ska bedrivas.
Många bra argument i frågan som jag håller med om har redan sagts (bl.a. från Henke, Martin och Johan J).
Men jag har en fråga vars svar kanske skulle kunna bidra till att skingra röken:
Finns det någon ISO-standard för akademisk forskning?
/Henrik
Jag tänker mig att det måste finnas massvis med ISO-standarder inom akademisk forskning. Standarder för hur rapportering ska se ut, hur forskningsmiljöer ska se ut och hur metoder ska utformas för att forskningsresultatet ska bedömas relevant och giltigt. Resultatet ska också kunna bedömas och vägas mot andra forskningsresultat inom samma område. ISO-standarder som stödsystem, det är min bild av forskningsvärlden och lite nätsök kring saken ger mig en fingervisning att jag verkar vara inne på rätt spår. Egen erfarenhet saknas.
Det finns också ISO-standarder för hur man testar ljudnivån på en värmepump; ISO3747, ISO3741. En standard för testarbete alltså, var mätpunkter ska införas och hur mätutrustningen ska hanteras, för att kunna bedöma resultaten likvärdigt mot andra värmepumpar och godkända nivåer.
Jag kan mycket väl tänka mig att ett iso-standard-stödramverk för mjukvarutest kan vara värdefullt och användbart för vissa. Skillnaden mot ovan verkar ligga i bedömningen; är ett resultat av test bättre än ett annat? Vad är godkända nivåer?
Tack Oscar för dina kommentarer!
Jag var kanske lite elak med min sista fråga, men jag ville ha med ett område som på många sätt påminner om det vi jobbar med.Akademisk forskning handlar om att ta fram (ny) information åt andra människor. Akademisk forskning omfattar väldigt många olika discipliner och inriktningar. Akademisk forskning har många olika “skolor” och synsätt.
Och enligt min ringa empiriska studie (1 professor som jag ringde) så borde hen kunna ge en indikation på om det finns några ISO-standarder eller övriga standarder.
Hen sa:
Inom akademisk forskning finns ingen standard (ej heller ISO). Däremot finns det allmänakademiska normer som har växt fram över tiden; exempelvis att man har källförteckningar, inte kopierar, etc. Detta för att det ser så olika ut inom alla olika discipliner. Om du hittar någon, så är den antagligen väldigt specifik och används bara inom det specifika området. (Lite att jämföra med de äldre standarderna inom testning av tåg som Magnus nämnde i artikeln kanske? (min anmärkning))
Även sättet som forskningsartiklar skrivs på bestäms oftast av publikationsägaren så forskaren får alltså anpassa efter situationen.
Visst finns det en massa standarder som touchar (och inte mycket mer) det vi jobbar med. Men ISO3747 och ISO3741 handlar om att mäta ljudnivåer hos en värmepump – i syfte att kunna jämföra mellan andra värmepumpar. Rätt specifikt och inte testning.
Jag gillar också tanken på att ha stödramverk. Men vad innebär egentligen att ett stödramverk är standard? Och var går gränsen för hur långt en standard i så fall ska sträcka sig för att fortfarande vara ett stöd?
Om vi tänker oss att standarden zoomar längre och längre ut så att den blir så generell att den knappt omfattar något specifikt, återstår kanske bara en definition av testning. Men t.o.m. den har vi (som jobbar med test) inte kunnat ena oss om… På gott, vill jag tillägga… 🙂
All heder till dig Oscar, du är en av få som faktiskt argumenterar med exempel på varför en standard skulle kunna vara användbar. Henrik Emilsson bemöter några punkter och jag vill själv utveckla ett par argument för att ge perspektiv.
Ditt exempel om ljudnivå på värmepumpar är intressant; det finns en standard för att kunna bedöma resultaten likvärdigt mot andra värmepumpar och nivåer genom att definiera bl.a. var mätpunkter ska införas. Inom mjukvaruutveckling är komplexiteten helt enkelt så hög att varje projekt inte är en ny typ av värmepump, utan en helt ny typ av apparat som fyller ett nytt syfte och därför är det väldigt svårt att definiera en standardmätpunkt.
Viss specifika delar går att delvis standardisera. Jag jobbade t.ex. med WLAN en gång i tiden och där var det viktigt att ha en standard att testa emot för att det ska fungera ihop med andra apparater. Men det var bara EN del av testningen då just vårt chip fungerade ett specifikt sätt i våran kontext med vårat system med våra specifika problem. Utvecklingen var så snabb att en stor del att testningen förändrades bara mellan versionerna på vårat eget chip. Vi kunde helt enkelt inte jobba på samma sätt som tidigare och vi var tvungna att ändra våra mätpunkter och förändra våran nomenklatur (kort sagt så introducerades en ny telefon av Apple som förändrade en hel del). Då förändringen i en så begränsad kontext gjorde att vi inte kunde behålla samma testdefinitioner mellan två projekt, hur ska en standard klara att göra det för testningen generellt?
En annan aspekt med ditt värmepump-exempel är att även om mätpunkterna standardiseras och mäts mot specifika nivåer så måste ändå testaren ställa sig frågor som “Fungerar som det ska? Blir våran kund nöjd?”. Man kanske ligger inom godkända nivåer, men har man testat mot konkurrenternas produkter som kanske har för kunden bättre ljudnivåer? Kan bieffekter uppkomma, som inte täcks i standarden, om kunden bygger in värmepumpen på ett udda sätt?
Stödramverk har jag inget emot, men att göra ett generellt är väldigt svårt. Det man kan göra är att säga att de här metoderna, processerna, angreppssätten etc. fungerar i vissa fall bättre och i vissa fall sämre (eller inte alls) och då är det ok enligt mig. Men att skapa (ytterligare) en “standard” för mjukvarutestning generellt är att återupprepa samma misstag som redan gjorts ett antal gånger.
Och kom gärna med motargument eller frågeställningar, det är intressanta exempel du tog upp som passar diskussionen bra!
Tack Magnus för att du delade med dig av denna information. Precis som du skriver så kommer detta ske varken vi vill det eller ej och då tjänar man alltid på att vara påläst.
Jag måste erkänna att jag faktiskt inte kände till att arbetet med en ny standard pågick. Blev lite nyfiken efter ha läst inlägget och alla kommentarer så jag satte mig ner och försökte hitta mer info om vad denna standard täcker och tar upp. Det första som slog mig var att det jag läste inte alls rimmade med en agil utvecklingsmiljö utan påminde mycket om det som står i tex TMap. Men dock upprepas vid flera tillfällen att den också skall funka för agila organisationer.
Började fundera i banorna om vi där jag arbetar skulle vara compliant enligt ISO/IEC/IEEE 29119 hur skulle vårt arbete förändras då. Eftersom vi saknar mycket av tex den dokumentation som beskrivs skulle vi behöva sätta oss och skriva testplaner och strategier. Vi skulle inte heller kunna fortsätta med den utforskande testapproach vi har eftersom den inte uppfyller dokumentationskraven och spårbarhet. (Utforskande test och spårbarhet går såklart att förena men det är inte så vi arbetar idag).
För oss skulle en compliance med denna standard innebära att vi arbetar långsammare och mindre effektivt. Men nu är det så att vår kund inte heller kräver att vi skall kunna visa upp hur vi testat utan är nöjd med att vi varannan vecka levererar en ny version av vår mjukvara till produktion som de kan klämma och känna på och vi får snabb feedback. Kunden är mer intresserad av resultatet och kanske inte så mycket hur vi uppnått det. Däremot måste det där ute finnas många företag som arbetar som vi men där kunden kräver en viss compliance med den nya standarden. Det skulle i så fall innebära en försämrad och mindre effektiv process. För det går inte att definiera ETT sätt att arbeta på som är bra för alla och det är just detta som hävdas när jag läser på lite mer om vad ISO/IEC/IEEE 29119 innebär.
Vad som också missas helt är, att i en agil värld eftersträvas en ständing förbättring i hur vi arbetar, vilka vertyg och metoder vi använder oss av. Hur är detta möjligt om inte standarden ständigt uppdateras och då menar jag inte en gång per år utan kanske varje vecka. Jag är rädd att när man uppnått full compliance så är man nöjd och driver inte arbetat med att ständigt förändras och förbättras vidare.
Jag tror inte att det finns ETT sätt när det gäller hur vi skall arbeta eller kommunicera med varandra utan detta är och bör vara anpassat till varje organisation, företag och team.
Kul med så många bra kommentarer och tankar kring ämnet!
Efter den här intressanta diskussionen väntar i varje fall jag med spänning på vilka konsekvenser standarden kommer att medföra när den introduceras. 🙂
Hoppas att många i framtiden delar med sig av sina erfarenheter om hur standarden påverkade dem.
/Johan
Till att börja med måste jag instämma med Johan att det var kul med så pass många kommentarer vilket jag inte alls hade förväntat mig när denna artikel publicerades innan min semester. Det som dock känns lite oroväckande och tråkigt är den aversion mot processer och standarder som det ges uttryck för bland många av kommentarerna och där man ser allting svart eller vitt.
I min värld är en process inte ersättning för den yrkesskickligheten många individer besitter och som de kontinuerligt arbetar med att vidareutveckla. För mig är processen ledstången upp för trappan, oftast behöver jag inte använda den men ibland behöver jag ta hjälp för att komma vidare till skillnad från barnen, de oerfarna, som behöver den för att leda dem uppåt. Att sedan inte kunna eller vilja återanvända saker är i mina ögon resursslöseri, oavsett om det är en dokumentmall eller en grundläggande granskningsprocess. Dock inte sagt att de kan behöva anpassning.
Tyvärr finns inte möjlighet att bemöta alla de påståenden och frågor kring standarden som lyfts fram utan får hänvisa till framtida seminarier och konferenser där den kommer att presenteras mer i detalj. Alternativet är att ni studerar standarden när den blir tillgänglig för allmänheten. Dock finns det några saker som jag önskar bemöta som man inte kommer att kunna utläsa ur den färdiga standarden.
I arbetet med att ta fram standarden har en stor mängd erfarna personer från runt om i världen varit engagerade. Jag själv skulle inte kunnat ta fram en sådan här standard eftersom det bygger på samarbete och konsensus mellan de bidragande individerna. I detta arbete har den svenska arbetsgruppen arbetat hårt för att föra fram våra synpunkter och kommentarer. I vissa fall har de fallit i god jord medan andra gång har man valt att bortse från dem.
Ett exempel är problematiken kring att den skall passa både traditionell och agil utveckling där man ibland har just har skapat för mycket struktur och dokumentation för att det skall vara agilt. Detta tillsammans med en del andra saker har resulterat i att vi de senaste fyra gångerna valt att rösta nej, alternativt lagt ner vår röst. Ett annat resultat är att den internationella arbetsgruppen beslutat att ta fram en teknisk rapport för att visa på hur man kan applicera standarden i agila projekt.
Avslutningsvis skulle jag vilja hänvisa till en kommentar på Johan Jonassons blogg av Yury Makedonov (http://blog.johanjonasson.com/?p=774#comment-10015) där han avslutningsvis skriver följande:
” If we want to understand both sides of this testing divide we need to start this discussion within Context-driven testing community. I believe that as a group we have enough experience and knowledge to figure this out.”
Jag tycker att diskussionen är väldigt viktig men för att få till en sådan och för att höra olika synpunkter kan man inte kalla alla för okunniga eller liknande bara för att man har ett annat synsätt på saker och ting.
Magnus jag tror du missuppfattar en viktig detalj.
Jag tror inte att alla är emot processer och standarder.
Det vi är emot är DENNA standard som jag och många med mig tycker inte hjälper oss i vårt arbete. Vi generalisera inte, våra kommentarer riktar sig mot ISO/IEC/IEEE 29119.
“För mig är processen ledstången upp för trappan” vilken bra liknelse men det hjälper ju föga när du är på väg upp för fel trappa. Då hade det kanske varit bättre att ramla ner och prova en annan trappa istället.
Och jag ber dig förklara för oss hur innehållet i denna standard ska vara en ledstång i vårt arbete. Vad specifikt i standarden kommer att hjälpa oss och hur?
“Att sedan inte kunna eller vilja återanvända saker är i mina ögon resursslöseri” – Ja det har du rätt i, det kan det ofta vara. Det jag däremot verkligen inte vill är att DU genom en standard tvingar mig vad jag ska använda och inte. Vad får dig att tro att du vet det bättre än mig eller någon annan för den delen. Du tar ju ifrån mig möjligheten att själv välja så då ligger det ju nära till hands att tro att denna standard kommer leda till resursslöseri.
“Jag tycker att diskussionen är väldigt viktig men för att få till en sådan och för att höra olika synpunkter kan man inte kalla alla för okunniga eller liknande bara för att man har ett annat synsätt på saker och ting.”
Det är väl inte någon som kallar dig för okunnig?
Vad jag säger är att ni utnyttjar (och föder) den okunskap som finns för att som du säger “skapa affärsmöjligheter”
Vad som däremot krävs för en diskussion är att parter bemöter varandras argument.
Väldigt tråkigt att du undviker detta utan istället hänvisar till framtida konferenser. Det är här och nu vi diskuterar och du initierade diskussionen. Fly inte undan utan bemöt oss dina argument och åsikter annars blir det en ganska enkelriktad debatt. Jag utgår från att det som sägs här i kommentarerna inte kommer som en nyhet för er utan att ni redan har funderar kring detta och har ett haft bra resonemang kring det. Så dela med dig!
Henrik A, jag tycker dina inlägg är bra märkliga och tyder på att du inte är särskilt insatt i hur standardisering går till och vad en ISO standard egentligen är för något.
Standardisering är ett politiskt spel som handlar mer om konsensus än om vem som har rätt och fel. Ingen kan anklagas för innehållet i en standard utan det hela är en förhandling där världens länder förhandlar om vilka krav som ska stå i den.
Magnus var en av få som engagerade sig och försökte få till en förändring i ett standardarbete som till stor del styrts av IEEE (som inte har särskilt stor erfarenhet av att skriva ISO standard).
Så den enda du ska anklaga för att 29119 inte blev som du ville är faktiskt du själv. Du hade kunnat engagerade dig och gjort din röst hörd i arbetet.
Alla standarder är helt frivilliga att följa. Sedan kan marknadskrafter eller lagstadgare göra att den blir tvingande. ISO har hittils tagit fram 20.000 st som i princip påverkar allt runt i kring dig.
Jag kan även lägga till att syftet med en ISO standard är att försöka harmonisera världen i en fråga så att alla gör på samma sätt och att det blir lättare för alla. Det betyder inte att varenda liten pinal ska standardiseras och göras lika utan ofta försöker man fokusera på det som underlättar och inte stjälper processerna. Det finns många standarder som styr hur en bil utformas men det betyderna inte att alla måste äga en svart T ford. Men det är förstås en fördel om alla har samma tanklock så att vi kan alla kan tanka på alla bensinstationer. Eller hur?
Sedan kan man ju fråga sig hur många här som här läst standarderna? Eftersom de ännu inte har publicerats så är det ju intressant att det finns så mycket åsikter om dem! Ungefär som den där boken “Satansverserna” där det utdelades dödsdommar hit och dit och det var nog få som fördömde den som överhuvudtaget hade sett omslaget ens…
Sverige kämpade länge med att få ISO 29119 serien nedkortat med korta tydliga krav på det som var viktigt. Dessvärre så var vi de enda som drev denna linje och kom in försent i standardiseringsprocessen för att kunna påverka den tillräckligt men så är det i politik.
Tycker att den här tråden/debatten påminner VÄLDIGT mycket om en annan “internetkris” som pågår nu, angående castingen av Ben Affleck som Batman.
Internet “rasar” ju om hur katastrofalt det är, långt innan filmen är klar, eller ens påbörjad.
Själv tror jag att jag kommer att behandla både standarden och Batfleck på samma sätt: jag avvaktar helt enkelt med mina omdömen tills jag tagit del av slutresultatet.
Tycker jag inte om det, fine. Ingen tvingar mig att använda den nya standarden, och Adam West finns fortfarande kvar.
En bättre debatt att dra paralleller till är en som finns inom organisationsteori och handlar om organisk eller mekanisk organisationer. Kort sagt utvecklades den mekaniska organisationen med industrialiseringen och finns typiskt i fabriker. Inom den mekaniska organisationen finns det ett “rätt” eller optimalt sätt att strukturera sin organisation och typiskt har man specialister som fokuserar på att göra ett specifikt moment så optimalt som möjligt (tänk skruva i en speciell skruv på en bil X antal tusen ggr). Den organiska organisationen började utvecklas på 50-talet då fler och fler organisationer behövde möta en snabbt föränderlig omvärld (tänk statsmonopol innan 2:a världskriget och konkurrens efter).
Idag kan man hitta båda typer av organisationer i olika typer av företag, fabriker är typiskt sätt mekaniskt organiserade och mjukvaruutveckling typiskt sätt organiskt organiserade. Beroende på kontext så organiserar man sig olika. Om man försöker skriva en generell standard för mjukvarutestning är man lika fel ute som om man försöker skriva en generell standard för hur ett företag ska organiseras.
Och det är det som den här debatten handlar om; Inte om själva innehållet i standarden (som säkert kan vara jättebra i viss kontext), utan om det går att skriva en generell standard för hur man ska testa mjukvara överhuvudtaget.
Stefan,
Du har rätt i att jag inte har sett på insidan hur en ISO Standard blir till. Det är för mig ganska ointressant då det är vad som skapas som är intressant och påverkar mig.
Vad jag däremot gjort är att följt framtagandet av ISO 29119 sedan våren 2008 så kom inte gaggandes om att vi inte vet vad vi talar om!
Du skriver att att ta fram en iso standard handlar om konsensus. Konsensus bland vem? Tycker du att vi verkar ha konsensus bland testare här i värden? Varför är konsensus bra?
Tycker du ni verkar lyckas bra med att harmonisera världen?
Att likställa en standard som syftar till att styra hur vi ska jobba med test med att tanklock ska se lika ut visar väl snarast på hur skev bild du har av det du pratar om!
Jag ifrågasätter syftet med arbetet och innehållet i standarden genom Magnus då han har varit den enda här som försvarat dess existens. Nu har du poppat upp så allt det som jag frågat Magnus gäller även dig!
Varför ska jag anklaga mig själv? Vad har du hört eller sett som får dig att tro att jag vill ha denna standard över huvud taget?
Ja en del av det vi skrivit om här har handlat om hur vi tror att denna standard kommer att användas. Det är väl ganska naturligt med tanke på vad Magnus beskriver för önskvärda scenarion i sin artikel?
Om ni nu inte får igenom era viljor utan blir nedröstade gång på gång. Varför står ni då bakom ISO29119?
Sen ber jag er igen att istället för att skriva om massa annat, kan ni inte konkret bemöta de frågor, synpunkter, funderingar och oro som framkommit i kommentarerna!
Jag registrerade mig här för att kunna kommentera kring arbetet runt ISO29119 och dess – i mitt tycke – meningslösa syfte.
Jag har jobbat med utveckling inom storföretag sedan slutet av 80-talet och har vigt mitt liv åt test sedan tidigt 90-tal.
Hur många manår jag har lagt ner på utveckling med vattenfallsmodellen vet jag ej men hör jag PROPS eller Prince 2 en gång till så kommer jag troligen att kräkas!
Det monolitiska ramverk och process-träsk som dåtidens testmetodik förespråkade var baserad på gigantiska projektcykler där det inte var ovanligt med 12-24 månaders utvecklingsfas – utan inkrementella leveranser!
På den tiden så hade man en implementation proposal att jobba efter och den var skriven på kodnivå så att det skulle bli exakt som arkitekterna ville ha det. Här pratar vi om enorma domänkunskaper som grund till detta arbete och var en förutsättning för att det skulle lyckas.
Med denna utvecklingsmodell så var man tvungen att ha ett system som baserades på dokumentation, dokumentation, dokumentation och åter igen dokumentation.
Fast forward till 2008 och nu med en marknad som svänger som snabba motorbåtar till skillnad mot 90-talets oljetankers och den problematik man har haft med den gamla rigida metodiken, nu har vinden äntligen börjat vända även på storföretagen och man inser att projektcykler på mer än ett år ger på tok för höga risker och osäkerhet med return of invest.
Först dyker Scrum upp som en gubbe i lådan och det tog inte lång tid innan den Agila metodiken med LEAN som grundpelare implementeras i rask takt och helt plötsligt så börjar man släppa, visserligen små, nya versioner varannan vecka och möjligheten att ta igen en del av utvecklingskostnaden utan att behöva vänta tills det är “klart” och vi kanske träffade rätt?
Under detta paradigmskifte så fick många projektledare stryka på foten till fördel för utvecklande scrum-masters och LEAN applicerades på all den dokumentation som tidigare bara hade producerats för att “så skulle det minsann vara” – även om ingen läste den! Det fanns stora besparingar att göra helt klart.
Vi vill absolut inte tillbaka till det träsket där man i syfte att skapa business nylanserar en ny certifieringsprocess och standard där man i stället för LEAN i botten skriver att “det även fungerar för agil metodik”. Jag hävdar bestämt att det inte spelar någon som helst roll vilken utvecklingsmetodik man använder – så länge man följer den slaviskt så blir det rätt. Den utopin finns inte och då måste man ner på lägsta nivå och applicera “design for testability”.
Bra test är rätt test och det beror helt på hur kravställningen ser ut, vilken kvalitetsgrad man begär och hur mycket man förväntar sig att tjäna på produkten. I dag kostar konsumentelektronik avsevärt mycket mindre än det gjorde förut och jag kan lova att även om hårdvaran har blivit billigare så har inte mjukvaran blivit det, snarare tvärtom!
Då måste vi hitta metodiker som testar rätt redan från början och genom att bedriva design for testability och automatisera till “rätt” grad för att uppnå de kvalitetskrav vi ställer på våra produkter.
Att i denna miljö börja kräva testspecar, testrapporter och andra icke-drivande dokument finner jag absurd och kan inte se andra intressenter än de konsultbolag som hoppas kunna debitera mer timmar än nödvändigt då de nu även “måste” skriva en massa tidsödande dokumentation.
Arbeta agilt och anamma LEAN ordentligt, se till att ni har test automatiserat redan från designstadiet, och för guds skull se till att alla testresultat är tillgängliga i realtid via en databas och adekvat front-end så att även den mest skeptiska chefen kan få ett snapshot när han/hon vill. Att i sedvanlig ordning byta namn på gamla processer eller metodiker/modeller är lika produktivt (enligt min åsikt) som att byta namn på ett företag som gjort bort sig och med desperation försöker förnya sig… “-Lipstick on a pig” kanske klingar bekant? 😉
Min utopi är så mycket automatiserat som möjligt och dynamisk testverksamhet som drivs av “one team” tillsammans med aktiva stakeholders som skriver adekvata user-stories och kvalitetskrav baserade på förväntad return of invest. Den har jag nått!
Jag är inte beredd att tåga in till mina team med en bokhylla märkt “ISO29119” och ordern “- kolla här grabbar! det här är det bästa som hänt sedan skivat bröd och nu kommer allt att bli så mycket bättre…”
Detta är inte en sågning av någons eventuella arbete, det är en sågning av den något optimistiska synen på hur test skall bedrivas kontra den faktiska verkligheten.
Given, When, Then!
Jag tror försöken att standardisera, certifiera och på andra sätt styra testarbete med generella och mer eller mindre heltäckande pappersprodukter, beror på en vanlig missuppfattning. Många tror fortfarande att mjukvaruutveckling sker enligt en löpandebandprincip med ett antal efter varandra följande utvecklingssteg och ordnande överlämningar däremellan. Så ser naturligtvis inte verkligheten ut. Allt utvecklingsarbete, inklusive test, är en halvt kaotiskt, utforskande, intellektuellt stimulerande och därmed svårdefinierbar verksamhet som inte låter sig beskrivas i processform. Därför försöker ingen heller att ta fram generella standarder för t.ex. producerandet av kod.
Varför sker då sådana initiativ inom testområdet? Kan det bero på den ingrodda ovanan att skilja på utveckling och test? Att man ser på testarbetet som en avstämning av färdiga leveranser? Att man ser på testare som revisorer med uppgift att kontrollera utvecklingsarbetet i efterhand? Detta är isåfall ett begränsande sätt att se på test som förminskar nyttan av vår profession. Jag menar att test är en del av utveckling och sker innan under och efter programmeringsstegen i samarbete med utvecklare, kravanalytiker, arkitekter och alla andra. En generell standard för mjukvarutestning riskerar att ytterligare driva in kilar mellan utvecklingsarbete och testarbete. En tråkig utveckling tycker jag.
Oj, så många arga inlägg om någonting som inte ens finns. Att ha så bestämda åsikter utan något konkret att kritisera låter dogmatiskt i mina öron.
Tänk om du kanske kan lära dig något från en framtida standard? Med så förutfattade åsikter kan det blir svårt.
Det kanske rent utav är bra om det finns motpoler till andra test-filosofier?
Vadå inte finns?
http://www.iso.org/iso/home/search.htm?qt=ISO%2FIEC%2FIEEE+29119&sort=rel&type=simple&published=on
Vad menar du med att vi inte är konkreta?
Där ser man. Standarden finns tillgänglig. Ser ut som den publicerades för en dryg vecka sedan.
Men det förändrar inte något. De negativa kommentarerna i denna tråd är inte grundade på innehållet i standarden. Eller har man ni haft tillgång till den på annat vis?
Jag antar att vi ser olika på standards. Jag tycker det kan vara en bra källa till testideer som jag ev kan nyttja i mitt kontext. Det betyder inte att jag följer den slaviskt.
Att man väljer sin teststrategi, -process och -metodik efter sitt eget kontext är sunt förnuft. Så självklart att jag inte tycker det är värt mödan att diskutera.
Den här standarden kanske är kass, det vet inte jag. Men jag tänker ge den en chans och läsa innehållet innan jag sågar den med fotknölarna 🙂
Jag tror du tyvärr helt har missuppfattat vad denna debatten handlar om. Jag ber dig läsa Martin Nilssons kommentar i detta ämne.
Hej!
Jag tycker ditt svar är lite märkligt. Hur kan du på denna lilla text anklaga Mattias ha missuppfattat hela debatten? Jag ser gärna att testzonen är ett seriöst forum inom test.
Med vänlig hälsning
Lars Wahlberg
Vi behöver inte vara överens över vad vi tycker. Det är bra, då kan vi diskutera det. Jag önskar att man inte kommer med milslånga bloggar om vad man tycker rent vardagligt och om ens egen karriär . Håll er gärna kort. Då orkar man läsa det. Testzonen är kanske inte forumet för mig, men jag tycker Jonas, Jörgen mm är bra personer.
Ja och jag tror att du och andra är bra personer (=som vill diskutera osv, finns inget ont sinne).
Hej!
Jag tycker standards är bra. Precis som tänk från James Bach och många andra. Det är ett försök av duktiga människor att samla ihop sina tankar. Det finns ingen demokrati osv vad industrin/myndigheter väljer att följa. Ex flygindustrin följer RTCA-DO-178B. Rätt eller fel, men så är det. Finns många bra saker i den standarden.
Jag kommer läsa även denna standard. Ta åt mig ideer som kan fungera i Agile testning. Följa den ifall den blir en best-seller (vem vet) eller att kunder kräver det. Jag har inte haft tid att köpa den än.
Ifall jag får sammanfatta så är det väldigt många duktiga personer som valts av industrin mm att ta fram denna standard. Några kloka ord finns nog i den. Skall bli spännande att läsa den …
Klart det kan finnas bra saker i en standard, men det väl ändå äpplen och päron att jämföra en persons samlade tankar med en ISO-standard? Om den här samlingen människor hade gått ut med ett ramverk och bara satt sina namn på den och sagt att det här är våra samlade tankar, take it or leave it, så hade jag kunnat se likheten, men inte när samma samling människor säger att deras mål är att skapa den definitiva standarden för mjukvarutestning och vill sätta ISO och IEEE på sina tankar.
Jag är inte heller med på vad du menar att dessa personer “valts ut” av industrin? Magnus Ohlsson kan säkert berätta om hur det gick till när han gick med i arbetsgruppen, men någon form av företroendeval ingick nog inte. Nu kanske du tycker att jag petar i detaljer, men jag blir lite rädd av bristen på skepsism från många i den här tråden och tycker det är viktigt att vi inte faller i fällor som den att tro att nuvarande arbetsgrupp fått någon form av extraordinärt förtroende. Det har i så fall gått mig helt förbi, eller så ser man väldigt smalt på vad eller vilka personer som ingår i “industrin”.
Att närma sig en ny produkt av det här slaget med sin inställning påverkad av, eller till och med grundad i, att det troligtvis är något bra bara för att det är en “standard”, eller att många personer med akademiska titlar eller många år i branschen varit involverade medför metodfel som vi aldrig skulle acceptera i vårt dagliga arbete som testare. Auktoritetsargument och populäritetsargument för att nämna två.
Det _kan_ finnas kloka ord i den, men det väljer jag att tro när jag ser dom, inte innan. Jag hör “definitiv standard” och jag läser om möjligheterna (riskerna) till att det utarbetas nya certifieringar inom standarden, kanske t.o.m på personnivå, som kan bli tvingande. Det gör mig rädd för att den ska accepteras per automatik i branschen, och skeptisk till att det över huvud taget är möjligt (“definitiv standard”), och det är med den utgångspunkten jag nu försöker läsa de tre dokumenten som är släppta. Målet med standarden är tydligt: Den ska kunna appliceras i alla testsituationer. Håller man fast vid det målet så räcker det inte med att man får ihop några bra tankar för att få ett “test ok” av mig.
Visst, visar den sig vara bra så adopterar jag såklart den, och visar den sig vara dålig så tänker jag kritisera den och motarbeta att den adopteras i så stor utsträckning jag kan. I inget av fallen tänker jag rulla över på rygg och bara acceptera att jag kommer bli påverkad i mitt yrke av något av den här storleken. Och jag förstår ärligt talat inte de som verkar likgiltiga inför en sådan här publicering eller som tror att vi inte kan påverka vår omgivning, eller inte bryr sig om hur den påverkas av s.k auktoriteter.
(Obs: Det sistnämnda är riktat till svar tidigare i tråden, inte till Lars kommentar. Likaså är mycket av min övriga kritik riktad bredare än så som ni säkert märker.)
Hej Johan!
Bra synpunkter. Jag var väl lite kortfattad och det går väl övertolka ifall man vill det. Helt ok.
När du har tid så kan du väl ringa mig på 0733-478707, så kan vi prata lite om ditt sista stycke.
Mvh
Lars Walberg
Hej Lars,
Gärna det. Jag sitter tajt till idag, men pinga mig gärna på Skype (johan_jonasson) eller dylikt i nästa vecka så ringer jag upp.
M v h
Johan
Ja vi försöker nå varandra nästa vecka, så kan vi diskuterar lite. Vi återkommer till denna “tråd” senare med vad vi kom fram till 🙂
En lång rad av kommentarer är nu borttagna från denna tråd då en del av dem innehöll olämpligt innehåll. Vi kanske återpublicerar delar av dem under nästa vecka efter kontakt mef berörda parter.
Teszonen red.
Länkar till ett blogginlägg av en testare som heter James Christie. Jag tycker att det han skriver belyser några av de problem som kan uppstå om man låter en standard definiera hur man testar.
http://clarotesting.wordpress.com/2013/09/18/testing-inside-the-box/
Bra blogginlägg!
Tycker han slår huvudet på en viktig spik, nämligen problemen med att driva en hårt positivistisk linje i testarbetet. Detta oavsett om man arbetar enligt en standard eller ej i mitt tycke.
Även om ansatsen inte riktigt faller mig i smaken så är det såklart inget fel på positivismen i sig. Jag vill minnas att jag under studietiden till och med skrev en hyggligt lång PM till positivismens försvar. 🙂 Men jag ser dess nytta mer i de hårda vetenskaperna. Att utforska kvalitetsaspekter i en produkt hör mer till de sociala vetenskaperna där en hermeneutisk ansats verkar lämpligare: Vad är det vi observerar och vad är betydelsen av det vi observerar?
Att jag har den åsikten kan säkert präglas av min generella inställning till kognition där jag lutar åt en inutition/känsla/perceptions-preferens (länk: Myers-Briggs). Men för att dra till med ett vilt påstående så skulle jag säga att det snarare är så att min MBTI-preferens gör att jag gillar att arbeta med kvalitetsarbete och testning, än att det skulle påverka hur jag arbetar med dito.
Problemen med testning ser ut som dom gör oavsett om vi tycker om det eller ej. Att försöka bedöma eller “bevisa” kvalitet med samma verktyg som vi bevisar fysikaliska principer är dömt att misslyckas, även om vissa av de verktygen såklart kan hjälpa oss en bit på vägen. På samma sätt kan en bra standard hjälpa en bit på vägen när den används i rätt sammanhang, men inte hela vägen. Implementationen och vad man implementerar måste alltid bero på kontexten.
“På samma sätt kan en bra standard hjälpa en bit på vägen när den används i rätt sammanhang, men inte hela vägen. Implementationen och vad man implementerar måste alltid bero på kontexten.”
Tror du inte att även standardens förespråkare skulle hålla med om detta påstående? Det kanske blir en diskussion om vad som är “en bit på vägen” så klart. Handlar det inte bara om detaljnivån på standarden? Med rätt detaljnivå finns det utrymme för variation i implementationen? Eller?
/Johan
Exempel på standarder som jag inte tycker är “i vägen” för bra testarbete och sunda implementationer är t.ex. de ISO-standarder som FDA’s riktlinjer baserar sig på. De avkräver bland annat spårbarhet, digitalt signerade dokument och en nivå av bevisning som jag tycker är rimlig med tanke på domänen. De dikterar dock inte hur processen för detta ska se ut, vilket jag också tycker är rimligt då de (guidelines) spänner över så många skilda kontexter och produkter som inte skulle må bra av att tvingas in i en gemensam process i min mening. De är sådana som jag avser jag när jag säger att de hjälper en bit på vägen. Likaså kan ramverk som Bach’s Heuristic Test Strategy Model vara en sådan “vägledare”, utan att för den sakens skulle vara en formell standard. Jag ser ganska brett på detta med andra ord.
Jag är alltså inte emot standarder generellt. Jag är emot standarder som antingen inte tillför något eller standarder som snarare mer liknar ett försök att stänga ute oliktänkande eller diktera hur saker som process och dokumentation ska se ut. Och då är det väl lite som du säger att diskussionen hamnar i vad som är “en bit på vägen”.
I fallet med ISO 29119 då… En av de största problemen jag har här är scopet och de stora riskerna som är förenat med att få sätta en ISO-stämpel på det scopet (som jag beskrivit tidigare). Det finns inte heller ett behov som jag ser det för en sådan standard och den riskerar att missleda folk som inte är så insatta i testproblematik att detta är allt man behöver göra för att garantera god testning. Som jag tror jag skrivit någon annan stans: Om gruppen som tagit fram dessa dokument hade sagt att detta är en samling tankar och idéer som man kan hämta inspiration ifrån så hade jag inte varit lika kritiskt. Då hade det kunnat vara att hjälpa testare “en bit på vägen”. Men istället säger man att detta ska vara Standarden med stort S.
Det är lite som att säga att om det inte finns med i den här standarden så är det inte bra. Ännu värre om det gud förbjude skulle finnas idéer eller erfarenheter som säger _emot_ något som står i den här standarden.
Bästa sättet att sammanfatta min åsikt tror jag är att kalla ISO 29119 till ett försök till en “power grab”. Få ut detta, kontrollera vad som får kallas Standarden för testning, och eliminera oliktänkande med referens till att det här är Standarden, trots att många erfarna inom branschen har vädjat till eftertanke och kritiserat hela företaget med ett försök till en allomfattande standard. Man väljer att inte lyssna och att fortsätta i samma (lik)riktning i alla dessa år. Det är en farlig riktning i en industri som fortfarande är så pass mycket under utveckling som mjukvaruindustrin är. Vi har mycket kvar att lära och vi har inte råd att bli tillbakahållna av några som vill slå ner bopålarna och säga Mission Accomplished. De som varit med längre än jag kan vittna om att vi har varit där förut, och det fungerade inte då heller.
Så nej, jag tror inte att den här standardens förespråkare håller med mig i mitt påstående om kontextberoende.
“Bästa sättet att sammanfatta min åsikt tror jag är att kalla ISO 29119 till ett försök till en ”power grab”. Få ut detta, kontrollera vad som får kallas Standarden för testning, och eliminera oliktänkande med referens till att det här är Standarden”
Med detta som utgångspunkt så håller jag absolut med dig i din oro och kritik. Jag själv är dock inte säker på att denna utgångspunkt stämmer, och kan därför jag inte ta en lika tydlig ställning. Men jag förstår absolut din oro.
“Jag är emot standarder som antingen inte tillför något eller standarder som snarare mer liknar ett försök att stänga ute oliktänkande eller diktera hur saker som process och dokumentation ska se ut.”
Detta håller jag absolut med om. Däremot vet jag inte om ISO 29119 är en sådan typ av standard – har helt enkelt för lite kunskap om standarden och dess syfte. Har bara läst igenom dokumenten övergripande, och vet ingenting om hur standarden kommer att användas.
/Johan
Jag blir mörkrädd när jag läser blogginlägget ovan. Eller så har jag missförstått budskapet. Nu är det förvisso en helt annat debatt så jag ska fatta mig kort.
Visst, man kan skoja till det med fantasifulla analogier som “Getting out of the box”. Eller så säger man bara – “Think outside the box” – det för fram budskapet. Inte skriva spaltmetrar med en massa flumm och hävda att ett vetenskaplig tillvägagångsätt inte fungerar. Då börjar det bli farligt. Då kan vi lika gärna börja tillbejda en test-gud om riktlinjer och tillvägagångsätt.
Självklart kan man inte bevisa testningen – det dilemma finns i all vetenskap också (man kan bara motbevisa en hypotes). Det är vetenskapens rationella tänkande vi ska ta med oss till testlabbet.
Spännande. Är det James Christie’s blogginlägg du blir mörkrädd av, eller min kommentar på densamma? (gissar på det förstnämnda, men vill vara säker)
Jag tyckte som sagt tvärt om att det var en ganska insiktsfull bloggpost. En specifik del som jag gillade var: “Both testing and auditing have been plagued by an unspoken, unrecognised devotion to a positivist outlook. This makes the ontological assumption that we are working in a realm of unambiguous, objective facts and the epistemoligical assumption that we can observe, measure and conduct objective experiments (audits or tests) on these facts. Crucially this mindset implicitly assumes that we can know all that is relevant.”
Jag läser inte detta som flum (och det kanske inte heller du gör?). Inte heller läser jag det som ett påstående att positivism inte skulle fungera. Men om jag förstår honom rätt, och det som också är min hypotes, så håller jag med om att positivsm och mjukvarutestning är en skakig kombination.
Det är inte fråga om att be en test-gud om riktlinjer. Snarare tvärt om. Det är att säga att vi har jättemånga verktyg som vi måste använda rationellt tänkande och sunt förnuft på för att använda på rätt sätt och i rätt lägen, men ett av dessa verktyg tycker vissa av oss ska användas sparsamt eller med stor försiktighet. Detta då det vi studerar inte riktigt lämpar sig för den ansatsen.
Jag tycker detta hör ihop ganska bra med debatten om den här artikeln (och den specifika standarden i artikeln) så jag diskuterar det gärna mer om du vill.
Det är lite “The Black Swan” över det hela känner jag. (Med reservation för feltolkning.)
Vi jobbar med något som är komplext och oförutsägbart.
Hur mycket checklistor och processer vi än har, så kommer det alltid att hända saker som vi inte kunnat förutse.
Vi måste ha en flexibilitet i vårt arbetssätt som gör att vi kan hantera sådana situationer.
Detta motsäger dock inte att vi jobbar på ett vetenskapligt sätt. Vi måste bara vara medvetna om komplexiteten.
Jag tycker inte att detta nödvändigtvis motsäger att vi kan ha standarder. Vi måste dock ta hänsyn till det när vi utformar vår standard.
Eller så har jag misstolkat allt.
/Johan
@Johan: Nej, du verkar inte ha misstolkat något men jag tycker inte heller att något av det du skriver i den här kommentaren motsäger något av vad jag skrivit, men det kanske inte var meningen heller? Om du tycker annorlunda får du gärna peka ut var vi skiljer oss så ska jag bemöta det. Men vi verkar vara ganska överens på dom här punkterna!
Nej det motsäger inte det du har skrivit, och det var inte min avsikt, utan mer en omformulering för att göra det klart för mig själv.
Antar att skillnaden i hur vi ser på just denna frågan (ISO 29119) är att jag förutsätter att de som skrivit denna standard har tänkt på just detta och gjort standarden tillräckligt flexibel för att den ska gå att använda på ett bra sätt. Eller åtminstone att deras avsikt är att standarden ska vara så flexibel i framtiden efter ett antal iteration och med input från testvälden.
/Johan
Först och främst vill jag påpeka att jag inte är något fan av klassisk ontologi (vilket jag antar du syftar till). Det är filosofi. Visst, filosofi kan vara kul att diskutera över kafferasten och visst finns kopplingar till vår komplexa test-vardag. Men jag grundar inte min testmetodik på filosofiska tankar.
Ja, det är James blogg jag referar till. Vad jag vänder mig emot är att hela inlägget andas postmodernism och psedovetenskap. Något jag är mycket kritisk till. I postmodernism är allt kontextuellt och inga absoluta sanningar finns. Med en sådan inställning kan man lika gärna ge upp. Men jag har kanske missförstått hans poäng.
Det jag tydligt kan utläsa från James inlägg är att vi ska se upp för det okända. Ok, med vilka metoder ska vi göra det? Intuition? Ska vi meditera? Skämt och sido, jag känner inte alls igen mig i bilden att min vetenskapliga läggning skulle vara ett hinder för att förutse “svår-förutsedda” händelser. Tvärtom, jag menar att min vetenskapliga empirism ger mig massor med ammunition att motverka just detta. Att man sedan kryddar med sunt förnuft efter kontext förstår vem som helst, eller?
Jag tror att vi ha en ganska likartad syn men vi pratar lika olika språk – vilket ställer till det 🙂
Jag förstår dock inte vad du menar när du säger att det vi studerar (testobjektet) inte lämpar sig för en positivistiskt (vetenskaplig) ansats. Det menar jag går alldeles utmärkt. Och det är den enda ansatsen som vi kan använda.
I praktiken är det dock oftast informellt. Jag kanske “känner” att vi bör göra på ett visst sätt. Då måste jag rationalisera den känslan och komma underfund vilka mina grunder är. Min känsla bygger på tidigare erfarenheter och lärdomar. Jag kan inte säga: vi gör så här för att jag “känner” att det är rätt. Däremot kan jag grunda min metodik på erfarenhet.
Då kommer vi till den svarta svanen (vilket Hoberg var inne på). Då kanske en slumpmässig modell är svaret. Eller så försöker vi reducera komplexiteten. Bygg systemet testbart.
Håller med om att vi troligen har en ganska likartad syn men olika språk. Vi kanske t.o.m. använder ordet positivism olika? Jag är på inga sätt emot en vetenskaplig ansats till testning.
Den begränsningen jag ser i den positivistiska ansatsen (såsom jag tolkar den) är att vi utöver jämförelser mot hårda, kvantifierbara krav, kommer att ha svårt att få fram “fakta” om hur systemet beter sig eller fungerar för en tänkt användare. Vi kan inte dra hårda slutsatser, vi måste tolka och ibland “gissa” kvalitetsbedömningar (baserade på bl.a. erfarenhet/empiri).
Så ja, grunda och rationalisera känslorna, absolut. Men kvalitet är subjektivt och uppfattningen av den skiljer sig från person till person. Så att ta fram kvantifierbara fakta om kvalitet är svårt, för att inte säga omöjligt i min mening.
Som sagt, kanske tänker vi egentligen väldigt lika men att problemet ligger i någon språklig skillnad som är svår att bena ut i text/onlineforum.
Hebbe,
Du verkar värdesätta vetenskapen över religion. Det är för mig en sund hållning som jag i så fall delar med dig.
Dock så hänger jag inte med i hur du gör kopplingen till religion i James post?
James skriver om en del i vetenskapen, experiment och positivist. Men James framhäver vikten av att ta in andra delar av vetenskapen också nämligen “Social Science”, detta är som namnet ganska tydligt antyder också vetenskap.
Jag ser inte att James i sin post hänvisar eller förespråkar någonting av en religiös inställning till test.
Men då du verkar utvärdera saker utifrån ett vetenskapligt perspektiv så är jag väldigt nyfiken på ditt resonemang kring ISO/IEC/IEEE 29119. Vad är det som du hört eller sett som får dig att tro att denna standard är framtagen på ett vetenskapligt sätt?
För med mina ögon så följer detta mer religionens
karakteristisk.
-En gud – ” one definitive standard for software testing”.
-Ett gäng egenutnämda profeter – Gruppen som tar fram standarden.
-Följ bibeln annars är du oren – följ standarden annars gör du inte testning.
-Ifråga sätt inte profeten – Dom har inte bemött någon kritik alls i denna tråden utan hänvisar till att man gör märkliga inlägg och inte är tillräckligt insatt.
-Ifrågasätt inte bibeln – Standarden syftar till konsensus inte oliktänkande.
Detta var min lilla analys men jag är öppen för att bli omvänd så jag ser med spänning fram till din argumentation.
Henrik,
Se delvis mitt svar till Johan ovan.
När det gäller standards och vetenskap. Författaren till denna så omdebatterade artikel är doktor. Många av hans kollegor som arbetat med denna standard har också en akademisk bakgrund. För mig antyder det att det finns element av vetenskap.
Jag har inte läst standarden så egentligen ska jag inte uttala mig. Men min förhoppning är att den akademiska världen har samlat en del av sitt kunnande i standarden. Räcker det som svar?
Hebbe,
Akademisk bakgrund är i det här fallet irrelevant då man gör om samma misstag som tidigare och som dessutom gjorts och avhandlats inom andra ämnen. Se t.ex. min tidigare kommentar om samma debatt inom organisationsteori. Du gör till synes också ett felaktigt antagande att den akademiska världen ligger långt framme inom området, min personliga erfarenhet säger att den ligger en bra bit efter. Om människor inom den akademiska världen vill skriva en avhandling om hur de tycker all test kan formuleras så får de göra det. Men om det skrivs som en standard så kan jag påverkas i mitt yrkesutövande. T.ex. kan någon i bestämmandeposition få för sig att om jag gör fel för att jag inte gör vad som sägs i standarden, och detta oavsett om jag gör rätt eller fel…
Själva utgångspunkten i denna iso-standard är att göra en standard för all test. Här är ett urklipp från abstraktet:
“The purpose of the ISO/IEC/IEEE 29119 series of software testing standards is to define an internationally-agreed set of standards for software testing that can be used by any organization when performing any form of software testing”
Att det internationellt överenskommet är som debatten visar, i detta och andra forum, felaktigt. Det finns många sätt infallsvinklar om varför själva idén till _en_standard är felaktig. Låt oss för använda ett väldigt enkelt resonemang här och låt oss byta “testing” till “development”:
“…set of standards for software development that can be used by any organization when performing any form of software development”.
Första frågan: Varför har man inte _en_ standard för hur man utvecklar _alla_ program?
Andra frågan: Hur kan man göra _en_ standard för testning utan att först definiera en standard för den utveckling man ska testa?
Tredje frågan: Måste det inte också finnas en standard för hur alla organisationer ska se ut? Hur vet annars författarna av standarden att de verkligen täcker “any organization”?
Jag skulle vilja påstå att precis som inom organisationsteori så har en standard för utveckling avhandlats och avfärdats. Komplexiteten i olika typer av mjukvara är helt enkelt för hög för att avverka i en enda standard. Däremot finns det standarder för specifika områden och det är naturligtvis inget problem, inte heller för test. Men den komplexitet som gör det omöjligt med _en_ standard för _all_ utveckling av mjukvara är bara en delmängd av komplexiteten som finns inom testning av mjukvara.
Om man väljer att inte titta på utvecklingen inom närbesläktade områden, inte klarar av att möta rationella argument eller klarar av att underbygga sin åsikt eller teori med empiri så håller det enligt min åsikt tunt.
Varför skulle akademisk bakgrund vara irrelevant? Jag tycker liknelsen med organisationsteori är svag. Organisationsteori är för mig ett betydligt svårare område att generalisera än test. Test innehåller trots allt en hel del teknik – vilket tenderar vara lättare att standardisera.
När det gäller analogin till utveckling så måste jag missförstå dig. Det finns massor med standards inom mjukvaruutveckling. Generella och specifika. Googla lite så ser du själv 🙂
Bara för att det finns generella standards för mjukvaruutveckling betyder det inte att alla måste/vill följa dem. Detsamma tror jag gäller en potentiell generell test-standard. Om den är bra så kommer vissa att nyttja den, andra inte. Precis som för utveckling.
Jag tror att det finns generella aspekter av test som återkommer oavsett kontext. Jag har arbetat i flera olika branscher och typer av system. Därmed inte sagt att det är lätt att plocka fram en bra generell standard. Denna omdiskuterade standard kanske är helt misslyckad. Min enda poäng är att för att avgöra det behöver jag läsa den – vilket jag inte gjort.
Nu tror jag att min delaktighet i denna debatt är över. Peace!
Apropå farhågan att standarden är ett försök till “power grab” så skulle jag vilja citera Magnus C. Ohlssons avslutande stycke:
“Det primära är att redan nu börja fördjupa sig i innehållet för att förbereda sig och skapa affärsmöjligheter istället för att få en inrutad vardag när det blir ett krav att följa standarden. Det är nu det finns utrymme att komma med åsikter, inte när kraven på att följa standarden trillar in som ett brev på posten.”
Att räkna med att kraven på att följa standarden kommer att trilla in som ett brev på posten tycker jag tyder på att det finns en uttalad förväntan som säger att standarden ska sätta tonen för all testning i framtiden. Det är väl “power grab” om något?
Citat från Martin “Däremot finns det standarder för specifika områden och det är naturligtvis inget problem, inte heller för test.”
Bra, där är vi överens. Man kan alltid diskutera ifall det går att få till en standard för all programvara. Jag själv tror, visst, men den kanske blir så på hög nivå att den inte stödjer så mycket. Jag skall precis av detta skäl läsa ISO/IEC/IEEE 29119 för att veta mer.
Något som jag kanske skulle önska i denna debatt är “nidorden” som används mot yrkesfolk med lång erfarenhet och ev. utbildning. Verkar inte finnas några gränser …
önska slippa i denna debatt
Den här tråden är väl egentligen avslutad men jag tycker ändå att James Christies nya blogpost hör hemma här:
http://clarotesting.wordpress.com/2013/11/12/testing-standards-can-we-do-better/