NVP Software Solutions

Tag: Quality Control

  • Review Requirements (by Writing Testcases)

    This is the second in the series about reviewing requirements. This week we are considering the method of using Testcases to review the requirements. Some people would feel that this is too early in the process to be considering testcases but we do not have to write complete testcases. Test conditions or objectives will be enough at the start and the payback is substantial.

    As we mentioned in the last blog, reviewing requirements can be surprisingly difficult for some people. The following problems may arise:

    • You don’t know anything about the system under review
    • The requirements are disorganised
    • It is difficult to maintain concentration for an extended period of time

    The act of writing testcases (conditions or objectives) and attaching them to the requirement for which they were written (Traceability) has the impact of clarifying thoughts on what the requirement really means. Most requirements generate multiple testcases. In order to write even the start of the testcases, we need to be able to decompose the requirement into its component parts and understand each one. The process of doing this will highlight the deficiencies in the requirements.

    1. If our test conditions contradict each other then the requirements are probably inconsistent.
    2. If our test conditions don’t seem to cover everything, then the requirements are probably incomplete.
    3. If our test conditions expect to test items that are clearly wrong then the underlying requirements are probably wrong.
    4. If our test conditions seem unclear when completed, then the requirements are probably just as unclear.
    5. We could draw other conclusions but these are the main ones for requirements.

    The process here is used to clarify the thought processes.

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

    Contact us for further information.

  • Review Requirements (by Reviewing)

    The title of this Blog may be considered to be a self-evident truth. How else would you review a set of requirements except by reviewing them? 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.

    Reviewing requirements can be surprisingly difficult for some people. The following problems may arise:

    • You don’t know anything about the system under review
    • The requirements are disorganised
    • 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 requirements are being created. You cannot review in a vacuum.
    • Organise the requirements by tagging them according to the type and what they discuss. (It would be preferable if everyone used the same organisation but there is no guarantee of that occurring.)
    • Break up the review into sections

    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 requirements sooner rather than later. They also all assume on previous individual work.

    For a different way to review requirements, 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. Requirements review is very cost-effective.

    Contact us for further information.

  • Quality Assurance for Contracted Software

    Quality Assurance for Contracted Software is a little different from our last two blogs on somewhat similar topics (Downloaded and Contracts). Obviously there is overlap with the QA for Contracts but here we are assuming that, rather than contracting for an already built product that might be modified for our use, we are specifying exactly what will be built. We are contracting out the development (and maybe testing) of something where we know exactly what we want.

    One would think that this would be a great opportunity to put Quality Assurance requirements into the contract and provide exact criteria for what will be received. The problem is that people have trouble specifying quality. Ask a group (I have) for a definition of Quality and you will get as many answers as there are group members (maybe more).

    The following are pretty common answers:

      1. The product shall be Fit for Use. By whom and with what training not being defined
      2. The product will adhere to the Requirements as stated. Quality Requirements not always being well defined or defined at all

    And the same three from our last similar blog

    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

    it is worth some time to put Quality Requirements into a Contract for Software. The time taken to add the clauses is minimal. The payback is huge.

    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.

  • Online Courses starting April and May 2018

    QAI LVC Courses starting April 3, 2018

    1. CSTE Certification Training – Online – April
    2. CSQA Certification Training – Online- April
    3. EMST – Effective Methods of Software Testing – Online – April
    4. CSBA Certification Training – Online – May – New

    Courses are continuing throughout 2018.

    Take your opportunity to get training created by experts in the field. Make 2018 your best Quality Assurance year by being prepared and ready for whatever might come your way in terms of Software Testing or Quality Assurance.

    Quality Assurance is not just a solution to a technical software problem. It is a consideration for the entire business. Software Quality Assurance failures impact the entire business and can lead to large problems if not addressed.

    Training testers using NVP supplied courses provides testers with the techniques, tools, and knowledge to select the best method for testing – not the one that has been used for the last 15 years that’s falling short!

    When you work with an experienced software testing trainer you benefit by:

    • Creating more valuable employees that pays back more than investments
      in any test tool!
    • Getting real value from testing
    • Enhancing speed, accuracy and results from your testing processes
    • Seeing larger profits

    Quality assurance training is a great way to help ensure your systems are working for you while supporting and contributing to the growth of your company.

    Let us know if we can help!

  • March Events in Software Testing in the GTA and beyond

     

    NVP Software Solutions will be participating in the following software testing and quality assurance events happening this March 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…)

  • Quality Assurance for Downloaded Software

    Downloading software is trivially easy these days. “There is an App for almost everything and downloading then only usually requires selecting them and agreeing to a few conditions. We fully realise that there have been many, many, articles on the dangers of accepting all the conditions and the sort of access that it gives to your phone or computer. However, we are more concerned here with the Quality of the Application regardless of how much it requires access to things you would rather keep private. The first step is in the testing that the App stores carry out before agreeing to include the App in the store. However, we are still concerned about whether the App actually does what it is supposed to before you trust it to help you in some way. The only real way to to prove that is to carry out proper Quality Assurance and Quality Control before you download the code. We know how difficult that is and there is not really any access for you to check short of installing it and hoping for the best in your particular software and hardware configuration.

    There is an open question surrounding how to test that the App actually does what it is supposed to or what it is advertised to do. This needs to be checked either by the vendor or by independent testers.

    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 can save you a lot of effort, time and funds later on.

    Contact us for further information.

  • Debugging versus Scenario Testing

    Recently someone in a class asked about the difference between debugging and scenario testing given the fact that many errors that need to be fixed must be completed in the code.

    If we make the assumption that we are doing a calculation of some sort or running an algorithm then the following applies.

    During User Acceptance Testing – the test should work end-to-end without an error in actual execution. The appearance, formatting or placement of the result may be incorrect but there should be no problems in running the actual process. This applies to normal cases. Clearly there is a possibility of issues with the unique cases that may have been identified late in the process. If the algorithm or test case does not run or cannot be completed then we are probably debugging rather than scenario testing.

    During System Testing – the calculation should complete although the result may be wrong and one or more steps along the way may provide incorrect results. So the results should be available and the algorithm complete although the results may be wrong. System Testing is aimed at Requirements so this is where we should whether the results agree with the requirements. If the individual test cases do not run or cannot be completed then we are probably debugging rather than scenario testing.

    During Integration Testing – each individual piece (validation of a piece of the overall algorithm) should run but they may not be able to work together. If the individual pieces do not work, then we are debugging. If they cannot be run as an integrated whole, then we are testing.

    During Unit Testing – we are debugging each individual piece of the algorithm. This is code debugging and is not expected to be anything else.

    Contact us to see whether you are scenario testing of debugging.

    Diagram by Veronica

  • Quality Assurance for Packaged Software

    There has been a large change in the last decade in how software is built and used. With the ability for anyone to build an app and market it, many organisations have realised that it is ‘easier to buy than build’. There are unique applications that are still being built (many of them) but for regular business functions and even some unique business functions it is often better and more effective to buy. A lot more functionality is available in the purchased package than could be built internally for the same cost.

    However the end result of this is that the Quality Assurance and testing aspects are frequently overlooked because they should have been taken care of by the vendor. However, most EULAs do not provide any assurance that the product works or provides valid results or information. Usually they state the opposite, there is absolutely no promise made of any ability to rely on the results. Thus you are on your own for the Quality Assurance (‘QA cannot be outsourced’).

    What tends to be overlooked in the rush to acquire the package is that considerations for QA need to be made at the time the purchase is being considered. They become part of the contract or requirements to ensure that the package is most of the way to fulfilling our needs before it arrives on site. We don’t want to be in the position of trying to change a package after it has already been purchased.

    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 can save you a lot of effort, time and funds later on.

    Contact us for further information.