Hardware

Ask something
Discussion Locked

selftest of program integrity

0 helpful
5 replies

by peter r

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

In case of anti-malware programs, as a precaution against attacks to cripple their functionality, a kind of selftest is mentioned.
I think that in case of other types of complex software, e.g. video-editing, such kind os program integrity might be quite useful, particularly when some persistent error occurs.
At least the time-loss involved with attempts to localize and resolve the cause (e.g. disturbing process, user error, software malfunction (not necessarily a bug), other PC errors) will be significantly reduced .
Preferrably such a self-test module (to be activated by the user) should be combined with a repair facility in the software set-up to prevent evt. unnecessary re?nstall. Is such a realistic item to request to (or require from) software manufacturers ?

5 replies

by tony hopkinson

In order to accomplish a test suite, you must design the test points into the application. You can have a good go at this in a new devlopment given the resources, retro fitting such a thing is expensive and risky though.

The other problem is a lot of the issues are installation / enviromental. Windows versions, network topology, security policies, common dlls etc, versions of teh application itself, even hardware and it's drivers...

Coping with all the potential combinations is an extremely exacting, risky and expensive exercise.

by peter r

Thanks for your expert comment Tony, I now better understand the complications involved.
Suppose a more direct approach: the program has some clever designed test-file and a database of results (either simply only the final result or for each major operational step).
If there is a significant difference between computed and reference result the program could indicate such (and possibly add some advice how to act further).
Maybe this is just another stupid proposition of a non-insider, but anyhow I will appreciate your comment

by tony hopkinson

If you do testing goes from useless/impossible to potentially automatable donkey work.

Here's a simple scenario.
If you wrote an application that hit a url and displayed the web page.
How many ways are there that that could go wrong?
Starting from windows networking not set up, to not on the domain, to dead proxy, to lan down, to server not available, to bad url...., to blocked by web police, AD policy issues, firewalls, routers....

As a programmer, I wrote the app aassuming that the page would be there. It was when I 'tested' it :D.

But to you as a user.
"Page not found", which is all you'll get back from url component is merely a starting position.
To provide you with a deeper description as to why you got the 404 error requires me to write a shed load of code, then that has to be tested.

This rapidly becomes a case of diminishing returns, so quicky in fact, you as a user end up with a dialogue saying one of these many things could be wrong, usually in arcane technicalese, and or a telephone support number.

There's no doubt that as suppliers of software we can do more, but as a designer I need some numbers to show the resources should be spent. That means as consumers, quality tests have to become a value added that you'll pay for or one that will persuade you to buy one of two functionally equivalent products. Without that I cannot get past the bean counters, except for internal testing / qa where the cost savings and therefore the margin can be considerable.

They are rarely considered significant enough to justify a total rewrite though.

In the production of software in a tight environment, the first two casualties in the quest for revenue /cost reductions are documentaion and quality. This only changes in the face of competition, when all other cost cutting initiatives have been exhausted, sad but true.

So essentially you aren't getting it because not enough of 'you' are prepared to pay for it.

by peter r

Tony, thanks for response. At first I planned to tell how in early DOS era we, being non IT technicians, had to program our models in Fortran or GWBasic, testing them stepwise through multilevel subroutines for extreme cases & adding ..if ..then .. else lines at positions of supposed risk for problems, but after re-reading your message I think that a view from the other side of the coin is more relevant to your comment, notably concerning the last somewhat pessimistic sentence.
-Fairly large business firms can afford dedicated computer systems, use UNIX OS, customer-cut (near ?Fail Safe?) software and 2 or more IT-troubleshooters. If there is competition, then at least in the quality sector.
-The majority of home users and small business units have to rely on PC, current (not always reliable) OS,
some utilities in the 15-45 $ class, a few complex programs in the 80-250 $ range and freeware; together sometimes overcrowding the HD?s and MFT?s. Such may hamper the functionnality of the complex programs.
In case of small business the PC-occupation will be much more modest but the additionnal damage in case of serious malfunction may occasionally result in a perfect illustration of Murphy?s Law, unless ..
.- Home-user example: I am member of an e-mail video-editgroup. Over 40% of the mails are concerning malfunction events; a lot of which are program ?hangs? without further notification. In many cases the program docs lack a relevant troubleshoot guidance. Therefore users, short of skill to tackle such events, have to rely on either helpdesk (no warrant) or troubleshooter (sometimes both costly). The more experienced may perform 1, more or all chapters of the following trial & error theatre set -> chk dsk + fix error, HD cleaning & defragmentation, apply System restore, some perform registry-repair and ?defragmentation, install a RAM-optimizer, or attempt a run in Safe (OS) Mode (in my case with succes, thus clearly pointing to some cause).
In many cases it ends up to a more or less adequate re?nstall, complaints to the manufacturer, often follwed by a number of patches on the website. Such experiences may lead to (also publicity-induced) ?image loss? of the product or manufacturer (very costly). A similar story applies to hardware driver- and risky firmware-update.
- It seems likely that if software and documentation is improved in such a way that users are given more grip
on how to act in a logical sequence in case of ?malfunction? , they are willing to accept a cost increase of say 20-25% (enough ?). It is however also a matter of marketing strategy of the manufacturer to convince the user and , above all, the opinion-shaping media (e.g. on software tests) to include such in their performance/price opinion.

by tony hopkinson

Installation checker, environment, the software itself, the database.

It could be improved, but what couldn't?

We sell support though, every time we can 'tell' the user to plug their network cable back in, is a customer who 'solved the problem themselves', and a call we don't have to field.
We get paid whether they use the support or not, so the business case for it is overwhelming.

This discussion is closed to new replies.