INR 1499/- for
As we have seen, the world in just the past year and a half has changed a lot, especially the workplace itself (if there even is an actual physical workplace for many Quality Assurance people these days) and our ways of working. Decreased Client budgets have made it necessary for Quality Assurance, in some cases if it wishes to even exist in the company, to develop a new, faster and more productive way of testing the system under test. DevOps and Continuous Testing can fill this need and provide the fast and accurate way of working to have an important place in Software Development as it exists today. This approach makes it necessary for QA people to add and also work towards expertise in programming languages: to not only survive but to thrive in this new QA world, we have to become skilled coders as well as continuing our testing skill sets.
Although DevOps can be a very malleable term, a simple working definition of DevOps is, “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality”. Being a set of practices that combines software development and IT operations, a main facet of DevOps is Continuous Integration, where Developers push code into repositories with greater frequency than in the recent past. To both validate and verify this frequent addition of code, suites of automated tests must be developed. The goal of this presentation is to show how Continuous Testing can keep pace with Continuous Integration to assure the system defined in business requirements is being developed and all features function as expected.
Languages and Ways To Implement Continuous Testing The first step in the implementation of Continuous Testing is to decide the framework and which language to use. This will depend on the language used in Development: Cucumber can be a good choice if the language is Java, Behat if using PHP, or whatever language the Quality Assurance person feels comfortable in using. My belief is that tests should match the ambient language of the company and what the Developers are using. The initial tests run after the build should be a short but detailed Smoke test set whose purpose is to verify that the system is up and running and additional testing can be done. If the Smoke test fails, then there is a major problem with the build and testing cannot continue. Detailed Functional tests for the present sprint’s features are run after successful completion of the Smoke test set. After issues are found and fixed in the Functional test phase, then a comprehensive Regression set is run to verify continued system stability.