Blog Category

This blog demonstrates how hosting the OpenTAP test automation engine itself on ARM-based systems is a relatively straightforward task. Since OpenTAP is built with .NET, it enjoys the hardware abstraction provided by the Microsoft application framework, with very few hardware-specific dependencies or idiosyncrasies. As examples, the blog shows how to target an Apple M1 host running Ubuntu Linux, an ARM64-based Raspberry Pi system, and an M1 Pro-based MacBook Pro running MacOS.

Testing and test automation usually conjure visions of software and hardware under test on a test bench in a lab or on a production line. The involvement of human actors can seem quite secondary and distant from executing test plans and running through test steps.

In practice, test engineering is a very human endeavor: humans design the systems under test, specify testing criteria, implement test code and evaluate test results. And they don't perform these tasks in isolation.

Every year for the last three Keysight has collaborated with faculty at the University of California Santa Cruz (UCSC) Baskin Engineering School to sponsor one or more senior projects in test automation. This year, that project focused on utilizing OpenTAP and OpenTAP plugins to control a collaborative industrial robot arm (cobot). The UCSC team faced a range of educational, logistical and technical challenges and met each with intelligence and aplomb.

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.

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.