Test av standardsystem - hur svårt kan det vara?

2011-04-18 Artikelbanken Test Läst 10507 gånger

De flesta testare arbetar i organisationer som har som mål att utveckla och underhålla skräddarsydda IT-system för en viss verksamhet. Mycket av de metodbeskrivningar och böcker som finns om testning handlar om denna verklighet.

Det finns också en annan del av IT-industrin som utvecklar generella standardprodukter t.ex. affärssystem, finanssystem, telekom eller säkerhetsapplikationer. Produkter som kunder installerar och använder i sin IT-miljö.

Att arbeta som testare på ett sådant företag är spännande, men även för andra testare kan det vara intressant att känna till mer om hur ett produktbolag fungerar. Dels för att vi alla kommer i kontakt med standardprodukter som användare eller att vi integrerar dem i våra IT-miljöer, men också för att produktbolag som ofta lever under hårt marknadstryck är tvungna att hela tiden pressa sig till det yttersta. På så sätt fungerar produktbolag som laboratorium för nya arbetssätt.

Den här artikeln handlar om de speciella utmaningar man ställs inför när man arbetar med testning av standardprodukter.

Produktbolagens miljö

Kännetecknande för standardprodukter är att de skall kunna installeras av många kunder, i olika miljöer, med olika krav, och kanske i många länder, tidzoner och språkområden. Kunderna har troligen omfattande och mycket varierande förväntningar på nya funktioner och felrättningar.

Ett produktbolags mål är att överleva och att maximera vinsten. Det finns mycket lite utrymme för att arbeta med något som inte direkt lönar sig och synen på kvalitet blir ofta krass – att med begränsade resurser få en tillräckligt bra kvalitet för att inte förlora kunder.

Flera samtidiga versioner att underhålla och testa

För att förbli konkurrenskraftigt och ha nöjda kunder måste ett produktbolag både kunna göra långsiktig strategisk utveckling och kunna hjälpa existerande kunder med felrättningar och utvalda nya funktioner. Eftersom kunderna ofta tvekar inför att göra större uppgraderingar kan det hända att man som leverantör är tvungen att underhålla även ganska föråldrade versioner.

Det är vanligt att produktbolaget arbetar med tre sorters releaser: stora utvecklingsreleaser, lite mindre releaser innefattande både felrättningar och utvalda nya funktioner, samt små, snabba releaser som åtgärdar uppdykande akuta problem.

Testningen av de olika releaserna skiljer sig väsentligt. De stora utvecklingsreleaserna bedrivs i projektform där man har tid att förbereda och genomföra omfattande testning. För de mindre releaserna där man har begränsat med tid måste man göra ett riskbaserat urval av vilka testfall man skall köra. Detta ställs på sin spets när man är tvungen att göra en akut rättning på minimal tid. Då måste man kräva av utvecklarna att de gör en konsekvensanalys av förändringarna och peka ut vilka områden som kan påverkas och måste omtestas. Eftersom man aldrig kan vara säker på en sådan analys bör man också ha en uppsättning centrala testfall som man aldrig släpper produkten utan att köra.

Att underhålla många parallella utvecklingslinjer ställer krav på testmiljön. Den måste klara av att ha flera versioner installerade samtidigt eller vara mycket snabb att ställa om. Det ställer också stora krav på hur man hanterar sina testfall. Det måste finnas en uppsättning regressionstestfall för funktionaliteten i alla existerande utvecklingslinjer, även för äldre versioner. En vanlig men inte så lättarbetad lösning är att ha testspecifikationer i form av Excel-ark, en flik för varje release, eller att man på annat sätt markerar vilka testfall som är giltiga för en viss release. Har man haft tid att investera i ett system för testfallshantering kan man ge testfallen olika attribut som gör att man lätt kan söka fram de testfall som skall köras för en viss version.

Olika parametrar och data

En standardprodukt skall passa många kunder och kunna användas på många olika sätt. Man löser ofta det genom att låta produktens funktion styras av ett antal parametrar som kundorganisationen själva sätter. Parametrarna kan styra saker som: språk, valuta, beräkningsmodeller, regelverk, säkerhetsprofiler och behörighetshierarkier. Parametrarna kan t.ex. finnas i operativsystems-inställningar, startup-filer eller i databaser. För testaren innebär det här en ny utmaning, man måste ha en strategi för vilka olika parameteruppsättningar man skall testa. Det finns ingen möjlighet att testa alla kombinationer så man måste välja. Ett bra sätt är att samla information om de kunder man har för att maximera testningen av de kombinationerna som kunderna använder.

