www.softwaretestforum.dk Forum Index www.softwaretestforum.dk
Virtuelle netværks forum for dem som arbejder professionelt med QA og software test
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Hvilken Testfase skal man have med i sin planlægning af test

 
Post new topic   Reply to topic    www.softwaretestforum.dk Forum Index -> Test Management
View previous topic :: View next topic  
Author Message
Marck Petersen
Bruger på niveau 5
Bruger på niveau 5


Joined: 16 Jan 2008
Posts: 86
Location: København

PostPosted: Thu Apr 10, 2008 11:17 am    Post subject: Hvilken Testfase skal man have med i sin planlægning af test Reply with quote

Hvilken Test fase skal man have med i sin planlægning af testen…?

Jeg har som reglerne altid 4 Test fase med når jeg begynder at planlægger min test

Teknisk Test
Kontrollere at funktionaliteten i de enkelte unit og komponenter uafhængigt af hinanden og at
Kontrollere at unit og komponenter fungerer i sammenhæng inden for et delsystem.

Systemtest og Brugertest
Systemtesten er for kontrollere, at systemets funktionalitet er komplet og korrekt, at data flyttes korrekt mellem de enkelte delsystemer og eksterne parter samt der kan udføres forretningsmæssige sammenhængende transaktioner.
Brugertesten er for kontrollere, at systemets funktionalitet og GUI er komplet og korrekt, i forhold til et forretningsmæssige sammenhængende

Accept Test (Krav verificering)
Accepttesten er for producere et beslutningsgrundlag for projektlederne, til at godkende ibrugtagning af systemet
+
Driftprøve
Driftprøven er for producere et beslutningsgrundlag for ledelsen, til at godkende ibrugtagning i Drift

Er der nogle som anvender andre test fase…?


Last edited by Marck Petersen on Fri Apr 11, 2008 9:56 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
Svend



Joined: 08 Apr 2008
Posts: 2

PostPosted: Fri Apr 11, 2008 8:43 am    Post subject: Hvilken Test fase skal man have med i planlægning af test? Reply with quote

Hej
Spændende spørgsmål!

Lad mig først sige at jeg er glad for den klare adskillelse mellem
•Tekniske tests, som kan kræve udviklernes indsigt i hvad de har lavet.
•Systemtest som bør laves af nogen andre end udviklerne på så færdige systemer som overhovedet muligt. Man kan fx ikke systemteste rene software features på udviklerens egen PC. Så er det ikke systemtest.
Der er rigtigt mange gode grunde til at de to typer test klart adskilles. Det er to forskellige ting.

De mere abstrakte test.

Jeg kan umiddelbart foreslå to faser mere.

Før jeg bliver beskyldt for at kalde alting test vil jeg lige prøve at afgrænse begrebet. Test er når man har frembragt et eller andet, at man så kikker efter om det er godt nok og om det oplagt kunne være bedre uden at koste mere. Det er forhåbentligt noget alle gør i større eller mindre udstrækning.

Hvis man er i en organisation hvor der er mere arbejdsvilje og flere resurser end der er risikovilje er der basis for en række lidt mere abstrakte tests.

Dokument-tests:

Før der overhovedet er lavet en prototype kan man foretage en række tests på tidlige dokumenter i udviklingsforløbet. Fx opstil en liste over alle de fornuftige krav man kan stille til en kravspecifikation. For hvert krav til kravspecifikationen overvej omkostningerne/risiciene ved at det pågældende krav ikke indfries. Kik efter om kravspecifikationerne opfylder disse krav. Det er ekstremt dyrt i slutfasen at opdage at der mangler nogen krav i kravspecifikationen, og man må ty til lappeløsninger for at gøre produktet brugbart for kunden.

Usability test på brugerinterfacet kan heller ikke vente til sidst. Lav et userinterface uden underliggende tekniske funktioner og få det testet hos en slutbruger. Opfordre testende slutbruger til at være kritisk og fx tage tid eller tælle skærmbilleder gennem de processer han laver hver dag. Om du så byger userinterfacet i Visual Studio, Flash, legoklodser eller pap, kan du ikke undgå at denne test tilføjer værdi til dit projekt.

