Almost every product we buy or use today goes through some form of extensive testing before it’s released on the market; typically, these tests are designed to replicate the worst-case scenarios that a product may encounter under real-world conditions.
Automobiles, for example, go through extensive hot and cold weather testing in remote locations, and are driven over obstacle-laden tracks designed to push the limits of their durability. Even seemingly mundane objects such as children’s toys are exposed to abusive simulations to ensure that they don’t harbor any potentially hidden and harmful effects.
On the current landscape, applications are the face of your business, often serving as the battleground where consumer loyalty is won or lost. Given this reality, it seems crazy to think that any applications are released having only been exposed to a minimum of tests. Yet, in the name of getting to market quickly, that’s far too often the case.
As disciplines including agile and continuous delivery continue to increase the speed at which development teams can release software, it’s easy to put the crunch on testing in the rush to get an update released. But that’s a costly mistake in the long run, as research has shown that it is 50 percent less expensive to find an error in testing than to address the same error once it has reached production, and more than 90 percent cheaper when addressed in the development/coding phase.
Given the dramatic cost savings of addressing errors in development, clearly the goal of any organization focused on continuous delivery should be to shift testing left so a greater number of defects are found early in the development process. This is what we refer to as continuous testing, and it’s a huge part of the reason why I am so excited about CA’s acquisition of BlazeMeter.
Performance load testing should be a core element of any continuous testing strategy because it is a critical factor in determining system reliability. Similar to the worst-case scenario testing that consumer products undergo, performance testing can quickly uncover applications defects that might otherwise go unnoticed. After all, the manner in which a system operates with a few hundred concurrent users may be very different than how it runs with thousands of users.
BlazeMeter enables today’s development, operations and DevOps teams to conduct this critical performance testing earlier in the development process, saving countless hours and resources. The company is also competing—and winning—in a highly competitive marketplace where it has been pitted against much larger, more entrenched competitors.
Part of the reason BlazeMeter is winning is its focus on offering a SaaS-based solution that is highly cost-effective and easy to engage. Using this model, customers can try out the testing software with a few clicks, and then quickly move forward to broadly adopt the system. Another catalyst to its success: BlazeMeter was built using open source tools, such as Apache JMeter, used widely in the development community for performance and load testing. As a result, BlazeMeter can easily run and analyze JMeter and other open source-based load tests—such as Selenium, Gatling and Locust—within a commercial-grade performance testing system.
This combination of a SaaS delivery model and incorporation of open-source tools, augmenting strong performance testing functionality, make BlazeMeter very complementary to CA’s existing continuous delivery solutions, including its CA Service Virtualization, CA Test Data Manager, CA Agile Requirements Designer and CA Release Automation products.
At CA, we’re committed to providing the most comprehensive, integrated and open continuous delivery ecosystem, allowing our customers to release swiftly, test agilely and constantly increase reliably. The addition of BlazeMeter will further enable customers test continuously, thereby increasing agility and the overall quality of their software, to ensure that applications don’t break down on the side of the virtual road.



In reality land, The Line was a patchwork of open-source frameworks, glue code, xml files and a few engineers unlucky enough to be tagged with role of “Build Master.” Woven together by the Build Master, these transformative robots and would take coders’ output, compile it into a workable build that merges all of the developed functionality, run and validate test harnesses against it. Once validated, the newly minted build then would be promoted to the higher-level environment, ultimately moving from dev to test, test to stage and, lastly, from stage to prod.
We have begun to see promising beginnings of The Cube pop up within medium and large enterprises through popularizing algorithms and outfitting teams with ubiquitous mission control-style dashboards and screens in team areas. But it is only when these dashboards can integrate and harmonize wide varieties of development, operational and business KPI data that we will be able to claim that we have delivered full and timely context (i.e., “the Right Information”) to the staff sailing the enterprise ship.
QA NJ
ugust Meetup on Test Automation Tools and Processes with
orking over pizza, wine and beer, I kicked off with an overview of my takeaways from Quest and StarEast QA Conferences. I gave a brief summary of the session that I presented at the conference titled “The Road to DevOps” followed by highlights from the most memorable sessions on Test Automation, Metrics and Mobile Testing. I focused on the importance of identifying and addressing the bottlenecks in the product delivery cycle which include manual processes such as test data management, environment configuration and test
execution.
Polina and Kamlesh also spent some time describing VCR, an alternative way of mocking APIs. VCR allows to run the tests against prerecorded response, but still faces challenges if cassette files become stale due to backend service changes. The session was followed by intense Q &A covering Code Coverage tools, PACT and minimizing cycle time.
very important f

First, let’s consider the survey, conducted by 
Hans Ashlock joined 

