NVP Software Solutions

Category: Quality Assurance Consulting

  • 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 – Part 2?

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

    A couple of weeks ago we talked about the issue of Software Testing being Ad Hoc and some of the reasons this might be the case. See the blog from January 14, 2019.

    The major concerns were loss of information, repetition and reinvention.

    The quickest way to stop this loss is to classify the testcases. This does not have to be complex at the beginning. You can classify the testcases based on the following criteria:

    1. Priority – High – must be executed with every release; Medium – must be executed at least once a release; Low – may be ignored unless there is a lot of time.
    2. Feature/Module/Function – This does require some thought at the beginning since you want to get the classification right to avoid having to do a lot of reclassification later.
    3. Level of testing – Unit, Integration, System, Acceptance – again something that might require some thought at the beginning to avoid having to reclassify things later.

    Obviously this is best done in a tool with a database behind it although a lot of companies start with a spreadsheet. The only expectation is that the next iteration of the project can at least see what exists and pick up what they need.

    Later you may determine other classifications that are useful. If you do, you may or may not want to reclassify everything that has already been stored. You may also want to do it over time as the testcases are used rather than trying to do it as one project.

    We have gone one step towards eliminating the ad hoc nature of the testing and now have something that can be reused.

    Contact us or join the discussion.
    Past Blogs
    Monthly Newsletter

  • January 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 January in Ontario, Canada. The events are located in Toronto and Kitchener-Waterloo 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…)

  • 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

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

  • Review of the Year – Automation

    Review of the Year – Automation
    Automation of software testing is something that seems to be on the minds of many Quality Assurance Managers and Test Leads. It has been a popular topic for many years.

    Currently we get requests for particular tools and knowledge of their attributes in particular environments; these are usually serviceable. Current status seems to be a separate tool for every need and environment and sometimes every organisation. Based on past experience, in a few years, someone will consolidate all the disparate technologies under one umbrella tool. Then the cycle will start again with people inventing new tools for specific niches and products.

    We also receive requests for people to “automate our testing” with no decision on the tool attached. This is a completely different question and requires some discussion to occur before the attempt to automate even starts. We need to know the what; when and Why the company wants to automate their testing. The thing we want to avoid are the actions below.

    1. Purchase Automated Test Tool.
    2. Install Tool.
    3. Wait for successful automation to save all the cost of the tool and cost of manual testing.
    4. Become disillusioned.
    5. Go to 1; Repeat ad infinitum.

    This has occurred over and over in different organisations. A lot of money gets used up with no progress and eventually the organisation gives up on the cycle and continues manual testing (see last week’s blog).

    Our best recommendations are as follows:

    Look up where you are on the technology maturity level with your current technology.

    Decide what you need (criteria are available) in terms of automation and what you are capable of handling based on maturity level.

    Then do a Plan to implement your automation. Never assume it will just occur. It won’t.

    Want to discuss how to automate effectively? Contact us.

  • Review of the Year – Manual Testing

    Review of the Year – Manual Testing

    Manual Testing is something that seems to be on the minds of many Quality Assurance Managers and Test Leads. Usually they want out of the Manual Testing and view Automated Testing (Blog planned for next week) as the saviour of their budget and time constraints.

    However, judging by the vacant positions we get requests to fill, there is still no shortage of Manual Testing positions at least in our area. There are still a lot of requests for Manual Testers with business knowledge preferred and new software and startups still start with manual testing. We get requests for Automated Testing with specific tools usually requested and will discuss this next week.

    The part that seems to be missing from many of the requests and the subsequent position is any discussion of the How; What; Why; When; and If; of the manual testing.

    There seems to be limited thought given to How the testing is to be done apart from some vague request to build testcases and execute them.

    Little consideration is given to What to test and Why beyond the statement: “We need to test the software”.

    When and If are not such an issue: Yesterday and definitely are the one word answers to those questions.

    These answers certainly provide freedom for the tester to do what they want but that may not always align with all the stakeholder’s wishes and may be 180 degrees off in some cases.

    This leads to a poor ROI and a large waste of time and money.

    There will continue to be a market for manual testers for new changes and new applications that are not yet mainstream. We expect automation to take over many of the repetitive tasks (as has always been the case) The only open question at this stage might be what AI will do to the industry. That we cannot predict.

    Want to discuss the effectiveness of your Manual Testing further? Contact us.