Lad mig i denne sammenhæng også nævne min kæphest Testability. Er der i de tidlige udviklingsfaser taget stilling til hvordan det pågældende produkt bliver så testbart som muligt. Enhver kan gøre testen mere umulig, men hvordan sikrer man at testen bliver så mulig, så let, så tilgængeligt som det kan. Alle udviklere bør kende mindst et dokument der beskriver hvad der er strategien for testability i det aktuelle projekt. Og ja - kvaliteten af det dokument kan også testes.

Måske ligner det test for testens egen skyld. Uanset hvilken udviklingsmodel man arbejder med har den sikkert nogen voldsomme ligheder med V-modellen. Det første man overhovedet frembringer, er det sidste man tester. Og det er ekstremt dyrt hvis der findes fejl her. Derfor er der god grund til at opsøge metoder til at sikre at grundlæggende ting er i orden.





Test-tests/Completion-test:

Test om testen er god nok. Man kan altid teste mere og bedre hvis man har flere resurser, men et eller andet sted må man stoppe og sikre sig at der ikke er glemt noget vigtigt. Fx kik efter om der er testet for alle risici. Testarbejdet er ofte opdelt efter andre kriterier end lige enkelte risici. Derfor er det måske ikke umiddelbart synligt om der er testet tilstrækkeligt.

Mål test coverage i alle testfaser.

Mål mængden af fejl der findes og estimer hvor mange flere der kan findes hvis testen fortsætter eller hvor mange der er tilbage i projektet. Kontroler kvaliteten at sådanne test-metrikker.
Back to top
View user's profile Send private message
Flemming Wulff



Joined: 19 Feb 2008
Posts: 2
Location: Slagelse

PostPosted: Mon Apr 14, 2008 8:26 pm    Post subject: Reply with quote

Har oplevet, at man i flæng bruger begrebet testfaser og testtyper for det samme.

Med testfase mener jeg: unit-, integrations-, systemtest osv.
Og med testtype: Har et specielt formål, som kan anvendes på tværs af testfaserne. Det kunne f.eks. være performancetest, brugervenlighedstest osv.

Jeg deler testfaserne meget op "efter lærebogen":

Unittest
Skal teste funktionalitet i de enkelt moduler/programmer hver for sig.

Testen planlægges og gennemføres af udvikerne.

Integrationstest
Fokus er test af grænseflader/integration mellem:
- systemets moduler/programer
- forbindelse til andre systemer indenfor virksomheden
- forbindelse til eksterne systemer udenfor virksomheden

Testen planlægges og gennemføres af udviklerne.

Systemtest
Har til formål at teste, at systemet er komplet og korrekt i forhold til aftalt funktionalitet. Desuden vil det også være her, man skal tage stilling til test af ikke funktionelle krav (f.eks. performancetest, robusthedstest osv.).

Testen planlægges og gennemføres af professionelle testere, udviklere eller testspecialister.

Brugertest
Har til formål at sikre at systemet lever op til brugernes forventninger og bygges op i testscenarier fra brugernes hverdag. Testen har også fokus på test af eksempelvis implementeringsmateriale, brugervejledninger, F1-hjælp.

Testen planlægges og gennemføres af kravstiller/forretningsfolk.

Accepttest
Har til formål at give et beslutningsgrundlag om systemet er klar til at gå i produktion.

Testen planlægges og gemmenføres af opgave- og kravstiler.

Man kan af forskellige årsager slå nogle af testfaserne sammen. F.eks. har jeg været i projekter, hvor unit- og integrationstesten og bruger- og accepttesten er slået sammen til en testfase.

Derudover kan man selvfølgelig også fravælge de testfaser, som ikke giver mening ift. et projekt. Det kunne f.eks. være unittesten, hvis det drejer sig om et købesystem, som skal integreres i virksomheden. Eller et meget teknisk projekt, hvor der ikke direkte er berøring med brugerne. I så fald vil det måske ikke give mening med en brugertest.
Back to top
View user's profile Send private message Send e-mail
Peter Lindemann



