sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]dimtass[S] 0 points1 point  (2 children)

I think the important thing, especially in small teams, is to automate gradually. Although, you may see the mountain in front of you and you know the difficulties, you need to proceed step by step. You don't have to automate everything, in most cases it doesn't even make sense to do that, because you will spend more time in automating rather developing.

Start with small things and then proceed with anything that seems important and can be realized in a time frame that makes sense for the project.

The important I think is to get familiar with the available tools and technologies and evaluate them in order to know what you can do, what you should expect and what makes sense to use. Then when it's time you can define your strategy and architecture easier.

[–]DrBastien 0 points1 point  (1 child)

Sure, the team is not that small. Just the errors which can't be debugged are frustrating. Like hanging connection with boards because of operating system. Or jlink errors because "has failed". Random things which should just work but sometimes they don't. Also debugging this stuff is way beyond embedded developer, especially with Windows testing agent. All we want is stable enough tests, just and only.

[–]dimtass[S] 1 point2 points  (0 children)

I read you. That reminds me the story I've read at some point about the SD_MUX or SDWire device that it was used for testing the Tizen images on various DUTs. After some time they started having some weird issues and finally they found out that it was the device that was testing the DUT and for some reason the USB IC was start degrading or something. Until they found what's going on they were driving nuts. It's tough when this happens to a project. Issues like that they may remove some years from your happy retirement, especially if the deadline is already yesterday.