Software development has for a long time been a step-by-step process.
Starting with the waterfall model, where most of the development is occurs before testing begins. Software development methods based around agile then became the hip new thing.
In an agile workflow, software development projects begin with an initial idea communicated to the developers. Who then go through a development cycle (pictured below). When the development is complete. It then passes it is then onto the operations teams for final delivery to the end-user.
This can work great. However, one main disadvantage is that because the operations team doesn’t get considered until the end of development. It can feel like the developers are chucking their completed code over a wall. Hoping the operations team will be there to pick it up.
Like me cooking you a nice curry for dinner, then finding out you don’t like spicy food.
To address this problem, break down silos in teams, increase collaboration and integration across departments. DevOps then came along with the purpose of being a continuous development and deployment method to enable the rapid delivery of software products.
However, I don’t see DevOps being a replacement for agile. I think there are some great things about DevOps that can apply to agile. We should consider them as two sides of the same coin and not as one being superior to the other.
DevOps is also a culture change
It’s important to note that as with other methods of software development. DevOps isn’t a single thing, an additional checkbox, or step to be taken.
Wikipedia defines it as:
A set of practices that combines software development (Dev) and information-technology operations (Ops) which aims to shorten the systems development life cycle and provide continuous delivery with high software quality.Wikipedia
In order for developers to integrate with the operations team. It requires teams to work in new ways, to find ways of working through the barriers that have long existed to allow for a better, faster, and continuous software development and deployment life-cycle to take its place.
Enabling continuous everything
One of the key selling points of a DevOps approach to software development is the idea that everything is happening continuously or ‘just works’.
From software builds, to testing, deploying and monitoring. We need new tools to enable a workflow that requires little human interaction.
Tools like Jenkins, Chef and Puppet are popular in DevOps deployment scenarios. And in testing, tools like Selenium, Appium and API testing frameworks like Rest Assured, to create an automated testing strategy.
The lines of a software developer and tester are increasingly becoming more blurry. But in this continuous future in which things are progressively becoming automated. We should not underestimate the need for dedicated testers within development teams.
Do I need to learn to code to test in DevOps?
With DevOps emphasis on automation and the role of testing in the entire software development cycle. Testers should have some basic programming skills to work in a DevOps environment.
The need for coding skills originates from the requirement to work with and understand the automated tools you are working with.
From coding a new check, understanding why something is no longer working. Or just reading the code that someone else has produced. Being able to write and read code even at a basic level is paramount.
What about manual testing?
While you can’t (and shouldn’t) automate everything. The need for an effective automation strategy within DevOps is key to creating a successful testing process. Contact me if you need help in creating one for your DevOps implementation.
We will always need to carry out manual testing, or testing. Automation is a great tool. But it can’t explore, it can’t think, and it can’t adapt without being coded to do so. Not yet at least.
But in a DevOps world, and in future methods of software development. I think we will see a reduction in the number of manual testing methods that are being used.
That’s not to say all of our testing will be completed by an ‘AI being’, or automated testing machine. But I think testers will need to automate as many user stories, interactions, and scenarios as they can. And this will become easier as tools mature I’m sure.
So what manual testing approach is best?
As I mentioned above. Automated solutions can’t think from themselves, deviate from their coded instructions. Or adapt their actions based on real-world conditions.
However, humans can. We’re very good at it.
Which is why introducing exploratory testing into a DevOps test process is the best combination of both worlds. Being able to conduct exploratory testing alongside automated checks allows a tester to explore a system, discover any bugs catchable through automation. And keep testing activities lean and flexible within the DevOps process.
The human aspect of testing should never fully be eliminated from your testing strategy. Even as the automated development process become the mainstream. The importance of ‘manual’ process like exploratory testing becomes ever more important.
Just as software development methods evolve to meet business needs. Testing methods need to adapt to meet the challenges that these pose to our craft.