Tag: QA

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

  • Struggling with Software Testing?

    Businesses, organizations and corporations purchase software in hopes of bettering existing processes, but sometimes the data is suspect and manual processes have to be put in place to fix errors caused by the new software tools. If software was implemented to help you operate more efficiently and grow as an organization, why is your new software slowing you down? Perhaps it’s time to look to your software testing team! (more…)

  • Reduce Business Risk with QA

    The software your business relies on to operate successfully is crutial to the success of your company. Software RISK (a potential problem that may occur due to lack of information, control or time) is something that should be minimized wherever possible when it comes to your daily business operations.
    (more…)

  • Make Better Business Decisions With the Help of QA

    When it comes to your company’s inventory management system and financials, is your information readily available so you can make key business decisions (with confidence)? If you can’t easily and honestly answer yes – perhaps it’s time to look at the process(es) with which you and your company manage data. This data could include monthly sales figures, accounts payable/ receivables, sales management data, purchase order tracking, contact database, employee information and more. (more…)