Blog

  • Startups and Small Companies Need QA

    There is a common view that Quality Assurance is restricted to larger companies like Banks, Utilities, and Telecommunications organisations. This view is misleading: Startups, Small Companies and Not-for-profit groups also need QA. As a matter of fact, in many ways they need it more than some of the larger companies because larger companies have the resources to recover from a problem and often have the reputation to ride out many issues that could flatten a small company.  A Startup or Small Business is often riding on limited dollars, time and staff and does not have the resources to recover from a large problem that could affect their product or their reputation.

    Quality Assurance that a smaller organisation needs does differ from that of a larger organisation. A large organisation requires Quality Assurance processes and procedures that will allow it to continue in business while minimizing the risk to their existing systems. A smaller organisation requires Quality Assurance processes and procedures that allow it to react rapidly to market requirements and grow quickly if necessary. A small organisation does not usually need extensive Quality Control or Software Testing – they know their product inside and out and and can quickly make changes as required. Startups or small businesses need Quality Assurance that ensures that any changes made fall directly in-line with the long term growth plan of the company and the product. This might involve some of the following:

    • Design considerations for the product to allow for future growth
    • Guidelines on how enhancements are going to be added to the product so that the overall product direction is not lost
    • Coding standards to ensure future flexibility of growth

    None of the above require a huge investment in time or resources (both of which are usually in short supply in a new company). They just require some consideration and the discipline to go back every few months and make sure they are effective and efficient.

     

  • Apps Need Quality Assurance Also

    Many people equate the requirement for Quality Assurance with old applications in large businesses. However Apps need Quality Assurance also, although for different reasons.

    Many of the old applications in large businesses are mission critical to the business and their profitability. Failure of those applications will have major repercussions and may drive the business into bankruptcy. The traditional argument for Quality Assurance and Quality Control hinged on that concern and there is no reason to change that attitude in that situation. As a colleague said, ‘I need to know what was done, how it was done and I need to know it was done correctly. Then I can go to my management with a recommendation that the application be released into production with assurance that it will work’ Suffice to say he works for a bank and a failure will hurt.

     

    At the other end there are the thousands of individual apps now available on a series of platforms and operating systems that are targeted at a specific limited audience and may have limited appeal to the bigger audience. The comment I heard at a recent TASSQ meeting is that the Apps must ‘Excite’ the audience and furthermore they must get good reviews, no negative reviews, and be somewhere close to the top of the popularity list. Otherwise you might as well withdraw, rebuild, rebrand and re-release the app as new. It is too late to fix after the fact. If that sounds suddenly familiar that is because we have just repeated the Quality Assurance argument. More than ever we need to get it right the first time. As stated above, there is now no time to fix it. We only have one chance. This does not mean bogging down the app in a long drawn out testing cycle. This means getting it right all the way along the cycle. Then we will have apps that excite! Quality Assurance provides that guidance.

  • Sometimes Simpler is Better!

    We have all heard that ‘Simpler is Better’ and a recent personal experience proves the point. Two members of my family flew to Thunder Bay – one went to write an exam and the other one went along for the ride. They were to return on Saturday after the exam. They arrived at the Thunder Bay airport for the return flight with time to spare and started waiting for the plane. At the other end of the flight (Toronto) I was watching the arrivals online so I would know when I had to go and pick them up from the airport.

    The time for the flight to depart from Thunder Bay got closer and closer and then eventually passed with no sign of a plane. What was interesting was the following:

    • The Departures Board still indicated the flight was leaving on time
    • There was no one at the airline check-in desk to provide any updated information
    • At the other end, I could see on the airline’s website that the flight was delayed

    Eventually some of the passengers asked the security guard if he knew what had happened to the plane. He looked out the window at the gate and stated the obvious: No plane is here yet so it is late. Sometimes Simpler is Better when it comes to answering a question. They could have signed onto the airline’s site and would have seen the updated status but it is expected that would be reflected in the local information.

    This same issue appears sometimes in Quality Assurance. Some people are under the impression that Quality Assurance is trying to make things harder. This is the exact opposite of what it is trying to do. Quality Assurance makes processes and work simpler and allows more time for the creative problem solving side. Processes or items that are standard are made into a process. Items that require on-going problem solving skills now have more available resources. Visit how Quality Assurance can make you more creative.

  • Quality Drives Productivity

    The Economist recently ran an article entitled “Unproductive production” indicating the difficulty of measuring whether Productivity in an economy had really increased. One of the points which was interesting was that as long there are more people in employment and they are building more items the economy will continue to grow. However, the main concern is whether these people are being put to good use. This is where (in the Software Industry) we look to have Quality Drive Productivity.

    There have been a lot of Productivity gains in the last few years in Software and in the Quality Control and Quality Assurance areas in particular. We have moved away from manual testing to automated testing and gained a huge jump in Productivity. We have refined our testing methods to improve the way we write and execute test cases and, in return, gained a positive ROI. We partnered with development and the user to make more effective use of the testing time we have and cut back on waste and inefficiencies. We have embraced completely new Software Development Methodologies stretching from one end of the process to the other and integrated Quality Control throughout. In the recent past we have outsourced testing to specialists who are experts in the field. And lastly, we have off-shored lots of testing to cheaper resources.

    Two questions remain after all this:

    1. Are there further Productivity gains possible under the current processes?
    2. Is the current methodology really increasing Productivity?

    By extension, there are probably some further minor Productivity gains under the current processes but to gain a real productivity increase will require a complete rethink of the process. So the answer to the first question is a qualified yes. For the second question, the answer is a little more difficult. If we take as given the first four items as no longer increasing productivity, then we are left with outsourcing and off-shoring as our current methodology for increasing productivity. This is where the referenced article raises the point as to whether these methods are really increasing productivity. The answer is probably no!

  • We Have Met the Enemy and He is Us

    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

    ‘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.

  • Quality Assurance – Why?

    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.

  • Quality Assurance is Green?

    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.