The Kimputing Blog

" Our test suite passed," the developer announced. The business analyst looked at the console output - pages of cryptic assertions, stack traces, and technical jargon. "Great," she replied. "But what did it actually test?" The developer scrolled through the logs, searching for something human-readable. Nothing. This scene repeats itself everywhere. We've invested heavily in test automation, but the reports speak only to those who wrote the tests. Business analysts, project ma

CenterTest provides numerous means for effortless Guidewire application testing, such as simplified test creation, requiring only basic Java knowledge. The power of CenterTest comes from the AnkrPt Bots, which generate a test framework directly from your Guidewire InsuranceSuite code.  Why does this matter? With IntelliSense, simply typing your field’s name on the screen display all possible options. When a field is based upon a typelist, avoid typos and testing unsupported o

Guidewire projects follow an Agile methodology iteratively releasing new lines of business one after the other or adding more capabilities to already existing products. This approach creates the need for better quality and faster time to market to overtake the competition. The number of existing functional tests over time sky-rockets. This puts a huge burden on testing which becomes time-consuming, repetitive and prone to human error. How many times has testing become the bot

A transition from manual testing to automated testing is a project on its own. Hiring resources with new skillsets, introducing or developing new tools, requests for additional infrastructure and environments, is a guarantee. All this translates to a bigger upfront investment in comparison to manual testing. Without fixed expenses nor clear predictable gains at the start of a transition, calculating the ROI of such endeavor is not a simple task. Here we will point to several

Every test automation needs investment to start with. With every new test, the overall execution time increases. Why write so many new tests if you do not have time to run them? What is the point of using Data-Driven Testing to multiply those numbers even more if you are already out of time?  The most common solution is to add more manual testers, however, this means an increase in cost for testing. Is there a way to avoid that?  If you only know what you will be testing, how