NVP Software Solutions

Tag: Quality Assurance

  • Register this week for the October events at TASSQ and KWSQA

    Last chance to register for TASSQ and KWSQA

       

    NVP is at StarCanada Wednesday and Thursday this week. Stop at our booth for your free stress relieving bug.

       

    If you are in the Greater Toronto Area or Kitchener-Waterloo you might want to consider these events to network with other QA people or learn some of the new ideas in QA.

    This image has an empty alt attribute; its file name is antenna-502680-unsplash-1024x683.jpg

    NVP Software Solutions will be participating in the following software testing and quality assurance events happening this September in Ontario, Canada. The events are located in Toronto and Kitchener-Waterloo in the coming 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!


    Photo by Antenna on Unsplash




    THE POWER OF DESIGN SPRINTS FOR PRODUCT TEAM

     October 29, 2019 6:00 p.m.  The Albany Club – 91 King Street East, Toronto, Ontario

    Presenters:  Leah Oliveira and Carlos Oliveira

    Reality Driven Testing

     October 30, 2019 11:30 a.m.   University of Waterloo

    Presenters:  Rob Sabourin 

  • October 2019 Software QA Events in the GTA and beyond

    If you are in the Greater Toronto Area or Kitchener-Waterloo you might want to consider these events to network with other QA people or learn some of the new ideas in QA.

    This image has an empty alt attribute; its file name is antenna-502680-unsplash-1024x683.jpg

    NVP Software Solutions will be participating in the following software testing and quality assurance events happening this September in Ontario, Canada. The events are located in Toronto and Kitchener-Waterloo in the coming 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!


    Photo by Antenna on Unsplash




    THE POWER OF DESIGN SPRINTS FOR PRODUCT TEAM

     October 29, 2019 6:00 p.m.  The Albany Club – 91 King Street East, Toronto, Ontario

    Presenters:  Leah Oliveira and Carlos Oliveira

    Reality Driven Testing

     October 30, 2019 11:30 a.m.   University of Waterloo

    Presenters:  Rob Sabourin 

  • RCA – Why – Part 1

    Why bother with Root Cause Analysis on Defects? We have enough to do without adding to the work!

    1. We found a defect.
    2. We fixed the defect.
    3. We retested the defect.
    4. We closed the defect (pending success on item 3).
    5. Enough said. Let’s move on to something else!

    We acknowledge that once we have a defect, all of the above have to occur (hopefully only once and not repeatedly). But Root Cause Analysis is intended to prevent 1 – 5 ever coming back to bother us again. The key word is ever! We never want to see that defect again. In order to do that, we need to find out where it occurred, why it occurred; and make sure that combination never comes up again. In the long term this saves us a lot of money and time and allows us to concentrate on more important items.

    October is Quality Month. Sign up for our newsletter, to see some things about Quality Month or request a copy if you are too late for this month.

    Photo by JJ Ying on Unsplash

  • Trend Analysis on Defects – Part 2

    Last week we discussed some prerequisites for Trend Analysis on defects. We are only discussing defects here but there are many other project metrics that could be analysed.

    Assuming that the prerequisites from the previous blog have been satisfied, what can we determine.

    1. The trend in the number of defects in each project (after normalization by some project size measurement).
    2. The trend in the number of defects in each Priority and Severity level (again after normalization).
    3. The phase or process that consistently generates the most defects.
    4. Any weak or defect prone supplier processes.
    5. Any product weaknesses that cause consistent customer complaints.

    Once we have the information listed above, we are in a strong position to fix any weak areas and correct any issues that may be costing us customers or internal funds. This is process improvement devoted to making sure that our internal processes are the best possible and we are generating the best possible product. There is more to trend analysis than we are mentioning here, but there are entire books and conferences devoted to this topic. We have only touched the surface of one item we can measure, address and improve.

    October is Quality Month. Sign up for our newsletter, coming out next week, to see some things about Quality Month.

    Photo by Stephan Henning on Unsplash

  • September Events in the GTA and Beyond

    If you are in the Greater Toronto Area or Kitchener-Waterloo you might want to consider these events to network with other QA people or learn some of the new ideas in QA.

    This image has an empty alt attribute; its file name is antenna-502680-unsplash-1024x683.jpg

    NVP Software Solutions will be participating in the following software testing and quality assurance events happening this September in Ontario, Canada. The events are located in Toronto and Kitchener-Waterloo in the coming 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!


    Photo by Antenna on Unsplash




    PRESIDENT’S DINNER – V2X (VEHICLE TO EVERYTHING) COMMUNICATIONS

     September 24, 2019 6:00 p.m.  The Albany Club – 91 King Street East, Toronto, Ontario

    Presenters: Charles Finlay, Peter Watkins, Tony Hui, Ysni Semsedini Moderator: Colin Dhillon

    Targeting Quality Conference

     September 23 – 24, 2019 6:00 p.m.  Cambridge Hotel & Conference Centre easily located on Hespeler Road in Cambridge, just off of the 401.

  • Does your software Testing Pay – Part 4

    “Does your Software Testing Pay” is the question we posted six weeks ago. We posted a simple calculation for a ROI and then a few comments that were received as feedback. Those comments were appreciated since they extended the idea past the direct defect costing calculation. Today we want to wrap up this series with some general comments that extend the idea a little farther.

    For the most part we have concentrated on the Software Testing aspect of Quality Assurance. Almost everyone we speak with is familiar with this aspect. Most software companies or those who depend on software complete some form of testing and the concept of testing can be generalised to cover a multitude of activities. However, it is not the entire picture.

    So, at the risk of making the title slightly inaccurate, what other aspects of Quality Assurance can be considered:

    1. Process improvement for the entire SDLC.
    2. Timely intervention at the Root Cause of many of the defects to prevent them from occuring in the first place.
    3. Concentration on the required end-result to make sure everyone is working towards that end. It is suprising how often this is obscured in large organisations. We attended a course a couple of weeks ago and spoke to the instructor afterwards and apparently many people on the course have only been told a very small piece of what they need to do (and part of that was to attend the course although the reason why was not provided). Not only is that against the concepts of keeping people informed of why they are doing something but it is also very de-motivating.

    The above list (particularly number 1) can cover a lot items that are very detailed and can add a lot of value to the Quality Assurance efforts. We may take this up in the fall.

  • Does your software Testing Pay – Part 3

    “Does your Software Testing Pay” is the question we posted four weeks ago. We then posted a simple calculation for a ROI two weeks ago.
    After we posted the second blog we had a couple of comments to the effect that concentrating on defects was a very narrow focus in terms of cost recovery and benefits. This was certainly a valid criticism; we had concentrated on something that could be answered and calculated without too much effort.

    Some of the suggestions that came back were as follows:

    1. Contributing to a better product using the information gleaned from testing
    2. Enhanced knowledge of the product for both testers and developers.
    3. Future design improvements.
    4. A better quality product.

    No doubt more items could be added to the above list

    Now we just need to cost them

    Since some of these are subjective benefits, it is suggested that they be documented and then all stakeholders can assign them to a value bucket (independently). As a starting point we can use an averaged value for each benefit and then convert that into a dollar value to determine the benefit.

  • Does your software Testing Pay – Part 2

    “Does your Software Testing Pay” is the question we posted two weeks ago.
    There are obviously two parts to this question, one is how much it costs and the other is how much it saves.

    The cost portion is reasonably easy:

    1. Chargeback rate on resources (means hours per release must be recorded).
    2. Equipment and space usage (if not included in the above).
    3. Test Tool cost (amortized over all the projects)
    4. Opportunity cost if the resources should be engaged in something else.

    The savings portion is somewhat harder:

    What would each found defect have cost to fix in production? This is obviously an estimate.  One calculation is supplied below.

    1. Look at each defect found by testing.
    2. Estimate the probability of it occuring after release of the code to the users. You might want to take estimates from several people and average them. Either the probabilities must be between 0 and 1 or else you need to convert to a figure between 0 and 1 before using it.
    3. Estimate the cost to the organisation under the assumption that the defect does occur in production. This cost includes the direct costs to the company (fixing, testing and deploying); the indirect costs (administration etc) that are often hidden (Iceberg – 9/10 of the costs are hidden)
    4. The cost of the customers in rework, lost data, inability to respond proerly.
    5. Add up the costs per defect and multiply by the percentage.
    6. Add up the resulting figure for all defects found by testing for a release.

    If Savings > Costs your software testing is paying for itself.