Om produkten har en databas som kunderna själva fyller med data är det viktigt att man gör en analys av vilka kombinationer av data man behöver testa. Även en måttligt komplicerad datamodell kan ge upphov till ett kolossalt antal möjliga kombinationer. Med en väl genomtänkt strategi för vilka data man skall testa kan man täcka många kombinationer med ett begränsat antal testfall.

Även om man varit framgångsrik vid testandet av olika datafall är det stor risk det dyker upp oväntade problem när man får en ny kund som fyller systemet med data som inte liknar det som existerande kunder använder. Om man har bra samarbete med en kund kan man försöka få tillgång till kunden databas, efter det att känsligtdata tagits bort eller anonymiserats, och använda detta data vid återkommande testning.

Test av att produkten fungerar i alla miljöer

En standardprodukt skall fungera på många olika plattformar. Testningen måste säkerställa att företagets produkter fungerar på alla operativsystem man stödjer (både server och klient OS). Det kan också vara nödvändigt att testa med olika versioner av de tredjepartsprodukter man måste fungera med, t.ex. databashanterare, webbläsare och kommunikationsprogram. Troligen har företaget specificerat vilka miljöer man stödjer och har regler för när man fasar ut föråldrade versioner av operativsystem och tredjepartsprodukter.

Om man skall testa på många olika plattformar kan man vara tvungen att lägga mycket tid på att installera olika operativsystem och andra produkter. Man kan vinna på att använda virtualisering och skapa virtuella maskiner för de olika installationer man vill testa.

Kundinblandning vid test av en standardprodukt

När man tar fram ett unikt system för en verksamhet brukar det sista testet, det som avgör om man har lyckats, vara acceptanstestet. När man gör en ny release av en standardprodukt finns ingen enstaka kund som kan utföra acceptanstest. För att uppnå en liknande kvalitetskontroll kan man i huvudsak välja två vägar: skicka ut produkten till en stor och oidentifierad mängd kunder och låta dessa utföra det som ofta kallas betatest. Det andra alternativet är att man ingår en överenskommelse med en eller ett fåtal kunder som man bjuder in att delta i en kontrollerad testning eller produktionssättning. Kundens vinst blir att vara först med den nya utgåvan och en viss möjlighet att påverka funktionaliteten. Denna metod ger ofta bättre och mer tillförlitlig återkoppling.

Vilken väg man än väljer så är kundtestningen något som testarna måste engagera sig mycket i. Genom att följa upp och stödja betatestarna, eller genom att ha nära samarbete med pilotkunderna för att se till att kunderna blir positivt inställda till produkten och för att alla förbättringsförslag som identifieras registreras.

Ett annat sätt att dra nytta av kunderna är att kontinuerligt analysera de felrapporter som kommer in från produktion och stärka upp testningen inom områden där det är mycket problem.

Leveransprojekt

Vissa standardprodukter kräver mycket anpassningar och utveckling innan de kan användas av en organisation. I sådana fall brukar man låta varje kundinstallation bli ett eget projekt. Projektet kan styras av samma företag som säljer produkten eller av ett helt annat företag. Testare som arbetar i ett kundprojekt arbetar ofta på samma sätt som i ett projekt som gör kontraktutveckling mot en viss kund. Integrationstest, funktionstest, systemtest och acceptanstest är viktiga aktiviteter.

Om företaget som ansvarar för kundprojektet bedriver flera likande projekt kan man dra nytta av varandra och t.ex. återvinna testfall från tidigare projekt.

Olika företag och marknader

Det finns många sorters produktbolag och alla har sina egna utmaningar. En programvaruleverantör kan behöva förändra sin testprocess många gånger under en produkts livscykel. En ny produkt som nätt och jämt börjat utvärderas av ett fåtal kunder kan inte testas med samma långsiktighet som en mogen produkt som nått en massmarknad. Under alla omständigheter är att arbeta som testare i ett produktbolag både krävande och givande. Man måste vara tekniskt skicklig, förstå kundens verklighet, bli specialist på produkten, avläsa trenderna på marknaden och hela tiden lära nytt och förbättra sitt arbetssätt.

Konsultbolag1 har konsulter som specialiserat sig på testning i produktbolag och kan hjälpa nya eller mer etablerade produktbolag att lyfta sin testprocess för att nå högre effektivitet och konkurrenskraft.

Nästa steg

  • Baskursen Effektiv kravhantering som täcker helheten, roller och ansvar inom krav, oavsett om det gäller standardsystem eller anpassade system.
  • Baskursen Effektiv testmetodik som täcker helheten, roller och ansvar inom krav, oavsett om det gäller standardsystem eller anpassade system.
  • Påbyggnadskursen Agil test, som hjälper dig hitta rätt upplägg, omfattning och strukter i dina testfall.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln