Investera i ett ramverk för testsystem

Av Henrik Ulfhielm

Under min 30-åriga karriär inom testsystembranschen, i både produkt- och konsultföretag, har jag alltid tyckt att det är märkligt hur ineffektivt och bristfälligt standardiserat många företag arbetar med utveckling och underhåll av testsystem.

Jag har sett så många testsystem inom samma företag som är byggda i olika programmeringsspråk eller utan någon som helst konsistens med varandra, trots att de är skrivna i samma språk och finns på samma avdelning. Återanvändningen av kod och dokumentation har i dessa fall varit nästan obefintlig.

På frågan om varför de inte har en gemensam plattform eller ett gemensamt ramverk för testning är svaret ofta "Person X föredrar att skriva det i det här programmeringsspråket", "Person Y kan bara det här programmeringsspråket", "Vi har inte tid att optimera vår organisation" eller "Jag använde den här programmeringsmiljön i mitt tidigare arbete".

Det kan verka som en stor investering att få alla att använda samma språk eller ramverk, och med pressen från nästa deadline kan det kännas som att du inte har tid att ändra hela infrastrukturen för att få vinster senare. Det är ett "Catch 22"-ögonblick. Du behöver förbättra dig, men du har inte tid.

På senare tid har jag sett ett växande antal företag med en tydlig strategi för test och testsystem med ett konsekvent, standardiserat ramverk och arbetssätt. Dessa företag lägger mindre tid och pengar på att utveckla och underhålla sina testsystem.

Att inte ha en utvecklingsstrategi för test och testsystem är ofta dyrt och innebär vissa risker. Här är några vanliga scenarier som jag har sett leda till höga risker och enorma kostnader i det långa loppet:

  • Scenario 1 - "Ensamvarg"

Ett eller flera testsystem utvecklas och stöds av endast en person på en avdelning eller i ett företag.
Jag har varit den här personen, och även om det kanske får dig att känna dig viktig och ger dig mycket makt (särskilt när det gäller löneförhandling), är det uppenbarligen ohållbart ur företagets perspektiv.
Om personen lämnar företaget blir det mycket kostsamt om testsystemen behöver service eller uppgraderingar. Ännu dyrare blir det om du inte hittar koden eller om den inte är dokumenterad. Om du har tur lämnar den ensamma vargen ditt företag och börjar på ett konsultföretag så att du kan anställa dem.kodkvaliteten tenderar också att vara lägre i dessa situationer. Enskilda utvecklarteam skapar mindre dokumentation, tenderar att fokusera mindre på arkitektoniska beslut för att koden ska vara underhållbar och läsbar och saknar det dubbla perspektiv som flerpersonsteam har.
Möjliga konsekvenser: Produktionsstopp, höga kostnader och lägre kvalitet.

  • Scenario 2, "Anarki - Använd vilket programmeringsspråk du vill så länge du känner dig bekväm."

Testsystem är skrivna i olika programmeringsspråk. Varje anställd har kunskap om och föredrar olika programmeringsspråk, så naturligtvis kommer testsystemen att skrivas på olika språk. Detta är lite som Scenario 1, men om en person slutar blir konsekvenserna inte lika stora, men sannolikheten är större att det händer. Andra risker och kostnader är att man inte får någon som helst återanvändning av kod och dokumentation mellan olika testsystem. Om du kombinerar detta med ingen dokumentation och ingen versionskontroll kan du få en ännu värre mardröm när det gäller service och support av testsystem. Möjliga konsekvenser: Produktionsstopp, mycket höga kostnader och lägre kvalitet.

  • Scenario 3 - "Vi använder LabVIEW, men i övrigt har vi inga regler."

Testsystemen är skrivna i samma programmeringsspråk med liten eller ingen återanvändning av kod.
Detta är mycket vanligt, och jag skulle säga att den här organisationen är i bättre skick än scenario 2 eftersom åtminstone alla testsystemutvecklare använder samma programmeringsspråk. Testningen är dock fortfarande inte kostnadseffektiv och man har en ojämn kvalitetskontroll, men det är inte så svårt att utbilda och övertyga organisationen om att standardisera kring en programmeringsmiljö som är välkänd. För att optimera kostnader och kvalitet måste du standardisera ett testramverk och börja återanvända och versionskontrollera din kod. Möjliga konsekvenser: Höga kostnader och dålig kvalitet.

Om du är en chef som ansvarar för tester och testsystem är det din skyldighet att ta fram en strategi för tester med väldokumenterade
regler som leder in i en testplattform eller ett ramverk.

Utmaningen

Om du är ansvarig för test och testsystem och befinner dig i något av scenarierna ovan är det dags att agera nu.

Målet är att ha kostnadseffektiva tester som hjälper ditt företag att leverera kvalitetsprodukter i tid.

Detta gäller antingen valideringstester för FoU eller produktionstester.

Utmaningen är att sälja in idén i organisationen - både till ledningen och till ingenjörerna. Den sistnämnda gruppen kan vara svårare att övertyga eftersom de troligen har preferenser när det gäller programmeringsspråk, stil och arkitektur, och de kan också vara rädda för att försöka lära sig något nytt. Ledningen kommer att vara lättare att övertyga med argument som kostnadseffektivitet, bättre kvalitet och lägre risk. För ledningens del, bevisa det du säger med beräkningar och exempel från ditt eget eller andra företag.

Övertyga din organisation

Skriv först en kravspecifikation på hög nivå för dina framtida tester och ramverket för testsystemet. Den här specifikationen behöver bara vara tillräckligt detaljerad för att göra en plan och en presentation. När du har sålt implementeringen av ramverket för testsystem till din organisation kan du göra en mer detaljerad specifikation.
Detta bör omfatta följande:

  • Hur tester ska utföras på din avdelning eller testprocedurer
  • En grundläggande mjukvaru- och hårdvaruarkitektur
  • Regler för återanvändning av kod i ramverket
  • Vilken mjukvara och hårdvara ska användas i ramverket
  • Kan något eller några av tidigare testsystem återanvändas?

Andra, måste du göra en plan. Skapa ett dokument med din rekommendation om att implementera testsystemets ramverk baserat på dina specifikationer.
Den bör åtminstone innehålla:

  • Tidsplan, t.ex. ett Gantt-schema
  • Kostnad
  • Vilka resurser som ingår i projektet

För det tredje ska du sälja in planen till din organisation. Förbered en presentation som innehåller följande:

  • En översikt av vad Testplattformen är
  • Argumenten Varför din organisation behöver en testplattform:
    • Kostnadseffektivitet - visa beräkningar
    • Bättre kvalitet - visa varför du får bättre kvalitet
    • Lägre risk - ge exempel från din nuvarande situation
  • Berätta hur föreslår du att testramverket implementeras:
    • Din tidplan
    • Kostnad
    • Vilka resurser som ingår i projektet
    • Vad kan återanvändas från nuvarande testsystem?
  • En översikt över de förväntade resultat spegling vad översikt med lite mer detaljer
  • Sammanfatta med frågor

Börja med att sälja in idén till din närmaste chef och låt denne hjälpa dig att sälja in den högre upp i organisationen. Parallellt med detta kan du börja sälja in idén till dina kollegor på din avdelning och, om de är intresserade, involvera dem i processen.

Implementering

Du vann. Vad ska jag göra nu? Det korta svaret är att göra upp en mer detaljerad plan och följa den.
Följ vår blogg för ett framtida inlägg om hur du implementerar din testplan.