Category: Uncategorized

One of my favourite quotes is “We have met the enemy and he is us‘. It originated from the Pogo comic strip and has lasted throughout the years. It seems to ring so true for many Quality Control initiatives. It is not as if we start out to be our own enemies but frequently we seem to end up in that position.

A short story might illustrate one of the most common problems. We had a client to whom we supplied some training. As a prelude to the training, we tried to get some idea of what was currently viewed as the major problem or problems in the organisation. The common concern was “Too much testing”. The obvious rejoinder to that was Why and the answer we received was that there was Zero tolerance for defects in production. Knowing that zero defects is pretty difficult to achieve although someone did claim recently in a LinkedIn group that it could be done, the question was how they felt that testing endlessly was going to help achieve the desired result of no defects in production. A little more digging and a few more questions and we had an answer. People felt that if they tested all the hours they could, whether or not it was effective use of their time, then they could not be faulted if (when), the inevitable problem showed up in production. In other words, we have exhausted ourselves testing everything in sight so anything left could not possibly have been found in the time before promotion or launch.
This is where Quality Assurance differs from Quality Control. Quality Assurance would be asking the following:

• What benefit is being gained from the testing?
• Is this an effective use of the time?
• Is there a better way of doing this?
• Does this effort actually have a positive ROI?

Testing faster or longer does not always provide what you want. Give us a call to see what is the most effective process to use.

‘Those who do not learn from history are doomed to repeat it’. According to Wikipedia this quote can be attributed to George Santayana. These quotes (we will have another one in the next blog) are always apt and apply to many different occasions. The one quoted here could be used so often in Software and Quality Assurance in particular that it seems to be redundant to say it.
If you have said (or heard) or wished to say any of the following you have paraphrased the blog title:

• We did this right last time
• Someone has the information somewhere
• I have forgotten what we did
• The person who just quit/retired/left knew it but no one thought to ask
• I remember solving this earlier
• An ‘unknown’ known.

The list could go on and you are invited to add your own as a comment.
We do not spend our time knowing our own history with the following excuses:

• We don’t have time
• We don’t have budget
• It is faster if we redo it over (and over and over and over…)

Meanwhile the solutions recede further into the background. We have had clients who (deliberately) lost every defect they ever created. They threw them out every year! It was more ‘fun’ to recreate the same solution each year than simply look up the older solution, resolve the issue, and move onto to new and more challenging issues. It was certainly easier – there was a half-remembered solution that could be used as if it was a new solution and then there was no time to provide a really innovative idea to move the organisation forward. This is okay of you have a monopoly and a captive market. Not so great if you are in a competitive market where your customers have choices.

Quality Assurance puts in processes to ensure that the existing items are remembered and reused and the creative efforts are expended on truly new items thus creating new business.

It might be better to say “Why Quality Assurance” rather than the title as listed but we had a reason for putting it in this order. Most people can usually answer the question of Why Quality Assurance even if there is some difficulty in articulating the actual reasons. However, Quality Assurance – Why? turns the question upside down and leaves it open for the answer to the philosophy exam question of “Why” which after a few hours of thought is answered with “Why Not”. So we could rephrase this as Quality Assurance – Why Not? and see if we get any farther.

There are four major reasons for embracing Quality Assurance and innumerable lower level reasons. In talking with a number of clients, they often advance the reasons we are going to discuss here as the reason for avoiding Quality Assurance

A crisis that costs money and could have been avoided

Few people see the need for Quality Assurance before the crisis occurs: “We have never had any problems and do not see the need for Quality Assurance.” Of course once the crisis occurs it is far too late to recover everything (including reputation) and the organisation is left scrambling for damage control. Any perusal of the latest news will tell you the companies that avoided adopting Quality Assurance until too late.

Government or Industry Regulations that require independent Quality Assurance

This is the “the unknowing driving the unwilling”. If one waits until the industry is forced to regulate or subject to government fiat then one is on the receiving end of whatever is decided. It is much better to adopt the leadership position and be the one setting the regulations in accordance with what we are already doing rather than accepting what others decree.

A demand from a critical customer for proof of Quality Assurance Activities

If a client or customer is demanding proof of Quality Assurance activities in your organisation, then it is already too late. Obviously there is dissatisfaction and there may already be a contemplated move to the competitor. Better to be ahead of the customer and telling them we have Quality Assurance in place already and are well ahead of the competition.

A realisation that Quality Assurance pays for itself in less rework and churn

This is the positive reason that appeals to the bottom line. Quality Assurance is a money saving exercise.

Over the last couple of weeks, there have been a lot of references to the meeting at the UN in New York addressing Climate Change.  Has Quality Assurance anything to add to this or is it something that is peripheral to our work?  Quality Assurance is Green.  It can be argued that anything that reduces rework or ensures that something is right in the first place reduces energy consumption and thus reduces the climate change.

With reference to some of the earlier posts we have put up, Quality Assurance cuts the failure rate and reduces the length of the process used to generate a product or provide a service.  This cuts the amount of energy use – see Energy Use in Data Centres.

