This article was originally published on DevOps.com
It wasn’t long ago that the Dev and test teams would work late hours, focused and rushed to meet a deadline: rapid fixing, reprioritizing and deferring bugs to close out the bug list, move everything to the staging server, do one last run of the regression and pass it over to Ops/IT to move to production. What happened after? No one knew. For most Dev and test team members, Ops is a black box. More often than not, they are oblivious to what happens at Ops, the roles, responsibilities and timelines. One day—long after the drop-dead deadline for Dev and test teams—after delays, questions and changes, the product went live. Continue reading
For enterprise test management professionals everywhere, automation testing has been an absolute boon to operations. By eliminating redundant oversight and testing efforts, automation ensures that code is adequately going through the test management system with as little manual effort as possible. A code once, test many times mentality helps to better guarantee software’s final quality in a fraction of the time.
Continuous testing (CT) is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. CT is an integral part of continuous delivery (CD) and DevOps practices.
Action Based Testing (ABT) is based on the importance of test design to drive automation success. It uses uses a modular keyword-driven approach, which means that tests are organized in “test modules” and built of sequences of “actions”—each consisting of an action name (keyword) and zero or more arguments. In our TestArchitect tool we define these in a spreadsheet-like format that is easy to work with. Test modules can contain multiple test cases that need to fit into the scope of that particular module. The test cases can form a narrative in which each test case can set up the preconditions for the next one.