Download to read offline
Uploaded byMatt Mansell
Surviving the DevOpocalypse; a DevOps survival guide for testers
The document discusses the challenges and adaptations necessary for testers in the context of DevOps, stressing that testing should be integrated throughout the software development lifecycle rather than treated as a separate function. It emphasizes the importance of understanding value streams and embracing change as opportunities for growth and improvement, while also recognizing the differences between technical and adaptive challenges. Lastly, it encourages individuals to lead change from their positions within organizations and collaborate effectively to enhance overall quality and efficiency.
More Related Content
Similar to Surviving the DevOpocalypse; a DevOps survival guide for testers
Surviving the DevOpocalypse; a DevOps survival guide for testers
- 1. Surviving the DevOpocalypse A DevOpsSurvival Guide for Testers
- 3. What is DevOps? •The Principles of Flow • The Principles of Feedback • The Principles of Experimentation and Continuous Learning
- 4. A Software DeliveryValue Stream Customers Project Mgrs Product Development Sales & MarketingCapabilities New Requirements Business Mgrs Concept & Consumption Product Related Product Related Product Related Shared Capability Shared Capability Business Development Operation & Support
- 5. What could gowrong? Customers Project Mgrs Product Development Sales & MarketingCapabilities New Requirements Business Mgrs Concept & Consumption Product Related Product Related Product Related Shared Capability Shared Capability Business Development Operation & Support Not involvedGut feel Too Many selected No incremental development Poor practices No big picture Not involved during build Over promise
- 6. DevOps is anexistential threat to testing You never change things by fighting the existing reality. To change something, build a new model that renders the existing model obsolete. R Buckminster Fuller
- 7. If we don’tdo it to ourselves someone else will do it to us The prospect of being hanged focused the mind wonderfully Samuel Johnson
- 8. Splitting the proverbialhair Test Is a separate function in an organisation Is ‘responsible for testing’ Is often seen as an (un)necessary expense Must estimate and get involved according to strict scope Testing Is embedded throughout the lifecycle Is everyone’s responsibility Is seen as vital Is included in everyone’s estimates as a part of what they do
- 9.
- 10.
- 11. My apologies toanimal lovers
- 12. This is anadaptive challenge for testing A Technical Challenge: An Adaptive Challenge: Is easy to identify Is hard to identify and easy to deny Most of the time has a quick and easy solution (tried and tested) Requires changes in the ways things are done (changes to the approach to work) It can generally be solved by expertise or authority People who are working from where the problem is generated are able to solve it Requires small changes that are within organisational boundaries Requires changes across lots of places which may cross organisational boundaries People are generally receptive to technical solutions People resist acknowledging adaptive challenges let alone receiving the possible solutions Solutions can be implemented fast and by authority Solutions emerge from experimentation and discovery, and can take a long time to implement
- 13. Surviving the DevOpocalypse meanschanging yourself “Be the change you wish to see in the world” Mahatma Gandhi
- 14. Embrace change asan opportunity “The secret of change is to focus all of your energy not on fighting the old, but on building the new.” Socrates (Johnson)
- 15. Build on changeopportunities
- 16. Understand the valuestream… Map the value stream Create flow Establish pull Pursue perfection Identify value
- 17. …And how youcontribute value to it From Friction To Flow
- 18. Widen your definitionof our craft What we are now: What we could be:
- 19. Together vs separate Thereis a difference between editing and proof reading. Author and editor co-create. A proof reader just highlights mistakes.
- 20. Leadership vs Management Managementis doing things right; leadership is doing the right things
- 21. Learn how tolead change from where ever you are https://www.silverplatypus.com/cart/lean-change-m
- 22. Seek “on thebalcony” moments
- 23. Get close tothe user and/or get technical
- 24.
- 25. References • http://blogs.forrester.com/mike_gualtieri/11-02-17- want_better_quality_fire_your_qa_team • https://www.linkedin.com/pulse/20140817172649- 73355280-let-s-get-rid-of-software-testing-or-not •Adaptive Leadership • Leaders Eat Last • The DevOps Handbook • The Lean Enterprise • Lean Change Management
- 26. Contact me ifyou want to talk Matt.Mansell@integrationqa.com https://www.linkedin.com/in/matthewmansell/ Twitter: @mjmansell
Editor's Notes
- #3 Hi, I’m Matt Mansell. I used to manage the testing services team at DIA. For the past three years I’ve been working at IntegrationQA helping organisations formulate and implement strategic change; especially change to DevOps. I’ve been working with executives and other leaders in organisations to help them understand what needs to change, why it needs to change, and how they can lead the change. I’ve also worked with testers, developers, architects, release & change managers, programme and project managers, PMO’s, procurement teams, finances teams etc to help them understand the journey of change and to make the kind of change required to really make Agile and DevOps sing. What I’ve learnt in this time has fundamentally changed my view of testing. [Animation] We believe this don’t we? We have too. Our profession is based on it. Our career edifice is built around this very assumption. This is testing’s reason for existing. When I was taught testing in 1999 it was drummed in to me on the STUD course. Yes, I’m a qualified STUD. Software Testing for Users and Developers. It’s all through the ISTQB syllabus. It’s drummed into us and into organisations. Writing code causes bugs and bugs need testers to find them. Independent testers. We believe that developers are incapable of writing code that is bug free. We believe that BA’s cannot accurately elicit requirements. We believe that architects can’t architect things properly. We believe project managers can’t run projects properly. We don’t believe that users know their own work well enough to test it. Whether you agree or not; conversations about these topics have been the hallmark of the last 19 years of my IT career. It’s certainly my experience that Testers don’t really believe anyone can do a good job. Except maybe themselves. It’s also my experience of conversation of conversations with developers, BA’s, Architects, PMs, IT Managers, Business Managers, Users and the like tend to think that testers think like this. I think many companies sell their testing services through a fear based approach that implies that quality is unachievable without testing. [Next Slide]
- #4 So what is DevOps? Anyone want to offer a definition? DevOps (a clipped compound of "development" and "operations") is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives. There are a lot of people out there selling tools that, if you implement them, will mean you are doing DevOps. Don’t get me wrong, tools are essential to really robust DevOps, but DevOps is far more than a toolset. It is way of thinking about our work. It is a culture, a mindset, a collection of practices. An attitude. Amazon webservices talks about it being: “DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity”. [Animation] So it’s not about technology. I have seen some pretty good DevOps happening simply because Developers and Operations people worked on the same team. I’ve seen terrible DevOps because a company had bought a tool that was now owned by this group and they were the DevOps team and sat in their silo. Has anyone read the DevOps handbook? The authors talk about the thee Ways of DevOps. The Principles of Flow is about optimising the value stream, removing waste, reducing batch sizes, removing hand offs between silos. The Principles of Feedback are about reducing feedback loops, amplifying signals, removing intermediaries. The Principles of Continual Feedback and Experimentation, are about constantly optimising our workflow, changing how we work based on the feedback, always looking to improve and refine how we deliver.
- #7 R Buckminster Fuller Many of the conversations I end up having with executives and senior managers end up revolving around perceived barriers to flow in the value stream. And guess what comes up as a topic of conversation over an over again? Testing. DevOps is exactly the kind of challenge to testing the R. Buckminster Fuller is suggesting here. The paranoid among us could see this as all the other parts of IT colluding to get rid of testing. Geoscience Australia laying off all it’s testers. DIBP example: 150 testers executing 60000 tests. No-one can tell me the value of these tests. BHP example. No defects in production in a year, 1 defect found by business in three years. No testers employed.
- #8 Would you fly in an airplane that was flawed and they were waiting for further funding to fix the problems? Would you buy a brand new house knowing there were critical flaws in it on the promise that the builder would fix them in a future release? No. You expect these things to have been built to be beautiful from day one. Why have we assumed that this is not possible in our industry? Is it because we, as a profession, have a vested interest in telling to the story about how it’s not possible? My experience over the past three years is increasingly that this is how Test is being seen by others in the lifecycle or dependent on it.
- #9 Samuel Johnson In his blog for Forrester consultant Mike Gualtieri tells of a client who got rid of their test team. In 2011. “The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn't work, the developers can't say that "QA didn't catch the problem." There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.” Lorraine Bracco wrote: “You can't change other people. You can only change yourself.” What I’ve learnt is that by changing how I think, communicate and act, slowly others change in reaction. We can change. Or others will change us.
- #10 I want to make an distinction here. There is a difference between Test and Testing. I heard Test describe as insurance that doesn’t pay. It’s sold to business owners as risk mitigation. But then when risk is realised Test blames everyone else. It’s not that there is no place for expert testers in DevOps. I went to a presentation by the Head of QA for Ebay where he talked about the teams being built around the tester, that the tester was the only indispensable member of a team. But this is not testing as we know it Jim
- #12 Organisms live in an environment, they are optimised for it. When the environment changes they are faced with a singular choice. Adapt or die. Organisations are the same. As are individuals. Change is a reality. We can’t stop it or prevent it. But we can control how we react to it. There is a leadership framework called Adaptive Leadership that is based around this principle. Those that adapt succeed. Those that don’t die.
- #13 This is technical challenge for the Lion. It can solve these problems within it’s current resourcing. The problem is easy to identify and their tried and true patterns of behaviour that will work (mostly) to solve the problem. This is an adaptive challenge. Something happens outside the ecosystem that the lion is designed to operate within. If the lion does not learn how to adapt to this challenge it faces extinction.
- #14 This taken from Adaptive Leadership is a practical leadership framework that helps individuals and organizations adapt and thrive in challenging environments. It is being able, both individually and collectively, to take on the gradual but meaningful process of change. It is about diagnosing the essential from the expendable and bringing about a real challenge to the status quo. In adaptive leadership they talk about recognising adaptive challenges. When an adaptive challenge occurs you take the best of what you do now and mix that with new ways of working to adapt to the problem. A change in scope on a waterfall test project is a technical challenge. A change in the way a development team writes is code is an adaptive challenge. “On the dance floor” vs “On the balcony”.
- #15 We need to adapt. We need to change how we think about our work. As individuals, as members of a team, as staff in an organisation, as members of an industry.
- #16 “Disruption” is the new buzzword. Personally I’m not a fan. It focussed too much on the wrong thing. Disruption makes it sound bad, like the thing that was being disrupted was wonderful and we should be sad or angry that something has come along and messed with it. What’s happening with Uber is a good example. The existing industries that used regulation to reinforce their market position are now fighting a rear guard action to stave off the inevitable. They demand the government do something about it. But, for the most part, governments have not fought it, because competition in the market is seen as a good thing. As I said earlier, change is a fact of life. Protesting against it rarely, if ever, prevents it. Change leaders are likely to see you as resistors who are unlikely to change and therefore you’re probably standing in from of a steam roller (Austin Powers – in government the steam roller is very slow). This is Socrates, or Socrates Johnson as Bill and Ted called him: “The secret of change is to focus all of your energy not on fighting the old, but on building the new.” He’s got it right here. Change is coming in our industry, in our organisations, to our jobs. Don’t waste effort fighting it, rather, look for how you can roll with it, how you can catch the wave.
- #17 My 6th form drama teacher, Linda Gordon told us that successful theatre sports meant you had to receive new ideas and grow them rather than reject them. I’ve carried that approach through my life. Yes and is a better way to deal with change, and with challenges to our way of working. When someone asks you: “Can you do this new thing?” Think and say “Yes and here is something I can add to it.” If you say “Yes, but (I need training, I don’t know how, etc)” what people here is no. Now obviously you shouldn’t just do anything you are asked. But if you take a “Yes and…” attitude into your daily work, you’ll be surprised at what opportunities might come up. I’ve been working with a guy who is new to IT. I’ve thrown all sorts of things at him. He’d said yes. He’s not shy to say, I don’t know, but he doesn’t stop there. He says, “Yes, and if I have any questions or new help, I’ll ask for it.” And he does. I’d recommend him to anyone, for pretty much any work, because with that attitude, he can do just about anything. When I was in a manager I’d put challenges in front of people , opportunities to grow. Things people hadn’t done before. The ones who said yes and were the ones who did better over time. When your boss comes up to you and says; “I know you have never done it before, but do you want to join this new team that’s going to try DevOps (or Agile, or any other good thing)” I encourage you to think “Yes and…”
- #18 DevOps is a way of being Lean in an IT context. Lean is based on the Toyota Production System, it’s a customer value focussed way of thinking. The goal is to deliver value to the customer is efficiently and effectively as possible. I don’t mean other customers in the value stream, like Developers, I mean the end customer. These are the core values in Lean, you’ll see various lists on the web, but these are at the heart of it. The Three Ways of DevOps are a re-articulation of these values. The Agile Manifesto is a specific, localised articulation of these values for software development. Lean is focussed on optimising the value stream to create flow. Flow is the state where valuable things customers want, in our case software, is developed and put in their hands quickly, efficiently and to a very high standard. DevOps is how to do IT “better, faster, cheaper.” Anything that creates friction in the value stream is classed as waste. Waste is to be mercilessly identified and eliminated. I have so many good examples of waste in value streams. The 60,000 test cases I talked about earlier is one. In the same organisation there are examples of people needing 40 to 60 signatures to get documents signed off. I guarantee that only two or three of those people actually read and understand the documents. As senior leaders in organisations come under increased pressure to find leaner ways of delivering, people like me are called in, and we see these enormously wasteful practices as creating friction in the value stream and as low hanging fruit to demonstrate how to do things differently. In another organisation a tester identified 99 test cases they were going to run on date fields. 9 tests, 11 date fields in the application = 99 tests; each release. When I asked the lead developer if there was a single unit of code that did dates she said there was, it was an out of the box library that they hadn’t altered, it came with a set of tests that ran every build. Still the 99 tests got run. There were no date field defects found. Waste.
- #19 And, more crucially, understand how you individually, and your ‘practice’ contribute value to it. [animation] This is a representation of the value stream I see in many organisations. When we presented this at Immigration, it was controversial. A number of groups didn’t like it, including the testers (pretty much everyone in the reverse fishbones didn’t like it). The testers argued that they were in the value stream, not imposing their function on it as the diagram represents. You want to build a house so you go out and hire a building inspector. Have you built the house? No. You hire an architect to write up blueprints. Have you built the house? No. You bring in a project manager to get things done. Have you built the house? No. You get an engineer to give you a site report. Have you built the house? No. At some point you need to engage the actual builders, be they carpenters, plumbers, electricians or whatever. You can have all the building inspectors in the world, waste your money and still have no house. Independent, manual, functional or non- functional testing, by test professionals, does not contribute value to the value stream. Every dollar spent on these people, is a dollar not spent on writing code or implementing infrastructure. Every dollar spent on building inspectors is a dollar not spent on hammering in nails. One thing I see a lot in testers is that we only see our link in the chain. We only see our little part of the value stream. This fundamentally undermines our ability to contribute value. This makes us into Building Inspectors. Proof readers. Insurance assessors. We become a problem to be overcome rather than a valued partner. When we think inside our silo we undermine our own value proposition. And we have tremendous value to offer. Learn to see the system as a whole. If you want to survive the DevOpsopcalypse under stand the value stream. Both in general, and in the context of your organisation. How does the how thing deliver value? How does your work contribute to that? Where is the waste in the value stream that you can do something about? Ask yourself, how can I become an enabler of Flow. In almost every case it will mean doing less, not more.
- #20 A lot of testers don’t see their craft as being anything but testing software, and maybe reviewing documents. To me testing is a philosophy, a worldview, and when used in such a way all of a sudden it’s valuable everywhere. One of the key skills we are taught as testers is to ask questions. To question everything. I had an architect colleague tell me the best test manager he worked with was constantly asking his questions and as she did he found it refining his work. Testing is simply experimentation. Form a hypothesis, try it out, measure the results and then form further hypotheses based on this. You can do this anywhere in anything.
- #21 This is a key distinction. Much of the way testing happens today, much of the way it is structure, the way testers are trained and indoctrinated, is to be proof readers. We have bought into a worldview that demands that some other party (i.e. us) own this independent testing thing. I think that is being shown up for what it is. At best misguided. At worst self interested to secure our jobs. What we need grasp is that we have a unique view of the lifecycle, we have valuable insights, we can add significant value to the value stream. But we need to stop celebrating our role as provers of other people’s mistakes. We need to stop being the people who always talk about what has gone wrong. We need to stop proof reading. When we don’t see ourselves as independent arbiters of quality, but as co-creators of value, then we don’t have to defend some arbitrary ground that we have carved out. Instead we are looking at the whole lifecycle going how can I bring my unique skills, experience and training to bear to help the team deliver a high value outcome. This is a cultural change. It’s a change to the way we think about our work. It’s a change to the way we train testers. It’s a change to the way we discuss our work between ourselves and with others. In DevOps, the real value of test professionals is as editors. As c0
- #22 Who here is a project or programme test manager? You need to think about how you will change. If a team is self organising why are you needed? Agile has put Test Managers on notice, DevOps is putting them against the wall for execution. A team doesn’t need to be told to do the things right. The product owner works with the team and the business to develop a prioritised backlog and the team works through that. If the team is working well they are estimating testing into their daily work. They are all doing testing in their daily work. What do they need? Someone who will help them do the things right. An advocate for the customer, the business outcomes. Someone who can help everyone in the team lift their test practice. Wouldn’t it be great if the measure of success for a test effort was that the tester ran no manual test cases? Because everyone else in the lifecycle had already done the testing. Instead the tester was the bridge for business users and customers to reflect feedback into the team. They coached and helped the others in the lifecycle test their own work. They agreed automation and wrote that so it could be run every time code was checked in. And Test Managers? Well, there is an example of what that expertise could become right here in Wellington. The BNZ have set up a test (and other delivery practice) coaching team. Their job is to be advocates for quality and improvement. To help teams get better. They are contributors to the principles of feedback and experimentation and learning. At immigration and border protection I wrote a coaching framework to build high performing teams. We’ll have development, test, Agile, and other coaches. We wanted an overarching framework so that the outcomes for teams and coaches were clear and so that there was a consistent approach that allowed for diversity. It’s worked pretty well. Test managers could become test coaches. Or you could consult into teams, helping them solve wicked problems. Helping them by doing the stuff outside like getting tools, dealing with organisational processes, advocating for quality and testing into the rest of the organisation.
- #24 I mentioned on the balcony vs on the dance floor. It’s very easy to get bogged down in the day to day in your job. To not see what is coming on the horizon; either in your project, your organisation or in the industry. Seek moments to get on the balcony and observe the dance from afar. It will improve your dance. You’re already doing this by being here. Conferences, working groups, meet ups, coffee with colleagues in other projects or disciplines. Ask for feedback. If each of us start thinking like this we’ll be well ready for when the change comes for us. In fact we might even become initiators of change.
- #26 Prosperity belongs to those who can learn new things fastest.