From the CEO's Desk: TestOps at the Speed of DevOps
DevOps has been a much talked about trend in recent years. Obviously, I am advocating DevOps along with most of the software professionals who are now reaping the benefits of the collaboration between the Dev and Ops teams, which is helping them release software faster than ever before. With DevOps, now that we have reduced the time taken for software delivery from a few weeks to a few hours, we also need our testing and QA teams to gear up to ensure that the delivered software is what everyone expects it to be.
Is DevOps killing Testing and QA or making them more important than ever?
“Automation and DevOps are going to kill the testing and QA teams” - I believe I heard this even before I heard about DevOps and automation. Both these terms are taking the IT world by storm and are fulfilling the basic objective that every business aims for, i.e., faster delivery and higher quality. Agile development, continuous integration, and automated delivery processes are taking care of faster delivery, but I think we can still argue about the speed at which we need to deliver the quality part. This is where QA and testing teams need to step up their game. Testing teams and architects can show the Dev and Ops teams why they need to go hand in hand with test teams and how important test designs, test case development, and test automation can be.
In fact, DevOps can bring out the best in testing teams and make them a vital part of the mainstream development process. Even though the QA team always has been a separate entity from a development team because they have different roles and jobs to do in a typical development process, the Operations team always looks at them as a single team with the traditional aim of delivering a product. So what DevOps does is show the Ops team and the overall organization why it is important to have a test team on par with the Dev team. QA teams, with the introduction of DevOps now, have more purpose than just finding and reporting the bugs. They can verify the expected performance of the product, initiate deploys, and instruct the Dev team to rework if there is any issue. In addition, they have automation to match the speed of the Dev team, improve predictions and repetitions, and deliver quality software by combining with the DevOps team.
Automation, Agile, and Continuous Testing
Testing at much earlier stages, and in every stage, can improve the quality of the delivered software, i.e., move the testing leftwards in a typical development process. We need to automate the testing part to match the increased development speed because of agile development and DevOps. But to guarantee that the matched testing speed delivers the desired output, we need more than automation. This involves proper utilization of tooling and cultural adoptions, i.e., continuous testing. In Opcito’s recent whitepaper Continuous Testing in DevOps, Colwin suggested a simple cultural change in testing- “Test early, Test often”- the exact way testing should be.
Continuous testing is executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release. This means involving testing at all the possible stages of SDLC, assessing risks, and recording the feedback in the software. This will help improve the outputs, reduce costs and time, and increase productivity. There is a possibility of getting confused between automation in testing, continuous testing, and agile testing. I have already stated continuous testing as an upgrade to automation in testing. Agile means testers test each increment of coding as soon as it is finished. So agile talks about the testing teams’ ability to cope with the speed of the development team; on the other hand, continuous testing advocates the continuous ability to test the code, which means adding test teams with Dev teams just like we add Ops teams and Dev teams in DevOps so that it becomes DevTestOps. The bottom line is to start testing even before we start developing.
Practices, Testing tools, and DevOps
A lot has been talked about changing the culture and how development and testing teams operate. What is it exactly? This involves certain practices that organizations need to adopt and use testing tools and frameworks to facilitate the cultural shift. For starters, group testers with developers and reduce the extensive test plans to test strategy at respective teams and sprint cycles. We should not undermine non-functional testing like performance and security testing. Automation of non-functional and regression tests can be a good practice. Consider API test automation for back-end components and run automated tests through CI server. We can do the UI validations, look and feel checking, and link verification through tools like Selenium. If we talk about tools, there are a number of them that we can use at different stages in a typical TestOps flow.
We can use the following:
- JUnit for unit testing and regression testing
- JMeter - an open-source tool to load test functional behavior and performance measures
- Selenium for test automation
- Appium for cross-platform testing
- Robot Framework - an operating system and application-independent automation framework for acceptance testing and acceptance test-driven development (ATDD)
- VCR for automatic recording and replay HTTP interactions with minimal code
- Jira TestNG for structuring and monitoring the progress
- Cucumber for automated acceptance tests written in a behavior-driven development (BDD) style
- PyTest for writing tests with almost zero overhead for creating unit tests.
A single-line command can automate the entire testing process if we consider continuous integration software like Jenkins. DevOps is our answer to the increased need and speed of software development. TestOps, with best practices and optimum utilization of available tools, can answer the increased demand for quality. Contact Opcito to ramp up your TestOps along with DevOps.
