Automation in the world of project
•Download as PPTX, PDF•
0 likes•56 views
The world of a software house is a constant search for compromise between quality and costs. In many cases, the cost-cutting starts from the test automation. Then you start to talk about ROI but recognize that numbers are not on your side. We were there and what we have found out is that only a complete change in our approach allows us to find common ground with our clients. I will reveal one detail from the presentation - we are not talking about test automation with clients anymore - as a result we do it more and more. Are you surprised that success automatically generates new challenges which we further translate into opportunities? We had to reconsider our approach to the test automation environment, internal frameworks and the way we share them between projects, including code ownership, … And again, one simple but unobvious solution allows us to both deliver what we promise and to earn more on our projects. As we have been reshaping our approach to the test automation, we had to change the way of delivery too. One of the main decisions was skip out the role of test automation engineer (or software developer in test). We decided to go with the whole team approach which is consistent with the way we sell it. Find it interesting? Join me and listen to our story about how we have transformed test automation.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Automation in the world of project
Similar to Automation in the world of project (20)
More from Zbyszek Mockun
More from Zbyszek Mockun (20)
Recently uploaded
Recently uploaded (20)
Automation in the world of project
- 1. Automation in the world of projects Zbyszek Moćkun Clan Head / Global Head of QA Practice
- 3. Theworldofprojects01. Selling thetest automation02. Frameworks/ Toolsreusability WholeTeamapproach Summary 03 04. 05. Agenda
- 4. The world of projects Intro • Project-based company • Mostly Web, where the center of the galaxy are Content Management Systems (CMS) • Delivered by Adobe or Sitecore • Which are Customizable • And Integrated with everything • (even black hole)
- 5. Selling the test automation
- 6. When ROI doesn’t work anymore Selling the test automation ROI Return of Investment
- 7. The coverage Selling the test automation • Code coverage • TestCase coverage • Requirement coverage • Feature coverage • 10%, 20% ... 50%, 80% ?
- 8. Selling the test automation Does TEST AUTOMATION bring BUSINESS VALUE?
- 9. Business Values Selling the test automation • Delivery Approach • Number of releases • Continuous Delivery • Should release be production ready? • Time to release • SLA defects • Lead time (time to deliver new feature)
- 10. Business Values Selling the test automation • Extendability & Maintainability • Is it one-off or continuous improvement • Decision determines futher costs • Business critical areas • Business logic • Technical and business risks • Other client’s challenges • A/B testing • Make application authorable than require code change
- 11. Selling the test automation Test Automation DOES NOT bring business value.
- 12. Be theexpert! • Propose solution for challenges • Test automation is not always the answer
- 13. Do not ask questions such as: Selling the test automation • Do you need test automation? • What test automation coverage do you need? • Or suggest test automation as a remedy for all quality or delivery issues.
- 14. Frameworks / Tools reusability across the projects
- 15. The advantages of reusability Frameworks / Tools reusability • Cheaper • Faster • Ready and existing infrastructure • Teams are familiar with the tools • Tools are specialized
- 16. Client’s concerns Frameworks / Tools reusability • Client is the owner of the code • reuse the internal framework and give it away • List of approved tools / frameworks • Your internal frameworks are not listed • If you use internal framework • Do you share the code with us? • Who covers the maintenance costs? • How do you ensure us that we will not be in the position to get rid of your frameworks?
- 17. How muchour internalIPs are worth? Can we get additionalmoney from internaltools? Cognifide’s businessside
- 18. The results Frameworks / Tools reusability • Test automation starts very late or at the end of the project • We produce a lot of technical debt and its elimination costs us a lot more
- 19. Frameworks / Tools reusability Let’s OPENSOURCE
- 20. Client is theowner of thecode– reusethe internalframeworkand giveit away٦٦ List ofapproved tools/ frameworks –yourinternalframeworks arenotlisted٦٦ Ifyouuse internal framework– doyousharethe codewithus? Whocovers themaintenancecosts?How doyouensureus thatwe will notbein thepositiontoget rid ofyourframeworks? ٦٦ ٦٦ Client’s concerns - solved
- 21. Common benefits Framework / Tools reusability • People are proud • We (people and the company) are recognized as experts • Company values • Knowledge sharing • Building a community
- 22. The unexpected reward Frameworks / Tools reusability Bigger project scope = More money
- 23. Bigger project = more money Framework / Tools reusability • We sell automation • We train the client’s team • We build the test automation infrastructure as a part of the project • We maintain the test automation infrastructure too
- 24. Automation as whole team approach
- 25. The old way Automation as whole team approach Automation Responsibility Square –Testing Experience , June 2011
- 26. What has changed Automation as whole team approach • Improved quality of features delivered by devs • Developers interested in automation • Automation as part of application code • DoD – Delivered and Maintainable • Switch from Testing to Quality Assurance • Better understanding of Test Pyramid • Continuous Delivery
- 27. The old way Automation as whole team approach Automation Responsibility Square –Testing Experience , June 2011
- 28. The new way Automation as whole team approach Automation Responsibility Square – April 2018
- 29. How it works? Automation as whole team approach • QA as the owner • Test automation training for dev at the beginning of projects • DoR – what we want to automate • Two-side Dev<->QA code reviews • QA Demo – automation as part of the demo • DoD – Delivered and Maintainable • Automation as a part of the backlog and technical debt (assign tasks for next sprint)
- 30. Testautomationis nota businessvalue01. Open sourceopendoors02. Moveautomationfromtestertowhole team03. Key takeaways
- 31. Thank you
Editor's Notes
- The natural way of selling test automation –calculate return for investment But how to do it if there is no test cycle, or worse - you do not have a test cases for example? What if you switch to QA process and encourage devs, start testing earlies – like 3 amigos, .... How do you calculate a costs when whole team is engage in test automation, if you start using test pyramid? You are agile and quick feedback is more important? But what if there is no question about the return, what if you just need it to do something? What if the automation is rather not question about money but about the ways of working and delivery?
- We veren’t able to define what metric is the best? What does the percentage number means? In which areas. Especially our clients were very confused when we start talking about so detailed thins, which are not connected with their businesses and needs. Even one of them just ask – why you can’t just write a code as it should from the beginning But the best question that I got was: Can you just write a good quality code from the begining, so we do not need a testing?
- Who say YES? Think about that not as a tester but like client, PO, .... And we ask ourself the same question. So let’s check what are the business values
- So, we know the answer, so we define what kind of client requirements have impact on test automation. And try to define what client needs we can translate into test automation. And when we know them, we can go with the solution. At the begining we were supprised that not always mean automate more, or autoamtion wasn’t the most important one.
- Just example Clinet needs to change the labels, needs A/B testing – you do not need to deliver frequently code changes, create a feature which allo to do that Continuous Delivery – start from delivery automation, blue green deployments ---- , sometime automation is jus one of small steps and not always the most important one
- QA plan contains automation approach as in our case Estimation / costs Approach Tools Coverage, on different levels as (code, requirements / features ) Now if you came to the client with propsal (ont est automation and describe how it solve his business challengaes /needs he is more open to discuss, accept costs or jus understand the need. Just htink how easy is to say I do not need test automation and how difficult is to accept the higher costs of new features, low delivery, ...
- So we stop to discuss about test automation and not asking client about it.
- Ok, wiec sprzedajemy ta autoamtyzacje Prowadzimy 10-2o projektow, w czesci troche podobne rzeczy. Warto wiec je reuzywac. Stworzyslismy wiec wlasne frameworki, narzedzia.
- So, everything looks fine at that point. Let’s use it. So we are going to our client and .... So we are going to our client
- And the don’t like this idea as we ;-)
- But it wasn’t only client. Our business / cellers comes with other questions, which had to be discussed. And it happen almost for each new projects
- Discuss, discuss, discuss And we dicide to do something with that. We was brave and make a decision
- Client side was solved but what with our business side? I got a question several months after opensource decsion from my boss –Zbyszek, what tdo you think (I know that we open source it, ...) but how much our Ips which is open sourced was worth. (in case of – how much money we could earn). And it was the point when I realized that we haven’t lost hte money in fact. Because ...
- So in fact, we earn on this decion and increase our revenue. WE have more work, quite interesting as you see
- As you see , there is no work outside the project anymore. There is nothing like separate test automaton project. And most of the work was moved to developers. QA / Tester keep the ownership –that i happens, works, green, ... But of course helping devs, writing some tests too (yes, if you want to be good at something, you need to do it ) but the priority is that dev deliver tests together with feature (of course with help)
- is accountable)