NVP Software Solutions

Tag: Software Quality Assurance

  • Are you satisfied with your testing – Part 2

    You may recall from the blog of two weeks ago that may organisations end up dissatisfied with their testing.

    The key to resolving this, from Quality Assurance, is to plan your testing before your start. Decide on what must be done, what should be done and what need not be done before the project gets very far.

    Sometimes people call these decisions ‘tradeoffs‘ since they imply that something is being traded off against something else and someone is losing out. Tradeoffs are different and do have the characteristics mentioned in the previous sentence. Here we are planning for what needs to be done.

    Other people claim they need to see the software in order to know what to test. At the detail level this can be true but it is not true at the upper levels.

    Still others will claim that they will think of all the testing that needs to occur while they are doing it. This is not a bad method as long as the tester fully understands all the business, technical, and software requirements and can handle all of this. Small projects with little risk can be done this way. Larger projects with higher risks are not so easy.

    A Quality Assurance process considers all the relevant items at the start and does not wait for a crisis to occur or for management to worry about what has been completed or not completed. It is determined at the beginning and the decisions taken at that point, not in the last 10% of the project with a huge amount of the work to complete. Ongoing reporting and process improvement ensures this works properly.

    Contact us or join the discussion.
    Past Blogs
    Monthly Newsletter

  • Are you satisfied with your testing?

    Following on from the theme of last month, many organisations are dissatisfied with their testing. They feel it is incomplete, or ineffective or costs too much. At the end of the testing effort they are left with a vague feeling of unease. Often it is difficult for people to quantify their concerns but they are very real and lead to delays and ongoing expensive testing in an effort to remove this feeling.

    The trouble is that the more they do in testing, the more they may realise what they have not done. This does not increase the confidence level! Furthermore, if they do find problems during this ‘extra’ testing effort the level of confidence drops commensurately and even more testing is required until there is no energy, budget or time left.

    Come back on February 25 to see how a Quality Assurance process can address these concerns long before they become issues.

    Contact us or join the discussion.
    Past Blogs
    Monthly Newsletter

  • Is your Software Testing Ad-Hoc?

    We wanted to start the new-year off with a topic we hear a lot about from many many people.

    Our Software Testing is Ad-hoc (i.e. created or done for a particular purpose as necessary.).

    • It is never reused.
    • We are always looking at testing each project as if it were a brand new experience.
    • Very little gets carried forward from previous projects and a lot of stuff seems to disappear

    If you have heard this or felt this way, you are not alone. The comment that “We had this somewhere but I cannot remember where or cannot find it right now” gets repeated a lot.

    The question is why does it occur. Some of the answers are below:

    • Project budgets are not built with the intent of supplying tests to later projects.
    • No-one can predict whether the same testcases will be needed in a future project
    • No-one can predict whether the testcases will be valid for a future project (may be outdated).
    • It is not possible to estimate how long it will be before an update is needed and we might re-use the testcases.

    All of the above reasons mitigate against creating and retaining robust testcases suitable for future use. The end result is ad-hoc testcases created for the project and discarded after one or a few uses.

    If you want a process that will solve this problem, come back in 2 weeks when we will provide a methodology that will solve this problem at minimal project cost and with positive ROI over the lifetime of the software.

    In the meantime, if you are in the GTA (Greater Toronto Area) or KW, see our next blog next week about the coming presentations.

    If you cannot wait for the two weeks for an answer look at some of the following information:

    Contact us or join the discussion.
    Past Blogs
    Monthly Newsletter