På samma sätt som att du behöver fundera på hur du ska genomföra dina funktionella tester, är det viktigt att ta fram en strategi för icke funktionella tester. Dessa tester omfattar egenskaper hos systemet som till exempel prestanda, säkerhet, användarbarhet och underhållsbarhet.
Beroende på vilken typ av system som ska testas och vem som ska nyttja det finns det också en mängd olika krav. I detta blogginlägg finner du därför även ett urval av icke funktionella krav och vad de innebär. Kraven skall täckas av tester som verifierar dessa.
Icke funktionella tester
När det gäller icke funktionella tester bör man fokusera på de affärskritiska användningsfallen snarare än att testa heltäckande. Förutom de affärskritiska skall de mest frekventa användningsfallen prestandatestas då de utgör den huvudsakliga lasten mot systemet. Beroende på hur känslig information som exponeras och sårbarhet måste omfattningen av säkerhetstester beslutas och genomföras.
Ett bra sätt att tänka är riskbaserat, förslagsvis enligt nedan utgångspunkter.
- Kan det inträffa?
- Vad blir effekten om det inträffar?
- Vem behöver åtgärda problemen när de uppstår?
- Hur pass viktigt är det att systemet är tillgängligt? Tappas det till exempel ordrar,
intäkter och kunder på att systemet inte är igång eller öppet under en tid?
Icke funktionella krav
Prestanda
För att säkerställa att ett system klarar kraven på flera samtidiga användare behöver man utföra prestandatester. Oavsett hur väl du utvecklar systemet och hur kraftfull miljö som planeras, behöver dessa tester utföras.
Det är väldigt svårt att förutse hur pass ett system med flertal samband kommer att prestera för en slutanvändare på ritbordet. Det är först vid prestandatester du får reda på om du har tillräcklig prestanda för att systemet ska kunna gå till produktion.
Prestandatest täcker in följande områden:
- Kapacitet
- Resursutnyttjande
- Svarstid
- Upptid
- Genomströmning
- Uthållighet
- Skalbarhet
Säkerhet
Applikationer och nätverk blir hela tiden alltmer komplexa och öppna när större mängd information görs tillgänglig via Internet. Applikationer och system utvecklas i snabb takt, ofta med stor tidspress och fokus på funktion. Detta medför att produktionssättning ofta görs utan att säkerheten har varit en del i kravställningen eller testningen.
- Verksamhetsgranskning, till exempel loggning av användning av system
- Inloggning, hindra otillåten användning, åtkomst av data, rollbaserade rättigheter
- Sparande av data
- Skydda hemlig data
Robusthet
I och med att applikationerna blir mer komplexa när vi går mot mer distribuerade system med många integrationer till andra system både internt och externt. Att få vetskap om vad som hur systemet beter sig när olika tillstånd inträffar krävs det negativa miljötester som till exempel Chaos Engineering.
- Undantagshantering, såsom redundans.
- Hur väl system/komponent fortsätter fungera när den får felaktigt indata.
- Tid för att åtgärda fel
Portabilitet
Hur enkelt det är att flytta programvaran till en annan plattform/databas.
Användbarhet
- Anpassning till land och språk (valuta, datum etc)
- Tillgänglig för funktionshindrade, fungerar med talsyntes
- Personliga inställningar
- Lätt att använda
- Lätt att lära
- Kortkommandon
- Tooltips
- Felmeddelande
- Grafiskt gränssnitt (Look & Feel) överensstämmelse med företagets standard
Verktyg
Det finns en uppsjö av verktyg som kan användas till att verifiera kraven ovan på ett effektivt sätt.
Vissa krav kan genomföras manuellt medan andra kräver verktyg, till exempel prestandatest.
En del av dessa verktyg är OpenSource, andra kostar en del, vissa utvecklar till och med egna verktyg.
När det är dags att skaffa verktyg som ska stödja valda plattformar och kodspråk finns det flera saker som är viktiga att tänka på.
- Verktyget ska vara lättanvänt och gå snabbt att komma igång med.
- Budget är något som kan behöva tas i beaktning. Om verktyget införskaffas och bekostas av ett projekt är det inte säkert att andra kommer att göra samma verktygsval. Således kommer en mängd verktyg finnas som utför samma uppgifter, vilket kan vara effektivt om kunskap finns och således minimera upplärningstiden. Men för vissa organisationer eller företag är det bättre om verktyget införskaffas centralt och där bekostas löpande. Detta för att fler skall kunna säkra sina leveranser samt att kunskapen om verktyget sprids i organisationen.
- Verktyget bör vidareutvecklas löpande.
- Antal samtidiga användare, hur många skall man simulera?
- Licensanvändning, hur många kommer använda verktyget?
Oavsett vilket verktyg du väljer är ett aktivt engagemang i verktyget inom organisationen avgörande för hur effektivt och användbart verktyget blir.
Delar av ovanstående text är ett utdrag från vår nya guide "Det här bör din teststrategi innehålla". I guiden hittar du allt du behöver veta om hur du skapar en robust och bra teststrategi, alltifrån metodik till hur du ska tänka riskbaserat och prioritera dina tester. Ladda ner den här!
