Cost calculation for legacy in-house test automation platforms is seldom a simple task; costs for in-house test automation are embedded in s/w and h/w development budgets. if itemized at all, testing costs fall into product and QA/QC budgets But the cost of developing and maintaining a test platform is almost never itemized because it’s not part of the product specification.
Keysight has always been at the forefront of the education industry, advancing teaching and learning with innovative solutions. Building on OpenTAP, Keysight enables engineering educators who transform engineering students into industry-ready engineers.
This fourth blog in our series on Total Cost of Owner examines costs for Support and Maintenance, Downtime, Compliance and End of Life.
Supporting open source project code offers greater freedom of choice and reduced lock-in to a single vendor. In many cases, the organization responsible for launching, distributing and/or maintaining the project code also offers commercial-quality distributions and professional support.
In our series about factors that influence Total Cost of Ownership (TCO) for open source test automation, we are investigating how those costs differ from proprietary software, including in-house and commercial platforms. This third blog examines paths from legacy, including proofs-of-concept, training, integration and operationalization.
This second blog in our series examines the factors that influence Total Cost of Ownership (TCO) for test automation. The blog focuses on how those costs differ from proprietary software, whether sourced commercially, created in-house, or built from open source. In this blog, we look at Acquisition Costs, in particular, the eternal Make vs. Buy decision facing IT and engineering management.
OpenTAP makes customization easy by offering a plugin-based architecture. The OpenTAP project includes a range of ready-to-use plugins to support instruments, DUTs, user interfaces, results listeners and more. Plugins also originate from OpenTAP ecosystem participants - hardware manufacturers, software suppliers and end-users. If you have developed an OpenTAP plugin and are eager to share it with other ecosystem participants, read this blog to understand how to host your plugin in the OpenTAP project repository.
This first in a series of blogs explores methods of cost determination for acquiring and operationalizing open source software in general and for test automation in particular. Included are discussion and analysis of key phases of the IT asset life cycle, available cost analysis tools, and example cost analyses.
The Total Cost of Ownership (TCO) for an asset is defined as the Acquisition cost plus the cost of Operation. For software, Acquisition can involve licensing, subscription, and/or development . . .
Open source projects like OpenTAP start out as mostly technical efforts. Developers create code to solve a technical problem or to implement a product or service and later find it might be useful to other devs and end-users facing similar challenges. In open source terms, software built to "scratch an itch" is soon helping a whole community to scratch theirs. This blog explores the makeup of the OpenTAP ecosystem and offers resources for its diverse members.
Open Source Software is a big place, a very broad domain that addresses the technologies that support and drive almost every field of human endeavor. And 2022 was a busy year for open source, with over 150M participants contributing to tens of millions of projects.
This blog calls out the highlights of 2022 – key statistics, notable investments and important progress – ongoing challenges in security and IP – and how they impact the business and operation of test automation.
Many testing organizations become frustrated with the limitations of a legacy test platform. They are also burdened by the overhead of keeping up with aggressive product lifecycles. But changing test platforms can be too daunting, leaving legacy solutions in place years beyond their useful lifetimes. This blog addresses the challenges of migration to a new test automation platform and lays out the first step on a path for successful migration, a Proof of Concept (PoC).
The concept of Shifting Left has come into vogue to describe moving a process or process stage to occur earlier in a left-to-right timeline. Shifting Left applies to various types of testing, especially tests aimed at improving usability and cybersecurity.
This blog reviews the implications for Shifting Left across various software development models, and highlights the benefit of combining a leftward shift with test automation.
Recently, KeySight field engineers met with a company that produces mobile-wireless infrastructure equipment. The testing team there had been using a legacy in-house platform for several years, but with each new device, the testing framework required unwieldy customization. They could not keep up with agile software life-cycles.
Testing had become the main bottleneck in their product life-cycles.
