A recent question was flagged because it was off topic, and the user flagging did not have the right reputation to cast a close vote. I have to agree with the flag that technically, the question is off topic. It deals with testing hardware, and this site is specifically for testing software.

Of course, this site is also armed with necessary tools to adapt itself to its needs. We can decide if we want to consider hardware testing on topic or not.

I think our name alone can answer this question. Are we

(Software Quality Assurance) and (Testing)

Or are we

Software (Quality Assurance and Testing)

3 Answers 3

(Software Quality Assurance) and (Testing)

It's not that. Testing is about more than computers. What about flu tests? Intelligence tests? Financial stress tests for banks? Compatibility tests for online dating sites? Tests in school? Cola taste tests? You could list many other examples.

A better question might be, "Is SQA just about software, or is it about anything that reasonably falls under computing, including hardware?"

I also wonder if hardware testing might overlap with https://electronics.stackexchange.com/, especially when you start talking about specialized testing equipment.

  • It's definitely off topic at electronics..... Those are only for EE questions. Anyway, what's the answer to "Is SQA just about software, or is it about anything that reasonably falls under computing, including hardware"?
    – Pacerier
    Jun 3, 2015 at 17:16
  • My opinion: SQA is just about software.
    – user246
    Jun 3, 2015 at 17:32

The problem stated in this particular question can be addressed from software testing perspective, e.g., a hardware can be treated as black-boxed function taking an input and returning an output. In this sense, I can see no difference from, let's say, testing a software deployed on mobile phones. Are we testing then: a hardware (a mobile) or a software? I think integration of both. Going further, providing clear distinction where the testing of software ends and testing of hardware starts can be hard if we start talking about testing circuits with embedded software installed or a firmware in my digital photo camera.

Therefore, I believe each such case should be discussed separately and one that flags it as off-topic should at least give a hint what kind of issues may appear in testing of such a thing that are peculiar to hardware, and thus would not be observable when testing the software in isolation or on a simulated hardware. Explaining such differences would be more informative for the software testing community than ignoring such questions at all.

This, however, would require a larger sample of hardware-related questions. For now, the number of posts tagged with hardware is very low. Maybe, we should start tagging more questions with this tag, if it seems related? For instance, some errors appearing in the application (like in this question, not tagged with hardware yet) may be either a software or hardware fault, and it would be valuable for a software tester to understand how to perform root cause analysis in such cases.


Difficult to comment on forum scope here as a bit of a newbie but :

Firstly building automated tests is a time consuming busines which benefits from experience, very careful planning, good tools, and accuracy. And of course should run at the click of a mouse. So once built one would want to utilise one's tests for the broadest scope of application.

Secondly the end user is only interested in end to end service. They don't care what combination of hardware, software, or whatever.

So I see a danger in limiting scope. I want my guys to think how they can get the greatest return from their testing efforts and I wouldn't want them to miss opportunities to kill two birds with one stone as it were.

ps: I remember a few years back doing load/performance testing for a new bespoke application. The planned application software testing was completed but when all the hardware was configured we ran our tests as an extensive soak test. We discovered, rather than the memory leaks we might have expected, failing disks. By looking at the batch numbers of disks within the farm we soon identified a batch number that was responsible for the failures. The members of the batch were replaced and the rerun soak passed with flying colours. In that case what started out as software testing delivered the greatest benefit in relation to hardware.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .