Lars Linderoth, Frontit, på SAST 20140402
•Transferir como PPTX, PDF•
0 gostou•566 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (7)
Semelhante a Lars Linderoth, Frontit, på SAST 20140402
Semelhante a Lars Linderoth, Frontit, på SAST 20140402 (20)
Mais de Frontit
Mais de Frontit (20)
Lars Linderoth, Frontit, på SAST 20140402
- 1. KASTA DEN HETA POTATISEN ELLER TA ÖVER DEN OLYMPISKA ELDEN Om framgångsrik överlämning från testprojekt till förvaltning 2014 www.frontit.se
- 2. INNEHÅLL Vem är det som pratar? Bakgrund Vanliga problemområden och ’root causes’ Rekommendationer Frågor, svar, diskussion
- 3. LARS LINDEROTH Ledare Testare Konsult Hjälpare Jobbat inom test jättelänge Varit konsult jättelänge Varit testledare i en massa coola projekt Pratat på massvis med konferenser Kan typ allt om test
- 6. AFFÄRSNYTTAN - EFFEKTMÅLEN Projekt Förvaltning Kostnad Förtjänst Projekt- mål Effekt- mål
- 7. DEN STORA SKILLNADEN Testprojekt FörvaltningRelease Release
- 8. VANLIGA PROBLEMOMRÅDEN • Tid för överlämning saknas • Överlämning inte medräknat i budget • Nästa projekt startas upp – man hinner inte lämna över Projekt avslutas för hastigt • Kompletta testpaket från alla testnivåer lämnas över • Testdata saknas eller är inaktuell • Testmiljöer klarar inte de nya systemen Fel testartefakter lämnas över • Räknas inte hem under projekttiden och blir nedprioriterade • Krav kring detta ställs inte Automatiserade tester saknas • Fullt upp med driftsättning • Saknar kompetens • Felaktigt organiserade Förvaltningen tar ej emot på rätt sätt
- 9. ROOT CAUSES De vanligaste grundproblemen
- 10. VANLIGA GRUNDPROBLEM • Processer är verktyg • Processer används för att undvika problem Övertro på processer • Man är inte medveten om vem som producerar det man snart ska förvalta Människor pratar inte • Förståelse för varandras verksamheter saknas • Man ser varandra som problem Man saknar förståelse
- 12. OM LÖSNINGAR Lösningar bör vara mindre komplexa än problemet Annars kommer systemet till slut att kollapsa
- 13. DO GOOD. INSTÄLLNINGEN AVGÖR. • Det gemensamma ansvaret slutar inte där projektet tar slut Det är aldrig ”någon annans ansvar” • Projekttestare och förvaltningstestare Bli kompisar! • Du lever på ditt rykte • Man mår bra av att se sitt projekt leva i verkligheten Slit för att det ska bli bra. Det lönar sig.
- 14. EARLY INVOLVEMENT • Förvaltningstestare deltar i granskning, design och exekvering av testfall • Förvaltningstestare kör utforskande tester • Testare från projekt deltar i förvaltningstestning Delaktighet Allt detta görs planerat!
- 15. OMARBETA TESTFALL • Välj ut testfall (områden) för överlämning Selektering • Välgjorda instruktioner och förutsättningar • Relevant testbas Anpassa för förvaltning • Automatiserad kontroll på testfall ur funktionalitets- och modulperspektiv • Exv: Byte av databasserver – vad ska testas? Klassificera • Lönsamt, roligt och effektivt Automatisera
- 16. ÖVERLÄMNINGSPROJEKT • Vid stora projekt eller program • Drivs, bemannas och initieras från förvaltningsorganisation • Bra sätt för förvaltning att bli aktiv Separat projekt • Skapar förutsättningar för effektiv hantering i linjen Bra övergångslösning
- 17. SAMMANFATTNING
- 18. SAMMANFATTNING Var medveten om fallgropar. Hantera dem. Övervärdera relationer. Alltid. Använd era processer som verktyg, inte som rundningsmärken. Kategorisera testfall Vid komplex överlämning, använd överlämningsprojekt.
- 19. www.frontit.se TACK! Lars Linderoth http://se.linkedin.com/in/larslinderoth/ http://www.frontit.se lars.linderoth@frontit.se 0763 – 93 63 33
Notas do Editor
- Om vi börjar med att titta på varför vi överhuvudtaget gör projekt så är det för att driva någon form av effektmål. Driver man projekt på rätt sätt så utarbetar man projektmålen utefter de effektmål man vill uppnå. Redan här går det fel för många projekt. Man fastnar i den leverans man ska göra, och ser inte till affärsnyttan, effektmålen. De allra flesta projekt är en kostnad under hela sin livstid och genererar affärsnytta, driver effektmålen, först efter sitt sitt avslut. Vi som är proffs inom test måste se den här bilden tydligare, inte bara ur ett teststrategiskt perspektiv utan ur ett underhålls- och affärsperspektiv. Projektet ska fylla ett syfte, och det börjar hända först när projektet är avslutat. Och det är inte bara den mjukvara, de processer och den dokumentation som vi tar fram som är del av det syftet, utan även de förutsättningar som projekten ger förvaltningen.
- Så vad är då skillnaden mellan att testa i projekt och att test i förvaltning? Ett projekt är till sin natur sådant att det slutar med någon form av leverans. Där dör projektet. Förvaltning är en oändlig uppgift, jag ser den som cyklisk. Man gör någon form av förändring, testar, lägger ut i produktion och så börjar man om. Så fortsätter det. Ibland kommer en större leverans från annat håll, från ett projekt. DÅ måste förvaltningen lära sig nya saker och ny funktionalitet som ska kunna testas Följdeffekter – I testprojekt är den värsta följdeffekten att en defekt stoppar testarbetet. För en förvaltningsorganisation an en defekt som har liten effekt på ett projekt vara oerhört allvarlig och kräva snabb lösning. De kan också leda till att man måste återställa data, hantera saker manuellt osv. Följdeffekterna av dålig testning är mycket större i förvaltning än i produktion Slumpartade defekter. Ett system lever mycket längre och används av många fler i förvaltningsläget – risken för att slumpartade fel uppträder är därför otroligt mycket större. Automation – I projektläget så kan automatiserad test vara för dyrt och ha för lång startsträcka för att det ska anses vara lönsamt. I förvaltningsläget är det dock nästan alltid lönsamt. Verksamhetskritiskt – Det som förvaltas och är i produktion är per definition verksamhetskritiskt. Risk – Projekt levererar ofta bara en gång till produktion, vilket gör att risker förknippade med förändring är små. I förvaltning däremot så är leverans till produktionsmiljön vardag. Naturligtvis är det mycket mindre förändringar, men risken att något går fel är naturligtvis högre. Man måste veta vilka förändringar som påverkar varandra för att kunna testa effektivt.
- Om vi tittar på projektavslut så finner man ofta att det är just avslut man håller på med, till skillnad från lämna över. Man glömmer bort att det är först när ett projekt levereras som det BÖRJAR att ge möjlighet att arbeta mot sina effektmål. Detta måste in i testtidplanen. Vi testar underhållbarhet (i bästa fall) men vi tänker kanske inte på att även de testfall som lämnas över till förvaltning kommer att behöva underhållas.