DevOps - Are testers still required and where do we fit?
Here's what we learnt from the DevOps Summit that we sponsored and attended in London.
When I first started my career in testing, I used to get really excited about going to conferences. The chance to travel and meet like-minded individuals always filled me with a childish sense of adventure. Over time, I came to realise that, not all, but quite a few of these were nothing but a sales pitch and thankfully, I found this not to be the case at the DevOps Summit.
DevOps is something I see starting to make real gains in the market however, while everybody agrees on the fundamentals of DevOps, the application and embedding of the operating model seems to differ wildly. I went to the Summit in the hope of gaining a better understanding of the successes and problems people have faced when implementing DevOps and gain a better idea of just how I can work with my teams to ensure we are positioned well to assist with this transition.
(We wrote a blog before we attended the event on what we were hoping to achieve, have a read of it)
On arrival, we were handed our badges – usually one of the most mundane occurrences at any conference but, oh no, not at a DevOps Conference! These were not just any normal badges, they were all bump enabled badges, allowing contact details to be swapped by getting overly close to strangers and touching badges together. This truly is a brave new world, goodbye business cards!
The Summit - Key Points
Into the opening session with Dan Worth, Deputy Editor for V3, who took us through the highlights from the Computing DevOps Review 2016. One of the main points, which became a key message throughout the summit and highlighted by several speakers, is that culture has to be the driving force of DevOps, with the main driver being overall IT strategy, not just by Ops or Dev strategies individually.
Finbarr Joy, CTO, Lebara Mobile* “Culture over tools every time”
Mike Dilworth, Former Agile and DevOps Transformation Lead, Sainsbury's* “DevOps is a culture not a role”
Simon Tarry, Engineering Lead, Ticketmaster “That’s a nice strategy, but culture eats strategy for breakfast”
Another point that was clearly put forward is that there is no clear distinction as to whether outsourcing is or is not necessary for DevOps. The consensus seems to be to have a team of skilled individuals that can be brought together for DevOps, not necessarily to have a dedicated team of DevOps engineers (this can drive a 2 tier company with the have and have not camps).
So, what does this mean for us? It kind of makes a lot of sense. Why would you bring in specialist resources to find they are underutilised? This is further supported by almost 80% of companies looking to train/retrain their existing staff base in the tools and mechanisms needed to implement and maintain a DevOps framework, this is a very forward thinking view which I fully support.
A change in my thinking stemmed from an idea of not fearing failure put forward by Finbarr Joy* “be prepared to fail and get comfortable with it”
I, like most of us, have developed skills in an arena which punishes failure! What seems to be the case in the brave new world of DevOps is not fearing failure but dealing with failure efficiently and with a minimum amount of impact and thus becoming “comfortable” with it.
The Summit presented a good message around the acceptance of failure. How do we react? In theory, we should accept it. How many times have we all been involved in programmes of work where we have been flogging a dead horse, working our teams to the bone in order to fix, de-scope adapt or change a piece of work, only to find when this is released it is not suitable and is either not used or superseded very quickly. The message of “learning to fail” is a very good one and one which those who work in a culture where failure is unacceptable need to strive towards changing. The failure of a project is not necessarily a personal failure and should not be seen as one. Sometimes the product or change is not right and we need to accept this and move on.
Throughout the day a number of the speakers highlighted the need to move away from traditional team structures and move to product teams related directly to the customer. For DevOps to be successful you need to change to, or create, cross functional teams and move away from the silo team structures commonly found in many organisations today. Ideally these teams should be co-located where possible or amend the way of working to enable a collaborative way of working as much as possible, using the many applications that allow teams to work together but not be in the same room. The team needs to be focussed on delivering a single or focused application with demonstrable business benefit.
Are Testers still required? YES, of course we are!
The strong message is that testing is integral to Devops “part and parcel” but must move away from being a service in the way many of us are familiar with today where it sits on the outside of the software delivery process. As testers we need to be involved much earlier in the software delivery process and remain involved all the way through the process, working in an open and collaborative approach and culture with all the other teams involved.
Testers will need to reskill to become more technical as there will be a greater emphasis on tools. Developers may become the owners of the automation, but the testers will remain the experts at testing! We will need testers who can do both. As testers we will also need to become more comfortable with micro services, deployments to environments and simulators/test harnesses, stubs and virtualised environments.
We need to move away from old school planning and more towards ensuring the product owner has heavier involvement in what we test and what is critical to the business, reduces risk and adds value.
Test Data Management is key to good testing and we should be looking at ways to create better data sets to increase and maximise test coverage.
So, what did I take away?
Going in with an open mind and testers curiosity, I left the DevOps Summit London with a clear understanding of the effect of DevOps on us as Testers.
- DevOps is a culture not a role. If the correct culture of open communication, support and collaboration does not exist, moving to a DevOps framework will not be a success and will not return the perceived benefits. The right culture needs be have buy in from all areas of the organisation and good sponsorship from senior management. You need to be prepared to be more open to risk and failure in a DevOps framework. This is not advocating taking risks for the sake of it, but to understand the risks you are dealing with, try things, and if they don’t work change them as required so that they work next time. Create a collaborative culture of open communication, support and continuous learning. We learn more from our failures than we do our successes. Don’t be afraid to change things if they are not working.Make the changes and move on.
- From a skillset perspective - I do believe this reinforces the need for testers to become more technically minded. Our continued shift left, which started with the introduction of Agile, has brought testing closer than ever to development. The more technically minded we are as testers the easier we will find it to harness the tools available to the development team and utilise them for ourselves. Imagine a world where you can spin up your own environments, create your own simulators or inject your own data.
- From a testers perspective - I have to admit I have changed my mind somewhat. Prior to the Summit, I had in my mind that this would be a seismic shift for test, however, if you work in a fully agile test team who are comfortable with Test Driven Development, Automation, Continuous Delivery and a collaborative multi team approach, the move to DevOps is a sensible one which you should embrace with open arms. If this is not the world you are working in, don’t give up but start by making small changes in culture and process that move you towards where you need to be.
Those of us in leadership positions have an obligation to ensure that we give our teams the tools they need to “Get going”. Our failure to do this will lead to the ultimate failure of the exercise. We must balance our success with the overall timescales and not let time drive us. Culture is the most important factor in DevOps and we must, as leaders of teams, ensure that we foster this culture, nurture it and help our teams grow.
