How Do You Solve RoadTest "RoadBlock" ?

When your road test is "I want to verify the product specs and it claims", then you just need to look at the specifications and marketing material, verify and test it, write it down and you are done. If the road test is for a more complex item (lets say an oscilloscope) its not as simple anymore. Then its more like exploratory testing and evaluation, and the writing gets more difficult. And when you want to do a real project for the test to see how its to be used in reality, the number of problems you might encounter is endless...

Roadtesting a new product that has just/ will soon hit the shelves is an exciting prospect from any perspective. Personally, I feel that a huge part of the appeal lies in the autonomy that it grants the reviewer to select any application using the aforementioned product. An occupational hazard of being granted such autonomy is a natural tendency to push the envelope. In my opinion, it's pretty natural to be subconsciously overwhelmed by the plethora of opportunities offered by, say a new development board and overshoot the limits of your experience trying to write a slam dunk of a proposal.

Unboxing and preliminary tests are smooth sailing if the product is well documented online and resources are abundant. However, the real challenge comes when you inevitably stumble upon a point you considered negligible while writing the proposal, and yet turns into a headache once you begin trying. I've been here numerous times, and in retrospect, these are opportunities where you can grow, not just as an electronics engineer, but also as a more well rounded individual.

In my experience, the most important requirement to succeed in such situations is the drive to do what needs to be done, irrespective of its position with respect to one's comfort zone. One can bypass that step or replace it with an inferior alternative, or learn the required skills to make it happen. Leaving this thread loose makes for a half-baked project, and even more importantly, limits ones ability to grow if this habit becomes well formed. On the other hand, perseverance and commitment to your idea results in a much more professionally analyzed product and well written review, a confidence boost, and you learn a new skill or two.

I have been working in the domain of embedded systems and SoCs, so,when designing a system for a Roadtest, I generally;

1. Draw a rough flow chart of how my system will work. This allows me to split the entire project into chunks which can be handled individually. This reduces the overwhelming feeling of a vast project and also gives me a good idea of my starting point, work flow and testing points.
2. Draw the topology of my system. Knowing which node does what function helps me visualize the end result and work towards it accordingly. Breaking down the functions of every node into small, intuitively understandable tasks is a huge plus while programming.
3. Decide the information flow and code flow. I have almost exclusively worked on embedded systems and IoT based Roadtests, so naturally, a large part of these applications has been data acquisition, manipulation and information extraction. The topology of the system helps me decide what information will go to which node, how it will go there and when it will go. Once this is done, coding becomes a breeze.
4. One-step-at-a-time Testing : I develop my code incrementally. Going chunk by chunk on the flowchart, it really is like building a virtual Lego structure. At every chunk, I deploy, test and finalize the code.
5. Formalize documentation method. This is something I hope to incorporate in my current and future projects, because, apart from being a good review, it also provides a reliable repository of your work that you can refer to, thus eliminating the need for reinventing the wheel.

When I come to a point where I feel I'm blocked or I can't move any further,I try this.

1. Develop an idea which may get me out of that situation. Let's take an example here. I want to design a BLE communication system, and the most intuitive package I know is not in Python, my programming language of choice,but Node.js. which I do not know. So I can either learn the less user friendly package in a known language or the more user friendly package in a lesser known language.
2. Analyze the pros and cons of each idea with respect to your requirements. At the time, I had two months to write the review, so I had to choose the package which gave me the maximum throughput for the least time invested in learning it. The Python package gave me more flexibility on the core BLE layers such as the GATT profiles, while the Node.js package took care of that within the package. Also, the Python package was not as widely used. Because my requirement was only transmitting data from the device, I decided to go for the Node.js package.
3. Learn the skill. Being an amateur in object oriented programming, I decided to learn only what I needed to know. How to code and deploy a BLE client and server. In the process, I learned more about object oriented programming and server side scripting than I would have otherwise.
4. Take care of loose ends. Now obviously, because of my impromptu change in plan, it would have some effect on the topology and flow of the project as well. All my other code was in Python, while only this part was in Node.js. So I simply initialized a MySQL database on the device and stored the data to be sent via BLE there through a Python connector. Doing the same thing in Node.js, I was able to bridge the two scripts.
5. Test and deploy. Now that I had all the skills at my disposal, I could solve the problem rather than circumvent it, which resulted in a much more elegant and efficient system.

These are just a few things that worked for me. Perhaps many will have a different approach to problem solving, but the common thread that binds us will still be the urge to solve a problem rather than avoid it.

Excellent points. Realizing that perseverance and facing the challenge will benefit you much more than avoiding the challenge ... is crucial.