My last last question was closed as off-topic. Yet, the only thing that on-topic page ascertains is that questions are accepted from QA engeneers and must not be "too localized" and I do not understand how ensuring reliability (by injecting the code to check the success of operations and retrying the failures) does not assure quality? Was my question closed because it is too localized or because I am not a test engeneer or making programs fault-tolerant is not a topic of SQA?


Val. Questions are always evaluated on what is in them, not who is asking. So it definitely has nothing to do with you not being a test engineer. (I'm not either, actually. I'm a developer who has been unfortunate enough to never have a testing team at any of the firms I've worked at...)

So the real question is "Is making programs fault-tolerant on topic for SQA?" and I believe the answer is no. Making programs fault-tolerant is a development issue. Identifying and reproducing the faults is an SQA issue. Once the issue has been identified, it really is development's job to determine why it doesn't work the way it should and how to fix it. If the tester is able to identify the cause, that's great, but I personally don't see that in the responsibility of the tester.

Now for many of us developers, we're also the test team. I struggle with this every day. But you have to keep your different hats ready, and know which one you're wearing and when.


There are all kinds of development practices you can follow to improve the quality of your code, including "injecting the code to check the success of operations and retrying the failures". However, SQA is more about how to test software than about how to write it.

The question we're currently discussing has four parts:

why nobody else does mention that

We didn't establish SQA to conjecture why people don't mention things.

and, secondly, which else operations are unreliable?

Too broad a question; Windows is a very large, complex system; it is unreasonable to ask for a list of Windows APIs that are unreliable.

Also, my reliability is based on assumed reliability of file.exists() function. It keeps the state of file system intact. But can it be considered reliable?

That is a question about a Windows API, not about testing software. I'm sure there are people on stackoverflow who could answer this.

What if it is also unreliable?

I try not to rely on APIs that are unreliable. Again, I do not think this is an appropriate question for SQA.

Val, I can see this is important to you, but you're asking your question in the wrong place.

  • By test your SW, do you mean a static test (as opposed to deciding what needs to be tested on-line)? which else operations are unreliable? is broad but it is not a wrong place and my Q has a primary focus on file create/remove ops and closing it because of this bonus seems very unjustified. Wikipedia says that robustness is a topic of SW quality. Quality Assurance topics deal with tolerance. Where is the right place for assuring reliability? You should see that my Q important not for me but all people who dislike their programs failing.
    – Val
    Dec 3 '13 at 8:58

Val - Here are a few comments:

  • Without getting into a terminology war, it is important to keep focused on the two primary functions of testers: 1) Identify risk in a product and 2) communicate that risk to the team as early as possible. You can set up a test and call it anything you like, as long as the team (including any stakeholders) are on the same page so that communication of risks to the team is not impacted.

  • Assessing fault tolerance (fault injection) is a function that may involve running tests, working with the team to cooperatively run tests, or helping the developers to structure unit tests.

  • "Reliability" is one of the "ilities" that a tester may evaluate. That is different from fault injection, which is a variation of functional testing. Reliability testing can involve (for example) fail-over testing for databases which tests the effect of sudden system shut-downs on data integrity.

  • "Robustness" can have many definitions, such as the team's ability to quickly modify the code without breaking other sections (ie, maintainability). That definitely sounds like a development issue and not a test environment issue.

  • Retrying failures sounds like a check for defect reproduction repeatability, which is necessary for insuring the quality of defect reports and not the application itself.

You must log in to answer this question.

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