Joined: 17 Apr 2008
Posts: 2

PostPosted: Tue Apr 29, 2008 9:54 am    Post subject: Reply with quote

Jeg kan ikke umiddelbart tilføje noget til det Flemming har skrevet, som er yderst velformuleret.

Man skal hele tiden holde sig for øje at bruge V-modellen, således at der skal være målbare krav der skal testes op imod, på hvert niveau. Man skal endvidere passe på med at en højere fase adopterer en lavere fases tests, fodi disse ikke blev nået. Her handler det om at stopppe op, standse projektet og revurdere situationen. Endvidere skal der IKKE med vilje indarbejdes tests på et højere niveau, f.eks. fejlhåndtering, som kunne have været lavet på et lavere niveau. Her skal en Fejlstyring sikre at et lavere niveaus tests omskrives / tilføjes dette element.
Back to top
View user's profile Send private message
Jesper Lindholt Ottosen
Guest





PostPosted: Tue Apr 29, 2008 12:50 pm    Post subject: det kommer an på Reply with quote

på det senste har jeg arbejdet på en testproces, hvor testfaserne i højere grad tager udgangspunkt i projektets risici og i projektets størrelse. Det giver meget godt mening, ikke blot blindt at vælge "system -> integration -> accept".

Er projektet en bette rettelse i et enkelt system, er testen nok også ligetil for leverandøren, og risikoen overskuelig. Er der høj risiko ved interfaces i designet, ja så skal interfaces testes i højere grad end forretningsgange (eller er der også højere risici her?).

Kald det praktisk risikobaseret test Wink
Back to top
Michael Thomsen
Bruger på niveau 2
Bruger på niveau 2


Joined: 17 Apr 2008
Posts: 15
Location: Allerød, Denmark

PostPosted: Wed May 07, 2008 12:09 am    Post subject: 3rd party leverancer Reply with quote

Enig med Jesper vedr. en pragmatisk holdning!
Men, hvad lægges så til grund for en pragmatisk vurdering af risk?

Jesper nævner test af 3rd party leverancer!

Der kan være tilfælde hvor man ikke har adgang til koden og internt design. (Man har formegentlig adgang til release note, test rapport og løste/udestående fejl).

Hvilke parametre skal man så danne sin risk ud fra??

Historiske erfaringer med leverandøren, Forretningsmæssigt impact og brugsfrekvens kendes ofte!

Teknisk kompleksitet, omkostning ved fejlrettelse i modulet, udvikler erfaring, historiske defects fra modul test fasen, kvaliteten af unit tests osv. kan man kun gætte på!

Altså:
enig i at test processen skal tilpasses projektet.
enig i at teste risikobaseret
Mener at man bør synliggøre hvilke kriterier man vurderer risk og dermed valg af test process.
Back to top
View user's profile Send private message
Jesper Lindholt Ottosen
Guest





PostPosted: Wed May 07, 2008 9:22 pm    Post subject: PRaktisk Risikobaseret test Reply with quote

(ovennævnte "leverandør" må gerne læses "producerende afdeling/firma").

Første dokument i omtalte testproces er "Test requirements and risk mitigation" som skulle udarbejdes sammen med og godkendes af forretningen/kunden/sponsor/ejer/rekvirent. Grundindholdet er
1) hvilke bekymringer risks skal der skaffes afklaring på
2) hvilken vægtning og hvilke krav er der til testen
3) hvilke tiltag gøres for at minimere risici
Det kan forberedes gennemføres på få timer på baggrund af kravspecs.
Altså en dialog og fastlæggelse af forventninger til test, og en erkendelse
af hvilke risici der skal vægtes højest. (tradeoff: time to market vs. quality) Først efter TRR vælges test strategi/test faser.
Back to top
Display posts from previous:   
Post new topic   Reply to topic    www.softwaretestforum.dk Forum Index -> Test Management All times are GMT + 2 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group