This past Tuesday, the annual State of DevOps Report for 2017 was released. The report is one of the most respected in the industry and attempts to measure and comment on the direction that a broad range of organizations travel on their DevOps journey. There are usually some interesting comparisons and trends to analyze against the previous year’s results also.
The report is
When I was a junior developer, the sort of books and blogs I read off-the-clock tended to be about design patterns, abstractions, test-driven development (TDD) and so on. These topics haven’t gone away, but these days we tend to focus more on rapid application delivery, continuous integration, feedback loops and continuous improvement in the development process of that software, not necessarily the software itself.
Much of the classic developer reading material has strong craftsman-like overtones, the excellent Pragmatic Programmer being the most obvious example. On the other hand, some of the more recent material, like Continuous Delivery or The DevOps Handbook, describe the process of developing software as a factory production line to be optimized, inspired by the lean manufacturing revolution at the likes of Toyota in the 1980s.
Is the change in imagery from the master artisan to the fine-tuned production line a sign of progress or something to be worried about? It looks like the software industry’s Industrial Revolution might have started.
If you’ve read my definitions of unit testing and system testing in my Ten Tenets of Test Automation, you’ll know that the primary differences between the two are target audience and granularity of coverage. Unit tests seek to validate the intentions of developers at a very fine, narrow scope, often at the function or small class level.
There should be lots of these fine-grained checks to validate your code base. Having them helps you understand the impact of evolving requirements. Having to deal with change in the life of developing a product is as certain as
Back in February, I was given the chance to deliver a presentation for the BCS, the chartering body for IT and computing in the UK, on the evolution of the software development lifecycle as we race into the Cloud era.
Well, I say that. I was originally approached to do a talk about test automation, but as I was thinking about what I might be able to add to that arena it occurred to me that the testing phase of the classical SDLC gets far more coverage from an automation sense than any other. Much of the modern thinking on how to deliver software efficiently automates much more of the process than just the testing. I began researching how the most progressive teams used automation to drive some of the lesser covered phases and a talk on how automation technologies are taking these over became much more compelling to me. Hopefully, the audience agreed!
Like most software developers, my first taste of automation was in the field of testing. When I was barely out of my teenage years, my first internship involved developing a system based on STAF (an open source test automation framework) for a server/workstation production line. That was quite a long time ago, but I’ve been involved in both writing automated tests for software products and frameworks to orchestrate them in a variety of roles ever since. Here are the ten most important things I have learned in test automation since then.
The outage of the Amazon S3 Service in Northern Virginia on the 28th of February 2016 was a warning shot to all of us involved in the delivery of software services of all descriptions. It made front-page news and highlights the scrutiny that public cloud providers are under and how much they are relied upon.