There is a number of ways in which Quality Assurance can help:

• Reduce the amount of storage required thus reducing disk space; the number of disks and the amount of cooling.
• Reduce the length of any process reduces CPU utilisation and thus the number or power of the CPUs and the amount of cooling.
• Remove or rationalise any redundant processes with the same impact as above.

In general, anything that is simpler yet still correct will lessen the impact on the power used and the climate change.

So far we have concentrated on the power aspects of running systems and servers to support the industry.  However, Quality Assurance can also help in checking other parts of the process unrelated to software to be more efficient.  This may reduce the need for resources or allow reuse in some way that will again reduce the carbon footprint or that of other uses that impact climate change.

One of the most common misconceptions is that Quality Assurance is Unmoving or at least Perceived as Unmoving.  Many people believe that once Quality Assurance  has set out a process it cannot be changed (ever).  This came about from the approval process inherent in some companies. By the time a process or standard (for example) had been

• Identified as needed.
• Created.
• Made the rounds for approvals.
• Gone up the ladder for approval (and back down) several times.
• Been enshrined in the documentation.
• Shipped out to all the divisions.
  and
• Finally used.

there was little incentive to start on a new process or modify the existing one that had finally come into existence and was still working its way through the company.

However, nothing could be further from what was intended. Quality Assurance  advocates continuous improvement and nothing is static if it can be improved. Furthermore a review and revision process is automatically built in for all processes (including the process for building processes!). It is assumed that improvement is always possible and refinement through several versions is expected, particularly for widely used standards or processes.

The problems arose as a result of the approval and promulgation process that was mandated after Quality Assurance had done its work. The improvement had already been identified and was accepted. However, the process to get it out, accepted and used was long and arduous. Most of the dissemination process has been fixed recently with the use of various communication methods  but Quality Assurance is still labouring under the misconception that it is static.

In some ways, Quality Assurance  anticipated many of the iterative methodologies that are now so popular.  There is always room for improvement and the feedback loop runs continually.  Nothing is ever really final until it is shipped and even then we can continue to make improvements for next time.

A colleague pointed out recently that we are back in System Maintenance mode; a lot of systems are being patched and upgraded instead of being replaced. Not everyone is in this mode; there is still a replacement and upgrade occurring but others are hoping that their existing systems along with a little tender loving system maintenance will last them awhile longer.

Some of this reluctance to invest is driven by budget concerns; there is a general unwillingness to spend substantial funds if the business direction is not clear or certain. There is no point in embarking on a large expenditure if there may be a large change in the business need.

Some of this reluctance is driven by an uncertainty of what technology can or will provide in the near future. Systems that were built a few years ago may be outdated but with a little judicious tweaking they will accommodate connections to the new technology and allow the organisation to get partial benefit while still utlising their existing investment in technology.

A substantial amount of this is driven by a lack of knowledge of the existing systems; how they work and what they actually do. It is very hard to embark on a major system replacement when no one knows how the existing systems work and what they do. There is a fear of losing functionality on which the company depends for basic business activity.

And lastly, there is strong component of corporate memory which recalls how badly it went last time a mass IT upgrade was attempted. Nothing stops a new initiative faster than someone saying “The last time we tried this, it went x% over budget, y% over schedule and we ended up with less than we had before.”

Quality Assurance can alleviate all these problems. QA is not just testing; it is process improvement, rationalisation, and organisation.

QA techniques can save on the budget and ensure that it is monitored and controlled.
QA can determine how the design fits with future trend and add the proper consideration of emerging trends at the correct points in the SDLC.
QA can provide techniques for determining the activity of existing systems.
QA can utilise past experiences to improve future outcomes.

Last week we talked about the common comment ‘always having time to do it over but never having the time to do it right in the first place’. Doing it Right has that famous answer: “If there are n people at a meeting, then there are n opinions on what is the right way and the n+1 st is the correct one”.

To some people doing it right means following the process. This makes the prior assumption that the process is right and provides the correct result. If you are reasonably sure that the process is stable and generates at least close to what is needed as an end result then you might get something that is reasonable at the end. It would be necessary to ensure those two items but it is a start. If the process is wrong, then no amount of work will get you the correct result. If the process is unstable then you may get something useful or you may get something completely wrong (and not know it).

To other people doing it right means doing it their way or no way. If you are absolutely sure that your way is the right way, then that may also suffice. However, if you are in the least bit unsure then the end result may bear no resemblance to the initial requirements.

Some believe that doing it right means supplying the customer with what they want no matter the effort or the convolutions in the process along the way.

Quality Assurance takes all of these into consideration and melds them together to ensure we are doing it right. A QA Assessment reviews the entire process with the following considerations as initial guidance:

1. Is the customer on track to get what they want?
2. Does the process support that end result at present?
3. Are there parts of the process which are not supporting the end requirements?
4. Are there parts of the process which are not being done even though they would support the end requirement?
5. Are there efficiencies that could be realised by process improvement?

NVP Software Solutions specialises in QA Assessments. Give us a call.