NVP Software Solutions

Tag: QA

  • Selling QA

    In the last couple of blogs we talked about Early Involvement and the ROI of Quality Assurance. A list of a few places where Quality Assurance pays was also provided.

    However, Selling Quality Assurance can still be a challenge.

      • Some organisations see the benefit and buy in to the concept permanently.
      • Others never make the move towards a Quality Culture and cannot see the need.
      • The most common scenario is a cyclical one:

    Someone in an organisation embraces Quality and either are in the correct position to make it happen or have great timing where there has been a move towards Quality Assurance and it just needed someone
    to ‘ride the wave’ to completion.

    • There is, of couse, always the last scenario where there has been a crisis and everyone comes to the conclusion “If we only had had Quality Assurance the ‘problem/crisis/disaster’ would never have occurred”.

    Be very careful of the last one; it is not likely a deep commitment. Once the crisis is over, there will be a reversion to the earlier behaviour. It is very tempting to go to an organisation that has just had a crisis and try to convince them to change but it is not likely to occur and will be a struggle.

    So, how do we sell QA:

    1. We need to know the state of the organisation. Is there an underlying need or wish; or just a superficial desire?
    2. Who are the decision makers and what do they want?
    3. Where can be we get a reasonable return in a short period – we have to show something fairly quickly.

    Remember a culture change takes years. We need a set of successes that are directly attributable to Quality Assurance to start making the case for the wholesale introduction and embedding of the concept.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Quality Assurance is exceedingly Cost-Efficient.

    Contact us for further information.

  • Quality Assurance ROI

    One of the items which comes up in most Quality Assurance discussions is the determination of what Return on Investment Quality Assurance provides. It can be hard to justify and obviously depends on the Costing Model used in your organisation. The factors in the Costing Model may differ but the overall trend is always the same. Early Quality Assurance (see last blog) alway pays.

    Here are some of the places where and how Quality Assurance pays:

    1. An error found at Requirements time will be much cheaper to fix there rather than later in the lifecycle. Estimates range from 10% of the later cost down to far less than 0.1% for even moderately complex systems.
    2. Similarly an error found at Design time has a ratio that is slightly less than Requirements but still substantial.
    3. Inclusion of Quality Assurance at an early stage will lead to root cause analysis of repeated errors saving thousands of dollars in testing and repetition of test cases.
    4. Inclusion of Quality Assurance at an early stage allows the definition and construction of an environment suitable for testing when the code becomes available. Environments may be able to be shared leading to cost savings or, at the very least, they can be designed with all the testing considerations included up front.

    The above are only a few of the places where Quality Assurance can save many thousands of dollars on the project. There are many more which could be defined and calculated.
    Our next blog will look at how Quality Assurance can provide valuable input and how that is made clear to the users.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Quality Assurance is exceedingly Cost-Efficient.

    Contact us for further information.

  • Early Involvement of Quality Assurance

    One of the items which comes up in most Quality Assurance discussions is the determination of when to involve Quality Assurance in the project. Those with the traditional view of Quality Assurance as simply Software Testing (Quality Control) delay the arrival of the Qaulity Assurance Professional until the last possible moment and are then disappointed when the testing is not done correctly or with due regard for risk. People (including some Quality Assurance personnel) believe there is nothing to be done until the software is ready and ‘complete’.

    These people are missing the value that can be contributed by Quality Assurance early in the project including the following:

    1. Assessment of Risk from a Quality Assurance point of view.
    2. Review of Requirements and Design from a Quality Assurance point of view.
    3. Proper design of the test environment and the processes surrounding it.
    4. Proper and complete design of the testcases that address the most important risks while minimising the efforts.
    5. The chance to have feedback from other project members over the course of the test design and preparation.

    Of the above items the last is probably the most important. Feedback can help find and correct deficiencies earlier rather than later.

    Our next two blogs will provide concrete examples of how and where Quality Assurance can provide valuable input.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Design review is very cost-effective.

    Contact us for further information.

  • Review Design (by Writing Testcases)

    One of the easier methods of review, for a Software Tester, is to write test conditions, test objectives, or complete testcases for the design. We define Test Conditions or Test Objectives as being statements of what is to be tested without the details usually found in testcases.

    For example the following might be a few High Level Test Objectives for a design:

    1. Test that the system continues to function in the event that the link to the Postal Code database is not working.
    2. Test that the system switches to the backup node when the primary node is taken offline.
    3. Test that the database is updated with the full CDR at the end of the call.

    There is a lot of detail under these Test Objectives and potentially they could generate many, many testcases but they are all real examples and they are all necessary. They key is to look for the following while you are writing the test objectives:

    1. Two, or more, test conditions that contradict each other.
    2. Places where we find it difficult to write any objectives at all – this may be related to a lack of knowledge or the design may be incomplete. Either are issues.
    3. Places where we are guessing at the expected behaviour for our Objective. We do not expect details here but a feeling that we don’t know what the result will be or how to prove it.

    Brainstorming with other people, talking to the System Architect, looking at other similar designs and looking up technical information are all good sources for building these objectives.

    Once you have completed your personnel review, you may be asked to join a group review bringing in your comments and hearing from everyone else. There are several methods of review depending on Risk including Desk Checking, Walkthroughs, Reviews, and finally Inspections. These vary from informal to very formal. However, they are all aimed at finding the errors in the design sooner rather than later. They also all assume on previous individual work.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Design review is very cost-effective.

    Contact us for further information.

  • Review Design (by Reviewing)

    The title of this Blog may be considered to be a self-evident truth. How else would you review a design except by reviewing it? There are other ways which we will get to in a couple of weeks. However, our initial look will be by the standard method of reviewing them and what a Quality Assurance person might get out of the review.

    Reviewing a design can be difficult for some people. The following problems may arise:

    • You don’t know anything about the technical solution
    • The design is very technical
    • It is difficult to maintain concentration for an extended period of time

    There are ways around these problems. Some of them are personal and some relate to the methodology used to review the requirements.

    On the personal level:

    • Familiarise yourself with the system for which the design is being created. It will help! You cannot review in a vacuum.
    • Organise the design into sections so you can concentrate on a particular section at once.
    • Ask for a System Boundary Diagram (SBD).

    We emphasized one item above. The System Boundary Diagram can be created at many levels but the common idea is that it shows the system in a pictorial form and identifies the interfaces to external systems. The act of creating an SBD brings many problems to the surface and allows the Scope of testing to be set.

    Once you have completed your personnel review, you may be asked to join a group review bringing in your comments and hearing from everyone else. There are several methods of review depending on Risk including Desk Checking, Walkthroughs, Reviews, and finally Inspections. These vary from informal to very formal. However, they are all aimed at finding the errors in the design sooner rather than later. They also all assume on previous individual work.

    For a different way to review the design, look for our next blog on this topic.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Design review is very cost-effective.

    Contact us for further information.

  • Quality Assurance for Contracts

    Quality Assurance for Contracts may seem like something that does not need to be considered and can be ignored in the early stages of a business relationship. That seems to be the normal reaction. The number of contracts we have seen that pay no attention to Quality Assurance issues or summarise them in one line is quite large. Some of our favourites include:

    1. The product shall be of a Quality nature. Quality nature not being defined
    2. Testing will be completed. By whom and when, how or where is not considered
    3. Test results will be supplied. Format, detail and how left to the discretion of the supplier

    And list goes on with no improvement.

    Of course, we pay the price at the end when either the vendor points out that the Quality wording does not bind them to much or the customer starts demanding information and proof. You can pay for these omissions for years in extra work and effort to try and either get the information from vendors or in supplying more and more detailed results which you had not expected.

    A few clauses outlining the expected Quality Factors and the expectations in terms of Testing and Quality Assurance can save masses of time and budget later on. Even better a few Fundamental Processes, put in place while people are not stressed thinking about the project can ensure everyone is on the same page when it comes to information and communication.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Considering the Quality Assurance and testing aspects early in the contract can save you a lot of effort, time and funds later on.

    Contact us for further information.

  • Upcoming Events – January and February 2018

     

    NVP Software Solutions will be participating in the following software testing and quality assurance events happening this January in Ontario, Canada. The events are located in Toronto, Kitchener-Waterloo and London in the coming two weeks. Check out the relevant websites for more information and to register. This is a great opportunity to connect with other software testing and quality assurance professionals. We hope to see you there! (more…)

  • Selecting Software to run your business – 2

    As mentioned in the last blog, there is any number of packages that are available to do some or all of what you want the business to do. Whether that is to track Goods-in-Transit, Maintain Financial Records, Generate a Sales Catalogue, Create and send an email blast, Retain Customer Information, Track needed Repairs or Write a Document, there are many choices and all the choices have their advantages and disadvantages. Some are cheap, others expensive. Some provide functionality you will never use, others will leave you wishing the software did more.

    If you are facing this conundrum, there is a solution. There are methods to evaluate what you need, then to evaluate what is available and then to finally bring the two together to make a quantified decision about what to buy (or build).

    The high level process is:

      1. Survey all the areas in your organisation that will be affected by the new software.
      2. Document the stated requirements from each group and give them weights (example follows).
        • Must have = 5.

          • Note: Any technical requirements that cannot be changed are given a 5 or you can simply set them up as initial questions and remove anyone not matching them.

        • Should have = 4.
        • Nice to have = 3.
        • Minimal need = 2.
        • Unimportant = 1.
        • Not relevant = 0.
      3. Create a scorecard based on the above.
      4. Survey the existing tools (there are many sites on the internet).
      5. Select the top 4 and bring in the vendors for a demonstration.
      6. Fill in the scorecard.
      7. Bring in the two highest scorers for a more indepth presentation.
      8. Make your selection knowing with certainty that you have made the best choice.

      Now comes the more interesting part: Implementation. That is a subject for the next blog.