With the arrival of our ‘production standard’ cameras, we’re putting a lot of work garnered over the past 3 months into action. We’ve learnt A LOT since we first shipped the beta cameras to the testers. As such, we now know how to approach things far better, more efficiently, but most of all, more effectively than last time.
This time we’re putting our testing plan into action. When the camera’s go to production we have two sets of independent testers at the ready to implement everything, however, as the next round of cameras is just short of 20 we’re highlighting what we need testing to them and doing a ‘walk-through’ with them. So let me share with you what’s going on at the moment.
The camera’s are currently being hardware tested. As stated hundreds of time, hardware is king. Firmware is easy to change, hardware is not, and as such, we’re putting the hardware through it’s paces. We’ve received 3 ‘early’ units (ahead of schedule) and as such we’re starting our process.
Each camera has been tested before hand in the factory, made sure soldering is up to scratch and everything is fine physically. The camera’s are then loaded with BASIC firmware. This firmware literally allows the camera to turn on, auto record, stop/start record, turn on and off wifi, turn on and off camera. These functions are tested and everything is written down. The camera’s are then sent to Emma.
Emma our Chinese sourcer receives the camera’s and will receive a report. The report usually will highlight a problem such as – “WiFi turn-off function for x y camera’s is not working, this is being fixed.”
This is not as big a problem as some people may think is this is firmware related and easy to fix – if the wifi could not be turned on this may be a bigger problem as this could indicate a problem with the button and the hardware/pcba but as the wifi is turned on this is probably just a conflict in code or a variable left out in the code and as such does not raise much of an issue for us.
Emma then goes through and tests every function. The first being the update function. The reason we ship the cameras with nothing on them except basic functions is we want to test the update function ourselves. For the camera’s we’ll be releasing the .elf files, but we want to make this as easy as possible for people. So we load each camera with the .bin file and see what happens. All 3 cameras passed and worked. Our LED update sequence indicated everything did and suddenly we have more features. Life’s great.
After that Emma goes through every feature making notes for each camera. Does LED on/off work? Is LED brightness acceptable? Does video time stamp work? Does the white balance screens work? Everything is gone through and detailed notes made. The problems with the app company are sent to the app company, and the problems with the firmware are sent to the firmware team. This happens with each camera. Each feature is being noted and analyzed for the indepedent testers so when it comes to them testing 100-2000 (depending on run size) they know EXACTLY what to look for. We know there will be faulty cameras, their could be loads of faulty cameras, but the mechanisms we’re putting in place should reduce that. This camera is not about making a quick buck, but rather starting to build a brand, and that is being a brand for reliability and quality. As such we’re investing in those two things.