NVP Software Solutions

Category: News

  • What should be reported from your Testing Efforts – Part 4

    Feedback is always welcome and this week we are indebted to Paul Seaman for some very valid comments on the What should be reported from your testing – Part 2. He pointed out that the blog seemed to have a written bias, missed the value of verbal communication and seemed to silo testers.

    We were considering mainly final reports using an independent test team and with the potential need for an audit of the testing. So some bias may have crept in and Paul pointed that out. Let’s look at each of these.

    Siloed Test Team: The more you silo a test team, the less effective they are. Information does not flow to them or from them. So the opportunities to learn from each other is lost. In addition, any information that does flow back and forth will likely be somewhat distorted by the time it gets to the other party. Testers need to be included throughout the lifecycle embedded in the team.

    Verbal Communication: This is an obvious follow on from the previous point. If you are remote, or restricted in communication then the chance to provide and receive feedback is reduced. Non-verbal communication tends to be asynchronous – something is sent and there is a delay before there is a response. Verbal (throughout the project or testing effort) allows instant feedback and may speed up responses and reactions to changing events. The only thing you may lose is an audit trail. Anything crucial needs to be noted and put into a decision log for retention.

    Written bias: This comes down to the same thing as the last comment in the previous paragraph. Crucial information that needs to be retained should be documented and stored. If the report is simply a status that is being provided then it may not need to be fully documented. Point taken.

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

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


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

    This image has an empty alt attribute; its file name is TASSQ-1.png



    WHY AND HOW TO ADOPT BDD IN SOFTWARE DEVELOPMENT – Rob Ashall- 26 March, 2019
    See https://www.toronto-assq.com/ to register
    This image has an empty alt attribute; its file name is cropped-kwsqa_withicon_small.png


    KWSQA – Kitchener Waterloo Software Quality Association – Wednesday, April 3, 2019 – Making the Web a Little More Accessible – Samantha Campbell  – See https//www.kwsqa.org/kwalitytalks  to register

    Courses

    Plan your 2019 Courses today. See nvp.ca/services/training for a complete schedule.

  • Look ahead to 2019

    So what is coming in 2019. No doubt, if that could be predicted accurately, we would not be doing this right now! We would be somewhere on a warm sunny beach.

    The easy answers are:

    1. Manual testing will continue.
    2. More automation will be done and much more will be wanted (with or without the understanding of what it involves).
    3. The software we are testing will evolve.

    The harder predictions are the external events:

    1. Increasing legal and regulatory requirements for testing can be expected. While some specific regulations in particular industries will be rolled back , we expect the general direction to be more external requirements relating to legal liability and fulfillment of specific requirements.
    2. New industries will move mainstream with software and subsequent need for testing. (If we knew which ones, we would tell you.)
    3. There will be no letup in the pace of software testing. Items that are ‘old’ and mainstream may be assumed to be okay and require minimal testing but new items will still require testing.
    4. The level of interaction between programs will continue to increase.
    5. AI will impact testing.

    Things we would like to see (our wishlist):

    1. Increased emphasis on ensuring the customer’s needs are met (after all they are paying the bill).
    2. Better understanding of what Quality Assurance and Quality Control has to offer. It is still too late and an afterthought and those that go into the testing with the assumption that they know it all will not cover what they need to cover to reduce the risk.

    One thing that might come up is the necessity (because of volume) to make some code pieces ‘bulletproof’. No matter what you throw at them, they will operate in the way that is expected – either via processing or rejecting the provided information.

    Want to discuss 2019?

    Contact us or join the discussion.
    Past Blogs
    Monthly Newsletter

    Happy New Year.

  • A Better Way – Case Study 2 – Thinking Like the Client

    A Better Way – Case Study 2 – Thinking Like the Client

    In our last several blogs we have discussed ‘A Better Way to Test”.

    The issue is to apply this to actual situations. We have 5 Case Studies we plan to use over the next several weeks to address this. The second case study might be called “Thinking Like the Client”.

    Even though many in IT have embraced Agile in some form or another and with some level of success, not all clients are so willing. We find this particularly the case with larger, older and more safety or image conscious clients. They are not willing to take the risk of everything not coming together at the correct time. They are not willing to live with constant change. In addition, they often have milestones that need to be fulfilled and quite frequently they have stated contract deliverables that need to be fulfilled so that payments can be made.

    We received a call from the President of a development company with a large contract with probably the oldest, largest and most image conscious client you could get – the federal government. Even though the company had delivered projects successfully before and had a good record of coming through with what was required, the client still wanted a formal Test Plan completed.

    In our experience, the client is normally okay with a High Level Master Test Plan provided it contains the following (this is not an exhaustive list by any means):

    1. High Level Objectives
    2. A listing of the types of testing needed and the risk around each type
    3. Processes for Test Creation and signoff
    4. Processes for Defect tracking and resolution
    5. Methodologies for executing the testcases

    This reassures them that the developers have an understanding of what needs to be done.

    If you want to discuss this further contact us.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to you. Testing can be better.
    Contact us for further information.

  • October QA Events – Toronto and GTA

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

  • Isn’t there a better way to Test?

    Isn’t there a better way to Test?

    This is a question that gets asked very frequently especially at the end of projects that have not gone well. Testing is often left to the end of the project and by the time people get to it they are tired of the project, tired of the project team and generally looking for something new. Even when projects do go well; people ask the same question.

    The answer of course is “YES”. Testing can go better. But it requires a shift in the way it is done. Some people have a set methodology they use for all testing projects. Others rely on specific tools that are supposed to aid them in testing properly. Others work out what they are going to do when they get to the project. If every project was identical and things had been successful in the past then these approaches will work. However, no two projects are alike and the requirements for testing or Quality Assurance differ from project to project.

    Sometimes the differences are minor and techniques and processes used in the past can be reused with slight modifications. However, even with minor differences, testing needs to evolve over time to take into account new technologies and new methodologies. With major differences in projects and expectations much more than just a slight evolution must be undertaken. This will be the subject of the next few blogs.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Testing can be better.
    Contact us for further information.