Testing in a Super-Agile Software Development Environment
- 3. 5/30/16 1 Tes$ng in a Super-Agile So2ware Development Environment 9.6.2016 Super-Agile Development § Presenta>on of Nelonen (Channel 4) and Ruutu (Screen) § What were the challenges of development? § How the development is organised? § What is “Super-Agile” development? § How the produc>on updates are done? § Tes>ng in Super-Agile development § How the bugs are fixed? § Is the ad-hoc tes>ng the solu>on? § Who leads developers or produc>on? § How does the Super-Agile work? § What next? § Ques>ons
- 5. 5/30/16 3 What were the challenges of development? § 5 years deal for streaming of Finnish Champion League ice-hockey matches § Old streaming player § New business needs § New applica>ons (iOS, Android, Windows Phone, SmartTV, Chromecast, …) § New architecture concept § New development partners § New quickly changed digital world Time ”Watch what is offered" ”Watch what ever, when ever, where ever" Main TV channels Other TV channels New ways to watch Time used for TV watching Habits of watching TV are changing quickly
- 6. 5/30/16 4 Developers Ruutu backend database videos Mul>user Development Environment § The principle of Nelonen: ”all development and opera>on are outsourced” § Nelonen team only coordinates and leads the development § All development companies belongs to one team, without borderlines, “Nelonen team” § Version controls are opened to all developers § One common documenta>on § Development is also done over own borderlines Ruutu
- 7. 5/30/16 5 Ruutu’s Roadmap § Planning 6 months ahead § Headlines of development for each month § Sub>tles are detailed plans § Business is involved to development planning § More issues at the begin of table, more space at the end ”Super-Agile development” § Target is to get quickly out a working soeware § Straight communica>on, not through documenta>on § Quickly react to changes § Short itera>on rounds § Aeer each sprint there should be a ready working soeware § All teams work physically in same workspace § Subcontractor belongs to same team § Planning is done con>nuously, the whole project >me § Refractoring is done regularly
- 8. 5/30/16 6 Roadmap Sprint planning 2 week Development Follow-up Version Control Produc$on Tes$ng Produc>on update process Thursday Sprint planning Tes>ng environment update Automa>c scripts to tes>ng environment Tes>ng Tes>ng Produc>on update Wednesday Friday Saturday Sunday Monday Tuesday Automa>c scripts to produc>on environment Automa>c tests Produc>on update informa>on
- 9. 5/30/16 7 Tes>ng in Super-Agile development § Fast cycle forces to quick tes>ng § Part of the tes>ng remain to produc>on, “customer tes>ng” § Developers have responsibility to larger tes>ng § In-house only acceptance tes>ng § The scope of tes>ng is challenging – Different plahorms (iOS, Android, SmartTV, Chromecast) – Different browsers (IE, Firefox, Chrome,…) – Different opera>ng systems § Tes>ng priori>sing is done against to customer profiles Is the ad-hoc tes>ng the solu>on? § Fast schedule force to new tes>ng solu>ons § Do we have to do hasty decision? § No >me to good regression tes>ng, only >me to test the new features § Who defines test cases? – Tester - > comprehensively, more >me needed – Developer -> nothing could go wrong – Business -> is the new feature working? § Beta tes>ng with customer Even small tes8ng is be>er than nothing
- 10. 5/30/16 8 How the bugs are fixed? § The problem is marked to backlog § Priori>sing – Priori>sing – Priori>sing – Balle against to business needs § Bug fixing – Are the developers responsible for tes>ng? § Tes>ng version – Which is the latest version? – Is this the last version before produc>on update? § Retes>ng – Is there enough >me to regression tes>ng? § Produc>on update – When is the suitable moment to update the produc>on? Who leads developers or produc>on? § We can’t only fix bugs, we need also to develop § It is exci>ng to develop new features § Let’s make a hohix § Business pressures § More complex environment (new plahorms, new products) § Produc>on problem: “fixed and gone” § Documenta>on takes too much >me § Friday aeernoon – let’s make a produc>on update… § When is the best >me for produc>on update? § Is the tes>ng done enough comprehensive? § Who has the responsibility of tes>ng? Developer or Produc>on? § Pressure from customers § Let’s not blow up ones the whole package § New features will break old features § Where is the update log? § Tes>ng and produc>on cost too much Developer Produc9on
- 11. 5/30/16 9 How does the Super-Agile work? § Super-Agile method is fast and flexible § Fast reac>on to changes § Business needs are easily fulfilled § No bureaucracy § No >me spend to documenta>on § Compact development team § Fast reac>on to customer feedbacks § Development is possible to execute in small groups § No >me to tes>ng § No >me scheduled to tes>ng § Bugs are frequently found in produc>on environment § Lack of documenta>on and changelog § Communica>on cri>cal, example Skype chat § The team should work closely, if possible in same room § Group discipline, no possibility to solo person § Using several subcontracts What next? § Development cycle and speed must slow down § Produc>on updates should be scheduled and predicted § Let’s not blow ones the whole package § Project plan and schedule § Separated development, tes>ng and produc>on environments § Outsourcing tes>ng? § Listening more customer feedbacks § Big company – own regula>ons § Are we at the end of agile development? § Is everything ready?