Antony Edwards, CTO at TestPlant, argues that DevOps may be an unclear buzzword for many organisations, but understanding the importance of keeping roles separate, while focusing on the customer, can allow testing to flourish<\/p>\n
The concept of DevOps has become a buzzword in recent years, with many organisations unsure of its actual meaning. DevOps, the combination of development teams and operations teams, became necessary the moment SaaS (software-as-a-service) was born.<\/p>\n
SaaS meant that development teams delivered software to their own operations teams rather than to customers, but often the operations team would say that the product wasn\u2019t fit-for-production, and too often a stubborn deadlock would result in which the customer and the company as a whole were the losers.<\/p>\n
The development team believed that the product needed to change, whereas the operations team thought that the web server environment was the issue.<\/p>\n
As a result, the purpose of DevOps was originally to make both the development and operations team communicate with each other. This reached an arguably historical moment, at the realisation that DevOpps not only should<\/em> be, but needed<\/em> to be automated through the deployment process. Today, the name DevOps has become synonymous with two phrases:<\/p>\n Continuous delivery \u2013 <\/strong>DevOps is all about delivering new value to users faster (and collaboration between development and operations is central to this).<\/p>\n Automation \u2013 <\/strong>When organisations delivered products to customers every few months the build-test-package-deploy process could<\/em> be manual (even though best-practice said it should<\/em> be automated). But continuous delivery, where new versions are released several times a day, the process simply must be automated.<\/p>\n When organisations talk about DevOps, the first adjective that springs to mind is \u2018fast\u2019. It\u2019s all about speed. Because of this, automation is essential: several hundred manual tests per day would be nothing short of impossible.<\/p>\n In light of this, DevOps teams can naturally become very inwards facing, reducing their emphasis on user experience in the process. The team is likely to focus on their own processes rather than the issues that the customers are facing, focusing on compliance rather than user-centric testing.<\/p>\n To tackle this, organisations often create another<\/em> team that immediately succeeds the DevOps team, specialising in user testing and the customer experience. In Digital Enterprises (for example, retail and banking) this new team typically lives under the chief digital officer rather than the chief information officer.<\/p>\n Achieving a balance between focusing inwards and outwards takes a while to perfect \u2014 often between one or two years \u2014 but the benefits are worth it.<\/p>\n Since the development and operations team joined to create DevOps, some organisations have eliminated roles to create an \u2018everyone is everything\u2019 structure. This in itself can be a leadership challenge, although in theory it\u2019s great for employees to take on multiple roles.<\/p>\n However, it also means that employees perfectly qualified for one role are also assigned to a completely unsuitable one, and are expected to complete that role well. This can lead to some tasks being near impractical for certain team members, severely lowering productivity.<\/p>\n The problem with leaders believing that everyone has to be doing the same role is that instead of creating cross-functional teams, the entire team often becomes focussed on the function most people are skilled at (which is typically development since \u2018DevOps\u2019 usually grows out of \u2018Agile\u2019 change projects).<\/p>\n To tackle this, DevOps teams need to be genuinely cross-functional teams which include people with different skills and strengths just like a great sports team does. DevOps teams shouldn\u2019t be a group of people focussed in one function suddenly given responsibility for all functions.<\/p>\n Alongside ensuring that DevOps teams are using their individual strengths and are concerned about customer requirements, the testing process can also be challenged. Organisations often need to test processes that teams don\u2019t have, so they must build them first.<\/p>\n This takes a considerable amount of time, which slows down the testing process. However, these tests rarely solve much larger organisational problems.<\/p>\n What\u2019s missing in several organisations is a separate group of testers that conduct the test alongside the \u2018rapid smoke\u2019 tests. These are important in an organisation, since you can\u2019t gauge user experience from 20 minutes of repression tests.<\/p>\n With DevOps teams deploying numerous processes every hour, organisations need to automate their testing to ensure that all of the processes that are created are also tested, and are tested to a high standard. DevOps may be an unclear buzzword for many organisations, but understanding the importance of keeping roles separate, while focusing on the customer, can allow testing to flourish.<\/p>\n","protected":false},"excerpt":{"rendered":" Antony Edwards, CTO at TestPlant, argues that DevOps may be an unclear buzzword for many organisations<\/p>\n","protected":false},"author":12,"featured_media":10007,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","pmpro_default_level":"","footnotes":""},"categories":[2],"tags":[145,1255,679,67,1880,1879,1881,328],"yoast_head":"\nSpeed over service<\/h2>\n
Too many cooks<\/h2>\n
Putting DevOps to the test<\/h2>\n
A brighter future for DevOps<\/h2>\n