Some Thoughts about The DevOps Era
Developing and releasing software is a complicated process. Applications now-days are more complex, and deployment infrastructure complexity grows, so are teams working on software projects.
Developing, testing, and releasing software quickly and in a consistent way, is therefore more challenging than ever. One way organizations face this challenge is to automate these processes.
In an era of DevOps, where the fact we live with applications around us in every aspect of life we turn to, new approaches to creating these applications is inevitable. Devops is best described as a culture, movement or perhaps a practice. Within this practice, companies and scholars develop new methodologies and with them are in search for new tools. For software development, for deployment, for testing, etc. From A to Z.
Continuous integration and Continuous delivery are terms used to describe one of the main approaches for this automated process. These strategies, relate to one another of course. Incorporating them into the application life cycle requires new practices and new thinking about software development projects. Part of this is a need for a new approach to software testing.
Traditionally testing is done after the code was written, with a combination of automated tests and manual tests. This phase is planned in advanced and is scheduled to allow the testers sufficient time to test and for developers time to fix any defects found by the testers, during testing.
This is all obsolete when implementing CICD methodology. The new code is deployed immediately after it was written leaving no time for testing, at least not what was called until now as ‘testing’, not to mention manual testing. In agile environments, the code a developer commits, triggers a build cycle. The definition of phases becomes vague, and everything seems to happen at once. There are automated tests that ran on the code as part of the process, but these cannot cover the required testing. Or can they?
As vendors of software testing tools, we are facing a new world of testing, with a need to find a way to deliver tools that can be relevant for a CICD environment. Until now, we were used to manual testing tools and automation testing tools. Apart. Each performing differently, and used separately by testers. Now we are faced with a need to create tools that can integrate in a whole different testing approach – it needs to be automated, fast and to allow developers and testers to quickly get reports back about any defects found (in a code which was already released). And even more interesting – and challenging – is how to include an option for those required manual tests, that no application can be fully safe, and clear of defects, without.
We don’t have yet answers, as seems to be the whole industry challenge, but the awareness and working together with end-users will most probably lead us in the right direction.