The DevOps philosophy is on its way to change our whole development chain which we’ve followed over many years, and especially once neglected disciplines such as security and performance testing will move to the forefront soon. In this post, I will outline the reasons for this development.
Nowadays, fast time to market is essential for the success of many businesses because the competition is high and addressing market needs fast guarantees more revenue. Organizations tend to release new products earlier to their customers and accept certain risks just to win the race against their competitors. At the same time, new technology appears on the market which brings significant changes in many sectors. There is Docker, the new container technology which will change the way how we deploy and operate applications entirely.
QA teams often rely on manual regression tests to guarantee the core functionality enriched with a few verifications of the new or changed features. Due to severe time constraints, testers often have not enough freedom for performance or security tests. Even release sprints are too short for proper maintenance of automated tests. Frequent changes make automated test execution anyway useless.
Strategies to deal with this dilemma
1. Make performance and security everyone’s matter
You can’t do more in less time, so your only chance to win the battle against short testing cycles is to involve earlier and later stages in your QA activities. Many leaders talk about shift left and preach this to their folks. Developers are already doing a good job when it comes to unit testing. However, response times or secure code analysis is still neglected in those early stages. Static application security tests are easy to automate. Choose a flexible platform which can scan your source code and provides insights about actual vulnerabilities as soon the code gets checked in. The same applies for load and performance tests. Select your core services, schedule a daily concurrent user load test and compare response times fully automated with corresponding baselines.
Earlier deployments into production increase the likelihood that our customers will be affected by more errors. Quick problem detection and drill down into the actual cause of those issues is therefore absolutely required to eliminate those hotspots. Therefore, consider a shift right and continue your QA and monitoring activities at production. Application performance and user experience monitoring platforms are a good starting point because they allow you to capture all transactions, identify problem spots and give your developers insights what was causing certain issues.
You can’t test hundreds of test cases manually within the short DevOps sprints. Even if there are plenty of resources, they won’t be able to run performance or static code reviews with the same precision as a machine could do this job. Forget manual repetition of the same actions and automate your functional, performance and security tests early in your development lifecycle. This will give you more time for complex test cases and increases the test coverage at the same time.
3. Breakup the walls
It’s time to forget the organizational walls and enhance cooperation across units because you won’t have enough time to investigate all issues by yourself. Let developers support error analysis at production and share collected metrics with those specialists. They are familiar with the new features since day one which will reduce the mean time to repair significantly. The same principle applies for a participation of Ops teams during Dev and QA. If those specialists get in touch with the new solution from day one they learn the internals of this new applications and are much faster when it comes to error analysis.
There is no doubt, DevOps is no cake walk, but if you improve cooperation, forward-thinking and automation you will make a good step towards fast release sprint with less re-work.