Advertisement
Advertisement

More Related Content

Advertisement

More from Maaret Pyhäjärvi(20)

Advertisement

Lean Startup and Intrapreneurial Testing

  1. From Lean Startup to Intrapreneurial Testing Maaret Pyhäjärvi Email: <maaret@iki.fi> | Twitter: maaretp
  2. Testers See the World Differently Testers start at the end, and work through the product from quality in delivery. Empirical evidence over theory. Builders start at the beginning, and work through the product for quality in delivery. Theory to handle versatile cases.
  3. We are never just something. Be aware of your use of time. Opportunity cost - what you don’t do since you are doing this?
  4. From Idea to Implementation Customer (business owner) End User Implementing Product / Solution OPPORTUNITY SPACE IMPLEMENTATION SPACE Details Pipe: One thing at a time, focus Funnel: Going through the options and making a selection 4 Ideas
  5. Testing feeds development before development again feeds testing
  6. Traversing Back in Lifecycle Time …in my life Testing features in systems Requirements Reviews AGILE Testing Contracts Testing changes in systems Co-creating Specifications Testing Business Models Testing Product Backlogs
  7. Testing Business Models Time …in my life Testing features in systems Requirements Reviews AGILE Testing Contracts Testing changes in systems Co-creating Specifications Testing Business Models Testing Product Backlogs
  8. Selling the product / feature before implementing is a test
  9. Lean Canvas (Ash Maurya) and Business Model Canvas (Alex Osterwalder)
  10. Understand the risks Know your business model
  11. Testing Product Backlogs Time …in my life Testing features in systems Requirements Reviews AGILE Testing Contracts Testing changes in systems Co-creating Specifications Testing Business Models Testing Product Backlogs
  12. Do we really need that? Can we make it smaller?
  13. Spot the assumption! “Always a feature away from success” Make your assumptions cheaper.
  14. Software Development is about Continuous Learning "Scope does not creep; understanding grows." -Jeff Patton
  15. Co-creating Specifications Time …in my life Testing features in systems Requirements Reviews AGILE Testing Contracts Testing changes in systems Co-creating Specifications Testing Business Models Testing Product Backlogs
  16. We built a feature three times before it was taken into use. Unintentionally.
  17. Customer Experience over Features
  18. Quality Power of Collaboration
  19. Quality Power of Collaboration “It’s about getting the best (not the most) out of everyone”
  20. http://leanpub.org/mobprogrammingguidebook #MobProgrammingGuidebook
  21. Testing changes in systems Time …in my life Testing features in systems Requirements Reviews AGILE Testing Contracts Testing changes in systems Co-creating Specifications Testing Business Models Testing Product Backlogs
  22. Certainty “I know what I know” Exploit Caution “I know what I don’t know” Explore Amnesia “I don’t know what I know” Expose Ignorance “I don’t know what I don’t know” Experiment Looking at World from Different Angles UnitTesting ExploratoryTesting Builder view Tester view
  23. What Testing Gives Us UnitTesting ExploratoryTesting SPEC FEEDBACK REGRESSION GRANULARITY GUIDANCE UNDERSTANDING MODELS SERENDIPITY Testing as artifact creation Testing as performanc e
  24. Thank you. @maaretp (please connect with me through Twitter or LinkedIn)

Editor's Notes

  1. Experiments are tests to learn about your assumptions. In this talk, we look into lessons of a tester helping with relevant experiments in intrapreneurial setting: a startup environment within an established company. We learn from discussions that take place allowing a thinking tester as far left as possible, before implementation: testing the user experience for features we need, testing the need of features to identify if what is asked for is worth building, and testing the elements of the business model to steer towards customer satisfaction and financial success. This talk provides thinking tools and ideas for a tester to contribute in the opportunity space, before entering the implementation pipeline. Unleash the entrepreneurial talent of testers to boost innovation!
  2. Empirical evidence vs. speculation Testing feeding development before development again feeding testing
  3. Story: implementing the basic equipment list – no one outside wants it. Implementing the equipment acceptance process – no one wants it even internally and now implementing concept. Unhelpful attitudes in development team is to stop this or say you needed to know in advance. Example: if we knew this when we implemented… But we did not. And while we focused on doing what we did, we got that out and it brings value already. hindsight and forward thinking attitude, let yourself learn when the software speaks to you, don’t punish yourself for not being perfect yesterday, treat every day as a learning opportunity (games, save point and do-over) Agile is about lowering the cost of change that is inevitable anyway.
  4. SOMETIMES YOUR BUSINESS DOES NOT KNOW IT.
  5. Example: if we knew this when we implemented… But we did not. And while we focused on doing what we did, we got that out and it brings value already. hindsight and forward thinking attitude, let yourself learn when the software speaks to you, don’t punish yourself for not being perfect yesterday, treat every day as a learning opportunity (games, save point and do-over) Agile is about lowering the cost of change that is inevitable anyway.
  6. Gojko’s SBE workshop: ”It’s about domain modeling – making business terms match the technical implementation”
  7. Unit testing focuses on what we know should exist.
  8. “there’s a process of knowing” – learning Does not give as regression; serendipity (safety against things happening randomly) / unwanted serendipity events. This is what it is and what it could be. There’s a direction to it, not just statement of what it is. Coaching is not just feedback, it’s pointing them to the right way. Safety. EXPERIENCE (the verb) rather than facts ; emotions over facts. REACTIONS. HISTORY, Lessons learned, checklists. Modeling. UNDERSTANDING – where you start (knowing the thing (code & environment), knowing the user, knowing the problems, knowing the developers (how to help them and what they do so that you can efficiently test), knowing the hackers (weird use cases outside common ‘have you tried reading it upside down’) , knowing all stakeholders, knowing the business priorities) Uncovering things I cannot know, giving the application a change to reveal information for me. This allows you to know things.
Advertisement