Testing software that is hardware based when the hardware isnt available?
So just want to throw this out there and see if anyone has any experience or suggestions.
I am currently working at a company that creates software that heavily relies on hardware (mostly cameras, custom boards, for example, the hardware will acquire or view images and the software displays acquisitions and processes the images, think forensics) but often the hardware is not available. The reason for the lack of available hardware is first of all its expensive to manufacture, we're a smaller company and if one unit is available at all the developers or scientists get priority to it.
So my question, is there some way to test software in this scenario? Is virtualization an option or is that more for OS based or settings based testing? My goal is to test sooner and more frequently, ideally without relying on hardware too much but I am not sure if there is much I can even do in this scenario.
Thanks for any input.
The questions of whether virtualization is an options, etc... will rely more on the specifics and nitty details of your product.
I don't have experience in this area. Just throwing out some thoughts/questions in the hopes it might bring some clarity.
* First off, what kind of software? Is it running on an embedded system, an EPROM, or a downloaded App?
* How are the developers developing the software? I'm thinking they would have a pretty close emulation in their dev environment.
* Is the hardware manufactured by your company? Who makes the hardware? What part of manufacturing it is expensive? Would it be possible to put together something consisting of the same parts without building the final product? For example, using a bread board and substituting the expensive parts for an Aduino unit with logic programmed to mock the real service. For example, a fake camera module that returns a fixed image instead of a super high res CAT scan image of a medical device.
* Would there be ways some of the expensive hardware so it can be shared? I remember my dad telling me of old days when computers were so expensive people had to sign timesheets to reserve run time on a computer. Perhaps some obstacles could be navigated using a bit of creative timeshifting.
Originally Posted by dlai
* The software is usually two parts, part installed on the hardware to control the zoom, focus, etc. as well as communicate back the users computer, the other part installed containing the user interface and all of the processing layers. A lot of our products we sell and ship not only the hardware of the cameras, boards etc. but also a desktop, monitor etc. with the hardware.
* They develop it in parts and chunks, the bulk of development deals with the processing behind the scenes, reliant on algorithms produced by in house scientists. So, they can run these algorithms against files already acquired without the hardware present in some cases, or when putting the UI together they can (I just learned this today) simulate the hardware being present so when clicking record you get flashing lights instead of an error that no hardware was detected. They seem a bit reluctant to pass this along though as it doesnt seem like the best testing solution but we'll see.
* We take hardware parts from other companies and put them together into our own hardware for our own uses. The expensive parts are usually the cameras involved internally, short wave infrared cameras, specialty filters for those cameras etc. The team is very small and turn-around is pretty quick so writing mock-ups on cheaper hardware to mimic the expensive hardware may not be in the cards time and expense wise but is an option I did not consider and may be worth investigating for longer term projects where hardware is frequently getting moved around or unavailable.
* This is likely to be my solution. I brought this thread up and am exploring other possibilities just to do some research, mostly just because I am curious. But the most likely thing I see occurring is me coming in early or staying after hours to get the time I need on whatever units are available and being more strict on signing up for usage during normal hours.
Just to add a little more disclaimer, I know this is a very broad question that cant really be answered without knowing quite a lot of the specifics, just wanted to get some ideas/opinions from other QA folk on how they may have dealt with or recommendations on dealing with testing when access to hardware the software is written for is limited. Ideally just looking to spark my own ideas for my specific situation.