.png)
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 to release software at a much faster pace than ever before. With DevOps, now that we have reduced time taken for software delivery from few weeks to few hours, we also need our testing and QA teams to gear up for making sure that the delivered software is what everyone is expecting it to be.
Is DevOps killing Testing and QA or making it 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 which every business aims for, i.e., faster delivery and higher quality. Agile development, continuous integration, and automated delivery processes are taking care of the 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 out of testing teams and make them a vital part of 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, Operations team always looks at them as a single team with a 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 to find and report the bugs. They can verify the performance expected out of the product, initiate deploys, and instruct Dev team to rework if there is any issue. In addition, they have automation to match the speed of Dev team, improve predictions and repetitions, and deliver a 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. To match the increased development speed, because of the agile development and DevOps, we need to automate the testing part. But to guarantee that the matched testing speed is delivering the desired output we need more than automation and 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” which is the exact way testing needs to be.
Continuous testing is nothing but 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 and assessing risks and recording the feedback in the software. This will help in improving the outputs, reducing costs and time, and increasing productivity. There is a possibility to get 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 development team; on the other hand, continuous testing advocates 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
Lot has been talked about changing the culture and the way development and testing teams operate. What is it exactly? This involves certain practices which organizations need to adopt and use some testing tools and frameworks which will 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 which we can use at different stages in a typical TestOps flow.
We can use:
- 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.
If we consider continuous integration software like Jenkins, a single line command can automate the entire testing process. DevOps is our answer to the increased need and increased speed of software development and TestOps with best practices and optimum utilization of available tools can be our answer to the increased demand of quality. Contact Opcito to ramp up your TestOps along with DevOps.
Leave Comment