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

The thesis that "manual testing will be a cheaper and more effective method than automation" continues to appear in testing discussions, webinars, and publications. This perspective represents a widespread but oversimplified view of software quality economics. While manual testing offers lower hourly rates and immediate deployment, this perspective fails to account for the complexities of scale, the many scenarios where automation isn't merely preferable but essential, and mo

We've all seen it happen. The developers on the team excitedly discuss the latest framework they're implementing, while the test automation engineers quietly stick to the same Selenium scripts they've been maintaining for years. It's a strange disconnect – the very people who should be at the forefront of technological validation often trail behind when it comes to evolving their own toolset. Let's be honest: many of us in test automation have become too comfortable with our

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

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