How Do You Solve RoadTest "RoadBlock" ?

I like this term Fortunately I'm quite used to write articles at work (though its usual specifications and documentation), although I still sometimes struggle with the language.

As kas.lewis wrote, the review starts with the application (or even when writing it). There you define what you want to do, which is the basis for your review. You start collecting documentation and create ideas. For each of the road tests I apply I start with a folder where I collect these documents,

When I get selected as tester, and receive the item, I create a text file where I write down my first impressions and anything I notice. When I further work with it, this file grows with even more notes. Test results (when I do lab tests and measurements) go into separate spreadsheets, but anything I notice also goes to the file.

When I start with writing the review itself, I can go back to my notes and sort them into a meaningful order. Most times I start with writing a rough outline of the review (just the headlines) and sort the notes into the chapters. That's the state my 'RasperryPi DIN rail enclosure" review is in currently. From there its just changing the notes into complete sentences Sometimes I have evenings where I don't want to write, or just struggle for words - then I just postpone it to the next day. It helps when you don't start the review late but have some days left.

It happens quite often that you come up with a project idea to test a product, and then find out it won't be possible (maybe because you missed something during preparation, or something else gets higher priority). In such cases I try to do at least do a thorough review of the product, and describe how it would be used (even though I did not really do a complete project). Try to be helpful and think of other potential users - what might be interesting to them? Is there anything you want to give as feedback to the manufacturer?

I like this term Fortunately I'm quite used to write articles at work (though its usual specifications and documentation), although I still sometimes struggle with the language.

As kas.lewis wrote, the review starts with the application (or even when writing it). There you define what you want to do, which is the basis for your review. You start collecting documentation and create ideas. For each of the road tests I apply I start with a folder where I collect these documents,

When I get selected as tester, and receive the item, I create a text file where I write down my first impressions and anything I notice. When I further work with it, this file grows with even more notes. Test results (when I do lab tests and measurements) go into separate spreadsheets, but anything I notice also goes to the file.

When I start with writing the review itself, I can go back to my notes and sort them into a meaningful order. Most times I start with writing a rough outline of the review (just the headlines) and sort the notes into the chapters. That's the state my 'RasperryPi DIN rail enclosure" review is in currently. From there its just changing the notes into complete sentences Sometimes I have evenings where I don't want to write, or just struggle for words - then I just postpone it to the next day. It helps when you don't start the review late but have some days left.

It happens quite often that you come up with a project idea to test a product, and then find out it won't be possible (maybe because you missed something during preparation, or something else gets higher priority). In such cases I try to do at least do a thorough review of the product, and describe how it would be used (even though I did not really do a complete project). Try to be helpful and think of other potential users - what might be interesting to them? Is there anything you want to give as feedback to the manufacturer?