Bojan,
There is a lot to cover in your question.

When I start a new embedded project one of the first things I do is build the "logging framework". The software team can build the logging framework on a microcontroller evaluation board, meaning that you don't need your hardware design (PCB) to start the embedded project. You can use an eval board to start working with the "OS framework" (ie FreeRTOS, Zephyr, or exec loop) and build the logging framework. IMO the logging framework is the most important module in your project because thats how you are going to get debugging information from the "field" (when the product is in the hands of real customers). Or even when the product is being tested by internal users, you will want a way for them to "push a button" (on the mobile app, for example) and have the "logs" sent to a server, and then to triage, and then to a developer. There are several logging frameworks out there, some are part of the OS, some are separate. There are also strategies for building "lightweight" logging frameworks, for example "pigweed" open source project from Google.

Most projects have a PC connection, either via a UART, USB, or wirless (BLE or WiFi), and the just described logging framework would use that communications path to send/display logs. In addition to the logs, you should build a command line interface (CLI) to your target. This will allow you to send "commands" over the UART (for example) to interface with your target. For example, if you have an I2C device in your target, you should add commands that allow the developer to query the I2C device, read and write registers for example. I consider this CLI as part of the logging framework.

The CLI interface is NOT a menu system. Don't make a menu system because they are too restrictive. If you need a new function you don't want to have to update the menu system. Think of the linux command prompt, think of making commands that take arguments (use c's argparse library). You can make one command that can read any I2C device register, if the commands takes the I2C address and register as arguments. One command can service all devices.

Now finally, I can answer part of your question. Using the CLI interface is how you would put your device into various test states, for example, to measure current in that state. You will also need/use the CLI interface in production testing, to turn on/off devices, voltages, or to perform built in self test (BIST) functions, like accesing the WHOAMI register of I2C devices.

For Continuous Integration (CI) there are several (open source) frameworks. I have used Jenkins (https://www.jenkins.io/) in the past. Github has a framework. Many others. A "professional" software development company will have a software production build system. These systems generally can't use IDEs, then need command line (linux generally works best) build environments, like cmake or make. Develpoment that is done in IDEs generally don't translate easily/well with CI flows.

CI and production builds are also important because (presumably) that environement controls the version of trhe build chain. All build artifacts (the elf/hex file) that are used by the company should only come from one place, the automated build machine. Don't allow developers to distribute builds from the personal computer. It is only a matter of time before one developer is using a different version of gcc than another developer and you will get different outputs, different bugs, and generally waste lot of time tracking that down. Developers need their personal built tool chain, and there should be control on how they set/install that. And developers will use their own build to add features and fix bugs. But at the end of the day, they make a comit and the build system will create "official" builds for other people in the company to use/test.

CI frameworks allow you to write test scripts, usually in python, where you can do what you want. A very simple CI test would be to load the code on the target, and see if the code boots up and you can see the logging output. If that fails, then you know that last commit does boot up. And before too much time passes, one can fix that bug. But you can do so much more, as long as you have that CLI interface, you can run any number of tests, and you can run "hardware" tests, like measuring current.

Consider having a product that has the same code base but runs on several different hardware versions. The CI build machine will have all these hardware devices connected to a machine, and the build tested (automatically) on all the different hardware versions.

CI testing gets more coverage and progresses over time. Just using a CI framework is a big first step and requires some learning to get set up. But over time the CI does more and more work and adds to the quality of your product. CI helps detect SW regression. CI systems can do software unit testing as well.

Raul,
I have compared the PPK2 to the P1125. If you want, we can arrange a time to chat and I can show you the plots I took. email me at martin@sistemi.ca.
Towards the end of the presentation there is a slide where I talk about other products in this catagory and they use "FET switching" to get the dynamic range and there are two problems with FET switching, (1) is the charge injection that happens at the FET, which causes a measurement artifact, (2) they would have an algorythm (SW or circuit) that tries to track the measured current and switch the FET at the apprpirate time, but they can't know where the device current is going, and thrashing can occur, where the measured current is change between two values causing the algorythm to keep switching FETs.

The PPK2 is ~$100. For hobbyiest, or casual designers, that price point is offer decent value proposition. But because of the FET switching issues, the developer might spend a day or two chasing current that is not related to her product.